<unnamed>

Public Key

npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4

Profile Code

nprofile1qqsrsljy2d5a380ktvr85m7x5llcn2qmexx050h2k5fd96vmjqnl94spzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkcqg5waehxw309aex2mrp0yhxgctdw4eju6t0csxm2m

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:38:57 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> > So connecting to many nodes just because we can and it's not technically
> > prevented is bad for the network and creating systemic risks of failure,
>
> Well it is actually; that's why myself, Wladimir van der Laan, and
> Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
> attack.
>
> The Bitcoin P2P network is resilliant to failure when the chance of any
> one node going down is uncorrelated with others. For instance if you
> accidentally introduced a bug in your nodes that failed to relay
> transactions/blocks properly, you'd simultaneously be disrupting a large
> portion of the network all at once.
>
This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.
> How many nodes is Coinbase connecting too? What software are they
> running? What subnets are they using? In particular, are they all on one
> subnet or multiple?
>
We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.
> > You know, you're creating an interesting bit of game theory here: if I'm
> > > a miner who doesn't already have a mining contract, why not implement
> > > full-RBF to force Coinbase to offer me one? One reason might be because
> > > other miners with such a contract - a majority - are going to be asked
> > > by Coinbase to reorg you out of the blockchain, but then we have a
> > > situation where a single entity has control of the blockchain.
> > >
> >
> > If someone did enter into contracts with miners to mine certain
> > transactions, and had a guarantee that the miners would not build on
> > previous blocks which included double spends, then they would only need
> > contracts with 51% of the network anyway. So it wouldn't really matter if
> > you were a small time miner and wanted to run full-RBF.
>
> But of course, you'd never 51% the network right? After all it's not
> possible to guarantee that your miner won't mine double-spends, as there
> is no single consensus definition of which transaction came first, nor
> can there be.
>
> Or do you see things differently? If I'm a small miner should I be
> worried my blocks might be rejected by the majority with hashing power
> contracts because I'm unable to predict which transactions Coinbase
> believes should go in the blockchain?
>
You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.
We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all. I do not see a single benefit
to running full-RBF.
FWIW, I'm fine with the first-seen-safe RBF, that seems like a sensible
addition and a good way to allow fees to be added or increased on existing
transactions, without harming existing applications of bitcoin.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/67e0dce0/attachment.html>

2023-06-07 17:38:56 CEST

- reply

📅 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>

2023-06-07 17:38:55 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> 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.
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.
In the long term, I would love to see a safe, decentralized solution for
accepting zeroconf transactions. However, right now there is no such
solution supported by any wallets in use, and I don't think breaking the
current bitcoin behavior for everyone is the best way to achieve this.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f769ac6f/attachment.html>