Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Before F2Pool's launch, I performed probably the only successful bitcoin double spend in the March 2013 fork without any mining power. [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad the full RBF is. We are going to switch to FSS RBF in a few hours. Sorry. On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd p...@petertodd.org wrote: On Fri, Jun 19, 2015 at 09:33:05AM -0400, 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? Specifically the following is what I told them: We are interested in the replace-by-fee patch, but I am not following the development closely, more background info is needed, like what the difference between standard and zeroconf versions? Thanks. Great! Basically both let you replace one transaction with another that pays a higher fee. First-seen-safe replace-by-fee adds the additional criteria that all outputs of the old transaction still need to be paid by the new transaction, with = as many Bitcoins. Basically, it makes sure that if someone was paid by tx1, then tx2 will still pay them. I've written about how wallets can use RBF and FSS-RBF to more efficiently use the blockchain on the bitcoin-development mailing list: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html Basically, for the purpose of increasing fees, RBF is something like %50 cheaper than CPFP, and FSS-RBF is something like %25 cheaper. In addition, for ease of implementation, my new FSS-RBF has a number of other restrictions. For instance, you can't replace multiple transactions with one, you can't replace a transaction whose outputs have already been spent, you can't replace a transaction with one that spends additional unconfirmed inputs, etc. These restrictions aren't set in stone, but they do make the code simpler and less likely to have bugs. In comparison my previous standard RBF patch can replace multiple transactions with one, can replace long chains of transactions, etc. It's willing to do more computation before deciding if a transaction should be replaced, with more complex logic; it probably has a higher chance of having a bug or DoS attack. You've probably seen the huge controversy around zeroconf with regard to standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer, it also doesn't make it any more dangerous, so politically with regard to zeroconf it makes no difference. You *can* still use it doublespend by taking advantage of how different transactions are accepted differently, but that's true of *every* change we've ever made to Bitcoin Core - by upgrading to v0.10 from v0.9 you've also broken zeroconf in the same way. Having said that... honestly, zeroconf is pretty broken already. Only with pretty heroic measures like connecting to a significant fraction of the Bitcoin network at once, as well as connecting to getblocktemplate supporting miners to figure out what transactions are being mined, are services having any hope of avoiding getting ripped off. For the average user their wallets do a terrible job of showing whether or not an unconfirmed transaction will go through. For example, Schildbach's Bitcoin wallet for Android has no code at all to detect double-spends until they get mined, and I've been able to trick it into showing completely invalid transactions. In fact, currently Bitcoin XT will relay invalid transactions that are doublepsends, and Schildbach's wallet displays them as valid, unconfirmed, payments. It's really no surprise to me that nearly no-one in the Bitcoin ecosystem accepts unconfirmed transactions without some kind of protection that doesn't rely on first-seen-safe mempool behavior. For instance, many ATM's these days know who their customers are due to AML requirements, so while you can deposit Bitcoins and get your funds instantly, the protection for the ATM operator is that they can go to the police if you rip them off; I've spoken to ATM operators who didn't do this who've lost hundreds or even thousands of dollars before giving up on zeroconf. My big worry with zeroconf is a service like Coinbase or Shapeshift coming to rely on it, and then attempting to secure it by gaining control of a majority of hashing power. 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%. There's no way in a decentralized network to come to consensus about what transactions are or are
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse stephencalebmo...@gmail.com 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 p...@petertodd.org 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 people safe? --- For a decentralized wallet, the situation is pretty bleak. These wallets only have a handful of connections to the network, with no way of knowing if those connections give an accurate view of what transactions miners actually know about. The only serious attempt to fix this problem for decentralized wallets that has been actually deployed is
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com 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] Fwd: Block Size Increase Requirements
On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. If Western miners do not find a China-based VPN into China, or if Western pools do not manage to improve their connectivity to China, or run a node in China, it would be them to have higher orphans, not us. Because we have 50%+. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I cannot believe why Gavin (who seems to have difficulty to spell my name correctly.) insists on his 20MB proposal regardless the community. BIP66 has been introduced for a long time and no one knows when the 95% goal can be met. This change to the block max size must take one year or more to be adopted. We should increase the limit and increase it now. 20MB is simply too big and too risky, sometimes we need compromise and push things forward. I agree with any solution lower than 10MB in its first two years. On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang 1240...@gmail.com wrote: On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. If Western miners do not find a China-based VPN into China, or if Western pools do not manage to improve their connectivity to China, or run a node in China, it would be them to have higher orphans, not us. Because we have 50%+. On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang 1240...@gmail.com wrote: On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. If Western miners do not find a China-based VPN into China, or if Western pools do not manage to improve their connectivity to China, or run a node in China, it would be them to have higher orphans, not us. Because we have 50%+. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. So far top 100 biggest bitcoin blocks are all from us. We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. I know most blocks would not be 20 MB over night. But only if a small fraction of blocks more than 10 MB, it could dramatically increase of our orphan rate, result of higher fee to miners. Bad miners could attack us and the network with artificial big blocks. As yhou know, other Chinese pools, AntPool, BW, they produces ASIC chips and mining mostly with their own machines. They do not care about a few percent of orphan increase as much as we do. They would continue their zero fee policy. We would be the biggest loser. As the exchanges had taught us, zero fee is not health to the network. Also we have to redevelop our block broadcast logic. Server bandwidth is a lot more expensive in China. And the Internet is slow. Currently China has more than 50% of mining power, if block size increases, I bet European and American pools could suffer more than us. We think the max block size should be increased, but must be increased smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, and so on. Thanks. On Fri, May 8, 2015 at 6:02 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I probably forgot one or two and certainly dont want to back myself into a corner on committing to something here, but those are a few things I see today as big blockers on larger blocks. Luckily, people have been making progress on building the software needed in all of the above for a while now, but I think they're all very, very immature today. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. Agreed, but that is water under the bridge at this point. You - rightly - opened the topic here and now we're discussing it.
