rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-06-19 📝 Original message:On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote: > > > > For instance, if Coinbase had > > contracts with 80% of the Bitcoin hashing power to guarantee their > > transactions would get mined, but 20% of the hashing power didn't sign > > up, then the only way to guarantee their transactions could be for the > > 80% to not build on blocks containing doublespends by the 20%. > > > > This seems to be more of a problem with centralized mining than zeroconf > transactions. You're mistaking cause and effect: the contracts will drive centralization of mining, as only the larger, non-anonymous, players have the ability to enter into such contracts. > Speaking of, could we get a confirmation that Coinbase is, or is not, > > one of the merchant service providers trying to get hashing power > > contracts with mining pools for guaranteed transaction acceptance? IIRC > > you are still an advisor to them. This is a serious concern for the > > reasons I outlined in my post. > > > > We have no contracts in place or plans to do this that I am aware of. > > However, we do rely pretty heavily on zeroconf transactions for merchant > processing, so if any significant portion of the mining pools started > running your unsafe RBF patch, then we would probably need to look into > this as a way to prevent fraud. What happens if the mining pools who are mining double-spends aren't doing it delibrately? Sybil attacking pools appears to have been done before to get double-spends though, equally there are many other changes the reduce the reliability of transaction confirmations. For instance the higher demands on bandwidth of a higher blocksize will inevitably reduce the syncronicity of mempools, resulting in double-spend opportunities. Similarly many proposals to limit mempool size allow zeroconf double-spends. In that case would you enter into such contracts? -- 'peter'[:-1]@petertodd.org 000000000000000005a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/7536be71/attachment.sig>