{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:\n\u003e \u003e\n\u003e \u003e For instance, if Coinbase had\n\u003e \u003e contracts with 80% of the Bitcoin hashing power to guarantee their\n\u003e \u003e transactions would get mined, but 20% of the hashing power didn't sign\n\u003e \u003e up, then the only way to guarantee their transactions could be for the\n\u003e \u003e 80% to not build on blocks containing doublespends by the 20%.\n\u003e \u003e\n\u003e \n\u003e This seems to be more of a problem with centralized mining than zeroconf\n\u003e transactions.\n\nYou're mistaking cause and effect: the contracts will drive\ncentralization of mining, as only the larger, non-anonymous, players\nhave the ability to enter into such contracts.\n\n\u003e Speaking of, could we get a confirmation that Coinbase is, or is not,\n\u003e \u003e one of the merchant service providers trying to get hashing power\n\u003e \u003e contracts with mining pools for guaranteed transaction acceptance? IIRC\n\u003e \u003e you are still an advisor to them. This is a serious concern for the\n\u003e \u003e reasons I outlined in my post.\n\u003e \u003e\n\u003e \n\u003e We have no contracts in place or plans to do this that I am aware of.\n\u003e \n\u003e However, we do rely pretty heavily on zeroconf transactions for merchant\n\u003e processing, so if any significant portion of the mining pools started\n\u003e running your unsafe RBF patch, then we would probably need to look into\n\u003e this as a way to prevent fraud.\n\nWhat happens if the mining pools who are mining double-spends aren't\ndoing it delibrately? Sybil attacking pools appears to have been done\nbefore to get double-spends though, equally there are many other changes\nthe reduce the reliability of transaction confirmations. For instance\nthe higher demands on bandwidth of a higher blocksize will inevitably\nreduce the syncronicity of mempools, resulting in double-spend\nopportunities. Similarly many proposals to limit mempool size allow\nzeroconf double-spends.\n\nIn that case would you enter into such contracts?\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000005a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/7536be71/attachment.sig\u003e"}