Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-06-19 š Original message:On Fri, Jun 19, 2015 at ...
š
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>;
š 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>;