Adrian Macneil [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-19 📝 Original message:> > > We have no contracts ...
📅 Original date posted:2015-06-19
📝 Original message:>
> > 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?
>
We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.
If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).
Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e0ee9118/attachment.html>;
📝 Original message:>
> > 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?
>
We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.
If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).
Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e0ee9118/attachment.html>;