Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
> > > 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Great. Thank you for this! Adrian On Fri, Jun 19, 2015 at 7:40 AM, Chun Wang <1240...@gmail.com> wrote: > On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil > wrote: > > 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. > > This might be useful to you: https://www.f2pool.com/api/mempool > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
> > Unless you're sybil attacking the network and miners, consuming valuable > resources and creating systemic risks of failure like we saw with > Chainalysis, I don't see how you're getting "very small" double-spend > probabilities. > 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, but relaying harmful double spend transactions just because you can and it's not technically prevented, is good for everyone? > 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. > For the good of Bitcoin, and your own company, you'd do well to firmly > state that under no condition will Coinbase ever enter into mining > contracts. > I don't personally see what good this does for bitcoin. Now you are suggesting that we should prevent a 51% attack by using policy and promises, rather than a technical solution. How is this any better than us relying on existing double spend rules which are based on policy and promises? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
> > > 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Extremely disappointed to hear this. This change turns double spending from a calculable (and affordable) risk for merchant payment processors into certain profit for scammers, and provides no useful benefit for consumers. I sincerely hope that F2Pool reconsider, given that RBF will decrease the overall utility of bitcoin and reduce the number of people using it for online purchases. Adrian On Fri, Jun 19, 2015 at 6:33 AM, Stephen Morse wrote: > It is disappointing that F2Pool would enable full RBF when the safe > alternative, first-seen-safe RBF, is also available, especially since the > fees they would gain by supporting full RBF over FSS RBF would likely be > negligible. Did they consider using FSS RBF instead? > > Best, > Stephen > > On Fri, Jun 19, 2015 at 6:39 AM, Peter Todd wrote: > >> Yesterday F2Pool, currently the largest pool with 21% of the hashing >> power, enabled full replace-by-fee (RBF) support after discussions with >> me. This means that transactions that F2Pool has will be replaced if a >> conflicting transaction pays a higher fee. There are no requirements for >> the replacement transaction to pay addresses that were paid by the >> previous transaction. >> >> >> I'm a user. What does this mean for me? >> --- >> >> In the short term, very little. Wallet software aimed at average users >> has no ability to reliably detect conditions where an unconfirmed >> transaction may be double-spent by the sender. For example, Schildbach's >> Bitcoin Wallet for Android doesn't even detect double-spends of >> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes >> that propagate them. The least sophisticated double-spend attack >> possibly - simply broadcasting two conflicting transactions at the same >> time - has about 50% probability of success against these wallets. >> >> Additionally, SPV wallets based on bitcoinj can't even detect invalid >> transactions reliably, instead trusting the full node(s) it is connected >> too over the unauthenticated, unencrypted, P2P protocol to do validation >> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay >> double-spends that spend the output of the conflicting transaction. I've >> personally tested this with Schildbach's Bitcoin Wallet for Android, >> which shows such invalid transactions as standard, unconfirmed, >> transactions. >> >> Users should continue to assume that unconfirmed transactions could be >> trivially reversed by the sender until the first confirmation. In >> general, only the sender can reverse a transaction, so if you do trust >> the sender feel free to assume an unconfirmed transaction will >> eventually confirm. However, if you do not trust the sender and/or have >> no other recourse if they double-spend you, wait until at least the >> first confirmation before assuming the transaction will go through. >> >> In the long term, miner support of full RBF has a number of advantages >> to users, allowing you to more efficiently make transactions, paying >> lower fees. However you'll need a wallet supporting these features; none >> exist yet. >> >> >> I'm a business. What does this mean for me? >> --- >> >> If you use your own node to verify transactions, you probably are in a >> similar situation as average users, so again, this means very little to >> you. >> >> If you use a payment processor/transaction API such as BitPay, Coinbase, >> BlockCypher, etc. you may or may not be accepting unconfirmed >> transactions, and they may or may not be "guaranteed" by your payment >> processor even if double-spent. If like most merchants you're using the >> API such that confirmations are required prior to accepting orders (e.g. >> taking a meaningful loss such as shipping a product if the tx is >> reversed) nothing changes for you. If not I recommend you contact your >> payment processor. >> >> >> I'm a miner. Why should I support replace-by-fee? >> - >> >> Whether full or first-seen-safe⁵ RBF support (along with >> child-pays-for-parent) is an important step towards a fully functioning >> transaction fee market that doesn't lead to users' transactions getting >> mysteriously "stuck", particularly during network flooding >> events/attacks. A better functioning fee market will help reduce >> pressure to increase the blocksize, particularly from the users creating >> the most valuable transactions. >> >> Full RBF also helps make use of the limited blockchain space more >> efficiently, with up to 90%+ transaction size savings possible in some >> transaction patterns. (e.g. long payment chains⁶) More users in less >> blockchain space will lead to higher overall fees per block. >> >> Finally as we'll discuss below full RBF prevents a number of serious >> threats to the existing level playing field that miners operate in. >> >> >> Why can't we make accepting unconfirmed txs from untrusted
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
> > 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Double spending and replace by fee
Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants. Adrian > On Mar 28, 2015, at 7:22 AM, Peter Todd wrote: > > Signed PGP part > Would you so us all a favor and make a list of companies *actually* relying > on "first-seen" mempool behaviour. Because I've been having a hard time > actually finding anyone who does who hasn't given up on it. Not very useful > to talk about attacks against hypothetical defences. > > On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn wrote: > >I've written a couple of blog posts on replace by fee and double > >spending > >mitigations. They sum up the last few years (!) worth of discussions on > >this list and elsewhere, from my own perspective. > > > >I make no claim to be comprehensive or unbiased but I keep being asked > >about these topics so figured I'd just write up my thoughts once so I > >can > >send links instead of answers :) And then so can anyone who happens to > >agree. > > > >(1) Replace by fee scorched earth, a counter argument: > > > >https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d > > > >This article lays out the case against RBF-SE and argues it is harmful > >to > >Bitcoin. > > > >(2) Double spending and how to make it harder: > > > >https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 > > > >This article summarises a couple of double spending incidents against > >merchants and then discusses the following techniques: > > > > 1. Risk analysis of transactions > > 2. Payment channels > > 3. Countersigning by a trusted third party > > 4. Remote attestation > > 5. ID verification > > 6. Waiting for confirmations > > 7. Punishment of double spending blocks > > > >I hope the material is useful / interesting. > > > > > > > > > >-- > >Dive into the World of Parallel Programming The Go Parallel Website, > >sponsored > >by Intel and developed in partnership with Slashdot Media, is your hub > >for all > >things parallel software development, from weekly thought leadership > >blogs to > >news, videos, case studies, tutorials and more. Take a look and join > >the > >conversation now. http://goparallel.sourceforge.net/ > > > > > > > >___ > >Bitcoin-development mailing list > >Bitcoin-development@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
