[Bitcoin-development] IMPORTANT - Bitcoin Dev List Move Tuesday, June 23rd 8pm UTC
This is an important notice to all members of the Bitcoin Dev List. *Tuesday, June 23rd 8pm UTC (1pm PDT) the following will happen.* - The current list at bitcoin-development@lists.sourceforge.net will reject all posts. - The current archives at http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/ will be exported. - The test archives at the new list will be wiped and replaced with an import from the old list. - The new list https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev will be open to posts after the archive import is complete. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Everyone may to subscribe at the new list now. Feel free to make test posts. Anything posted prior to the switchover on Tuesday will be wiped from the archives. *DMARC Status* A current issue with this list is posts from domains that require DKIM signature verification will end up in the spam folder at popular providers like gmail. Initially the new list will have that exact same problem as we will continue to have the subject tag and footer. Within a few weeks LF will upgrade Mailman to do automatic Munge From http://wiki.list.org/DEV/DMARC which will solve this problem. Warren Togami -- ___ 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
Yep - similarly: you live in a neighborhood with a local coffee store. Sure you could use a stolen credit card or a fake $5 bill, but it's not worth the risk of being caught for a $3 coffee. And on the other side, the store can deal with 1% of transactions getting reversed or having a fake bill so they don't change their procedures. Perfection is not necessary in all situations. On Sat, Jun 20, 2015 at 12:02 AM, Eric Lombrozo elombr...@gmail.com wrote: On Jun 19, 2015, at 8:48 PM, Luke Dashjr l...@dashjr.org wrote: On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote: They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. They never will be. You can get a decent rate of success merely by making one transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg, 1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason unconfirmed transactions aren't double spent today is because nobody is seriously *trying*. Luke Newspapers are often sold in vending machines that make it possible for anyone to just pay the price of one and take them all…and most of the time they are not that carefully monitored. Why? Because most people have better things to do than try to steal a few newspapers. They probably were much more closely monitored earlier in their history…but once it became clear that despite the obvious attack vector very few people actually try to game it, vendors figured it wasn’t really that big a risk. Same thing applies to people trying to steal a piece of bubble gum at the cash register at a convenience store by double-spending. - Eric Lombrozo -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hard fork via miner vote
On Saturday, 20 June 2015, at 8:11 pm, Pieter Wuille wrote: you want full nodes that have not noticed the fork to fail rather than see a slow but otherwise functional chain. Isn't that what the Alert mechanism is for? If these nodes continue running despite an alert telling them they're outdated, then it must be intentional. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hard fork via miner vote
On Sat, Jun 20, 2015 at 7:26 PM, David Vorick david.vor...@gmail.com wrote: I see it as unreasonable to expect all nodes to upgrade during a hardfork. If you are intentionally waiting for that to happen, it's possible for an extreme minority of nodes to hold the rest of the network hostage by simply refusing to upgrade. However you want nodes to be able to protest until it is clear that they have lost the battle without being at risk of getting hardforked out of the network unexpectedly. You can't observe the majority of nodes, only miners, and weighed by hashrate. If you need a mechanism for protest, that should happen before the hard fork change code is rolled out. I am assuming a completely uncontroversial change, in order to not confuse this discussion with the debate about what hard forks should be done. So I am not talking about protest, just about deploying a change. And yes, it is unreasonable to expect that every single node will upgrade. But there is a difference between ignoring old unmaintained nodes that do not influence anyone's behaviour, and ignoring the nodes that power miners producing actual blocks. In addition, having no blocks on the old chain is safer than producing a small number, as you want full nodes that have not noticed the fork to fail rather than see a slow but otherwise functional chain. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hard fork via miner vote
I agree giving notice that the change is going to happen is critical for a hard fork. If miners vote in favor, they need to give people time to upgrade (or to decide to reject the fork). The BIP 100 proposal is that no change will happen until a timestamp is reached. It isn't clear exactly how it would work. Testnet: Sep 1st 2015 Mainnet: Jan 11th 2016 It suggests 90% of 12000 blocks (~83 days). This means that if 10800 of the last 12000 blocks are the updated version, then the change is considered locked in. I think having an earlier fail threshold would be a good idea too. This guarantees notice. Assuming 3 is old rule and 4 is new rule If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of the last 12000 blocks are version 4+, then reject version 4 blocks If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of the last 12000 blocks are version 4+, then reject version 3 blocks (lock-in) If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of the last 12000 blocks are version 4+, the allow new rule This means that if the 90% threshold is lost at any time between 1st Sep and 1st Nov, then the fork is rejected. Otherwise, after the 1st Nov, it is locked in, but the new rules don't activate until 1st Jan. For block size, miners could still soft fork back to 1MB after 1st Nov, it there is a user/merchant revolt (maybe that would be version 5 blocks). On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Hello all, I've seen ideas around hard fork proposals that involve a block version vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I believe this is a bad idea, independent of what the hard fork itself is. Ultimately, the purpose of a hard fork is asking the whole community to change their full nodes to new code. The purpose of the trigger mechanism is to establish when that has happened. Using a 95% threshold, implies the fork can happen when at least 5% of miners have not upgraded, which implies some full nodes have not (as miners are nodes), and in addition, means the old chain can keep growing too, confusing old non-miner nodes as well. Ideally, the fork should be scheduled when one is certain nodes will have upgraded, and the risk for a fork will be gone. If everyone has upgraded, no vote is necessary, and if nodes have not, it remains risky to fork them off. I understand that, in order to keep humans in the loop, you want an observable trigger mechanism, and a hashrate vote is an easy way to do this. But at least, use a minimum timestamp you believe to be reasonable for upgrade, and a 100% threshold afterwards. Anything else guarantees that your forking change happens *knowingly* before the risk is gone. You may argue that miners would be asked to - and have it in their best interest - to not actually make blocks that violate the changed rule before they are reasonably sure that everyone has upgraded. That is possible, but it does not gain you anything over just using a 100% threshold, as how would they be reasonably sure everyone has upgraded, while blocks creater by non-upgraded miners are still being created? TL;DR: use a timestamp switchover for a hard fork, or add a block voting threshold as a means to keep humans in the loop, but if you do, use 100% as threshold. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 18:20, Jorge Timón wrote: On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Non-repudiation can be built on top of the payment protocol layer. Non-repudiation is an intrinsic property of the ECDSA signatures which Bitcoin uses - it's not a feature that needs to be built. There's no way to accidentally sign a transaction and accidentally announce it publicly. There is no form of third-party error that can result in a payee receiving an erroneous contract. Justus, We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity? Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction. Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.” - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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
On Jun 20, 2015, at 5:27 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 19:19, Eric Lombrozo wrote: On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 18:20, Jorge Timón wrote: On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Non-repudiation can be built on top of the payment protocol layer. Non-repudiation is an intrinsic property of the ECDSA signatures which Bitcoin uses - it's not a feature that needs to be built. There's no way to accidentally sign a transaction and accidentally announce it publicly. There is no form of third-party error that can result in a payee receiving an erroneous contract. Justus, We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity? Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction. Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.” Bitcoin has no concept of identity, but in any type of commercial transaction the parties involved must know some minimal amount of identity information in order to transact at all. Except for some identifiable special cases, I think a payee is perfectly justified in treating a double spend of a payment sent to them as part of a commercial transaction as a fraud attempt and employing whatever non-Bitcoin recourse mechanisms, if any, they have access to. From the perspective of the network, the obviously correct action for any node or miner is to relay the first version of any transaction they see. The primary purpose of mining is to resolve this otherwise-unresolvable problem of determining which transaction among a set of conflicting transactions happened first. If a node or miner wants to deviate from the obviously correct behaviour, and if they want to avoid harming the value of the network, they should be particularly careful to make sure their deviation from first seen doesn't introduce harmful unintended side effects, like making fraud easier. The contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event…but the behavior you’re claiming as “obviously correct” is NOT obviously correct. In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this…perhaps such relays could be flagged or placed in a special message type). - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-06-20 19:19, Eric Lombrozo wrote: On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 18:20, Jorge Timón wrote: On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Non-repudiation can be built on top of the payment protocol layer. Non-repudiation is an intrinsic property of the ECDSA signatures which Bitcoin uses - it's not a feature that needs to be built. There's no way to accidentally sign a transaction and accidentally announce it publicly. There is no form of third-party error that can result in a payee receiving an erroneous contract. Justus, We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity? Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction. Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.” Bitcoin has no concept of identity, but in any type of commercial transaction the parties involved must know some minimal amount of identity information in order to transact at all. Except for some identifiable special cases, I think a payee is perfectly justified in treating a double spend of a payment sent to them as part of a commercial transaction as a fraud attempt and employing whatever non-Bitcoin recourse mechanisms, if any, they have access to. - From the perspective of the network, the obviously correct action for any node or miner is to relay the first version of any transaction they see. The primary purpose of mining is to resolve this otherwise-unresolvable problem of determining which transaction among a set of conflicting transactions happened first. If a node or miner wants to deviate from the obviously correct behaviour, and if they want to avoid harming the value of the network, they should be particularly careful to make sure their deviation from first seen doesn't introduce harmful unintended side effects, like making fraud easier. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7 FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617 APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5 WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d 5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be 646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+ GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2 po6di9uOSlLq0BJJfSrM =HbNG -END PGP SIGNATURE- -- ___ 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
On Jun 20, 2015, at 4:47 PM, Eric Lombrozo elombr...@gmail.com wrote: On Jun 20, 2015, at 4:16 PM, Jorge Timón jti...@jtimon.cc wrote: On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo elombr...@gmail.com wrote: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time… I disagree with this premise. Please, don't take this as an argument from authority fallacy, but I will cite Satoshi to express what I think the assumptions while using the system should be: As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. I can't say for sure what was meant by attacking the network in this context but I personally mean trying to rewrite valid and proof-of-work-timestamped history. Unconfirmed transactions are simply not part of history yet. Ordering unconfirmed transactions in a consensus compatible way without a universal clock is impossible, that's why we're using proof of work in the first place. Alternative policies are NOT attacks on the network. Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case. - Eric Lombrozo I think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side. - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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
Has anyone from Mycelium weighed in on this? Is their doublespend attack detection broken with this kind of irresponsible behavior? On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: 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. Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. The reason we don't yet see such technology permeating the ecosystem is because, to date, zero-conf transactions have been irreversible enough, but this has only been a happy accident; it was never promised, and it should not be relied upon. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- *MONEY IS OVER!* IF YOU WANT IT http://www.zeitgeistmovie.com/ = The causes of my servitude can be traced to the tyranny of money. -Serj Tankian -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
On Fri, Jun 19, 2015 at 12:47 PM, Adam Weiss a...@signal11.com wrote: Hi Warren, If you set dmarc_moderation_action to Munge from, the list will detect when someone posts from a domain that publishes a request for strict signature checking for all mails originating from it (in DNS) and rewrite the envelope-from to the list's address. Reply-to will be added and set to the original sender. That seems to change Reply behavior for those recipients? It would seem to accidentally direct mail intended to DKIM-user + list to DKIM-user. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Remove Us Please
You're only strengthening Gigas' point about the mailing list by posting derisive emails. Take your nonconstructive comments elsewhere. - Jameson On Fri, Jun 19, 2015 at 4:01 PM, Brian Hoffman brianchoff...@gmail.com wrote: damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus. On Jun 19, 2015, at 3:55 PM, John Bodeen john-bod...@uiowa.edu wrote: from their website, humorous bits highlighted *October 14, 2014 *In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided it would be a good investment to launch its own coin and back it itself. The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015. Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project. On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp jameson.l...@gmail.com wrote: You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. corpor...@gigasgaming.com wrote: This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain. Is there a canonical implementation of FSS RBF around somewhere I can review? Best, -jp -- Jeffrey Paul +1 (312) 361-0355 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2 On 19.06.2015, at 15:52, Chun Wang 1240...@gmail.com wrote: 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
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: 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. Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. The reason we don't yet see such technology permeating the ecosystem is because, to date, zero-conf transactions have been irreversible enough, but this has only been a happy accident; it was never promised, and it should not be relied upon. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Remove Us Please
damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus. On Jun 19, 2015, at 3:55 PM, John Bodeen john-bod...@uiowa.edu wrote: from their website, humorous bits highlighted October 14, 2014 In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided it would be a good investment to launch its own coin and back it itself. The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015. Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project. On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp jameson.l...@gmail.com mailto:jameson.l...@gmail.com wrote: You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. corpor...@gigasgaming.com mailto:corpor...@gigasgaming.com wrote: This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
I'm not sure I understand your question about the need to store paths in the wallet database -- there's no way to infer the path of an address inside an HD wallet from the address alone (short of an exhaustive search), and HD wallets need to store either the paths, addresses, or both that have been previously derived/used to monitor the blockchain usefully, but those facts aren't new or specific to this path format. The motivation for this path structure over standard bip44 is that it separates the concept of network (or which blockchain I'm using) and coin_type (or what kind of thing I'm sending over that blockchain). This is useful, for example, if I want to import a wallet into my application and I know that an account was in use at m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty - I only need to check the addresses derived below that path for balances against counterpartyd. It may be worth pointing out that I expect multisig HD wallet imports to require master keys and a list of account paths – not a list of addresses, as it's very possible that a new address could be derived between the time when the wallet data was exported and when it will be imported. This use case might be very specific to our model, but the reason I figured we should request a BIP # for this is that to start using it, we need to pick a number for the purpose field and don't want to do it arbitrarily (and risk having to change it later) or overload 44 (which would be misleading). Did I either a) answer or b) misunderstand your questions? -- Matt Smith | Gem https://gem.co | GH: @thedoctor On 6/19/15 2:25 PM, Matt @ Envrin Group wrote: Hi Matt, I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers. I'm a little uncertain as to the relevance though. All those variables (purpose, network, asset_type, account, change, index) need to be stored internally within the wallet database, as there's no way to retrieve the path used from just the address, correct? In that case, what's the meaning of that exact path structure when a) it can't be retrieved from just the address, and b) the values will be stored internally within the wallet when you lookup the address. Matt signature.asc Description: OpenPGP digital signature -- ___ 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
What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. Aaron Voisine co-founder and CEO breadwallet.com On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach m...@friedenbach.org wrote: What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at wrote: I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote: They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. They never will be. You can get a decent rate of success merely by making one transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg, 1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason unconfirmed transactions aren't double spent today is because nobody is seriously *trying*. Luke -- ___ 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
What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at wrote: I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
It all comes down to managing risk. If you’ve got a decent risk model with capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine. But most payment processors and merchants right now probably don’t have particularly good risk models and are making many dangerous assumptions…and probably would not be able to gracefully handle very many risk scenarios. - Eric Lombrozo On Jun 19, 2015, at 6:23 PM, Aaron Voisine vois...@gmail.com wrote: What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. Aaron Voisine co-founder and CEO breadwallet.com http://breadwallet.com/ On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at mailto:andr...@petersson.at wrote: I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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 -- ___ 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
I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. 0xAA4EDEEF.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty What is stopping you from using m/44'/9'/a'/c/i as descibed here: http://doc.satoshilabs.com/slips/slip-0044.html to avoid having an internal mapping from 9'- 0' to find out what blockchain to query, this sounds like it should be trivial for any wallet. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which is what your proposed path structure would be, and it results in the address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w. When the wallet notices a transaction in the blockchain that has 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an output, it's going to have to lookup the address within its database to get the values 6/4/7/99/0/196, as there's no way to retrieve them from just the address. So technically, you might as well just use m/account'/change/index if using hardened child keys, or m/change/index if not, as recommended, because the wallet will still function the exact same way. Matt On 06/20/2015 06:31 AM, Matt Smith wrote: I'm not sure I understand your question about the need to store paths in the wallet database -- there's no way to infer the path of an address inside an HD wallet from the address alone (short of an exhaustive search), and HD wallets need to store either the paths, addresses, or both that have been previously derived/used to monitor the blockchain usefully, but those facts aren't new or specific to this path format. The motivation for this path structure over standard bip44 is that it separates the concept of network (or which blockchain I'm using) and coin_type (or what kind of thing I'm sending over that blockchain). This is useful, for example, if I want to import a wallet into my application and I know that an account was in use at m/##'/0'/99'/0' where 99 is the identifier for, say, counterparty - I only need to check the addresses derived below that path for balances against counterpartyd. It may be worth pointing out that I expect multisig HD wallet imports to require master keys and a list of account paths – not a list of addresses, as it's very possible that a new address could be derived between the time when the wallet data was exported and when it will be imported. This use case might be very specific to our model, but the reason I figured we should request a BIP # for this is that to start using it, we need to pick a number for the purpose field and don't want to do it arbitrarily (and risk having to change it later) or overload 44 (which would be misleading). Did I either a) answer or b) misunderstand your questions? -- Matt Smith | Gem https://gem.co | GH: @thedoctor On 6/19/15 2:25 PM, Matt @ Envrin Group wrote: Hi Matt, I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers. I'm a little uncertain as to the relevance though. All those variables (purpose, network, asset_type, account, change, index) need to be stored internally within the wallet database, as there's no way to retrieve the path used from just the address, correct? In that case, what's the meaning of that exact path structure when a) it can't be retrieved from just the address, and b) the values will be stored internally within the wallet when you lookup the address. Matt -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On 6/19/2015 6:43 AM, Mike Hearn wrote: No surprise, the position of Blockstream employees is that hard forks must never happen and that everyone's ordinary transactions should go via some new network that doesn't yet exist. If my company were working on spiffy new ideas that required a hard fork to implement, I'd be rather dismayed to see the blocksize hard fork happen *before those ideas were ready*. Because then I'd eventually have to convince people that those ideas were worth a hard fork all on their own. It would be much easier to convince people to roll them in with the already necessary blocksize hard fork, if that event could be delayed. As far as I know, Blockstream representatives have never said that waiting for other changes to be ready is a reason to delay the blocksize hard fork. So if this were the real reason, it would suggest they have been hiding their true motives for making such a fuss about the blocksize issue. I've got no evidence at all to support thoughts like this... just the paranoid mindset that seems to infect a person who gets involved in bitcoin. But the question is every bit as valid as Adam's query into your motives. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
I don’t think the issue is between larger blocks on the one hand and things like lightning on the other - these two ideas are quite orthogonal. Larger blocks aren’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and will likely need to move to a model where it isn’t necessary for everyone to validate everyone else’s latte purchases. Larger blocks might, at best, keep the current system chugging along temporarily - although I’m not sure that’s necessarily such a great thing…we need to create a fee market sooner or later, and until we do this, block size issues will continue to crop up again and again and economic incentives will continue to be misplaced. It would be nice to have more time to really develop a good infrastructure for this…but without real market pressures, I’m not sure it will happen at all. Necessity is the mother of invention, after all. The question is how to introduce a fee market smoothly and with the overwhelming consensus of the community - and that's where it starts to get tricky. —— On a separate note, as several others have pointed out in this thread (but I wanted to add my voice to this as well), maintenance of source code repositories is NOT the real issue here. The bitcoin/bitcoin project on github is a reference implementation of the Satoshi protocol…but it is NOT the only implementation…and it wasn’t really meant to be. Anyone is free to fork it, extend it, improve upon it, or create an entirely new network with its own genesis block…a separate cryptoledger. The real issue regarding XT is NOT the forking of source code nor issues surrounding commit access to repositories. The real issue is the *forking of a cryptoledger*. Open source repositories are meant to be forked - in fact, it is often encouraged. It is also encouraged that improvements be submitted for review and possibly merged back into the parent repository…although this doesn’t always happen. However, we currently have no mechanisms in place to support merging of forked cryptoledgers. Software, and most other forms of digital content, generally increases in value with more copies made. However, money is scarce…by design. The entire value of the assets of a decentralized cryptoledger rests on the assumption that nobody can just unilaterally fork it and change the rules. Yes, convincing other people to do things a certain way is HARD…yes, it can be frustratingly slow…I’ve tried to push for many changes to the Bitcoin network…and have only succeeded a very small number of times. And yes, it’s often been quite frustrating. But trying to unilaterally impose a change of consensus rules for an existing cryptoledger sets a horrendous precedent…this isn’t just about things like block size limits, which is a relatively petty issue by comparison. It would be very nice to have a similar workflow with consensus rule evolution as we do with most other open source projects. You create a fork, demonstrate that your ideas are sound by implementing them and giving others something that works so they can review them, and then merge your contributions back in. However, the way Bitcoin is currently designed, this is unfortunately impossible to do this with consensus rules. Once a fork, always a fork - a.k.a. altcoins. Say what you will about how most altcoins are crap - at least most of them have the decency of starting with a clean ledger. - Eric Lombrozo On Jun 18, 2015, at 5:57 PM, Chris Pacia ctpa...@gmail.com wrote: On 06/18/2015 06:33 PM, Mark Friedenbach wrote: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. One of my biggest concerns is that these solutions (lightning network in particular) could end up being worse, in terms of decentralization, than would be a bitcoin network using larger blocks. We don't exactly know what the economies of scale are for pay hubs and could very well end up with far fewer hubs than nodes at any conceivable block size. Of course, it could also turn out to be fantastic, but it seems like an enormous gamble to basically force everyone in the ecosystem to collectively spend millions of dollars upgrading to Lightning and then see whether it's actually an improvement in terms of decentralization. To me, a much more sane approach would be to allow people to voluntarily opt in to those other solutions after we've had an opportunity to experiment with them and see how they actually function in practice, but that can't happen if the network runs out of capacity first.
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote: Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. No worries, let me know if you have any issues. You have my phone number. While my own preference - and a number of other devs - is full-RBF, either one is a good step forward for Bitcoin. -- 'peter'[:-1]@petertodd.org 03188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab signature.asc Description: Digital signature -- ___ 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
On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote: I just sent the following email to F2Pool: I was disappointed to see Peter Todd claiming that you have (or will?) run his replace-by-fee patch. I strongly encourage you to wait until most wallet software supports replace-by-fee before doing that, because until that happens replace-by-fee just makes it easier to steal from bitcoin-accepting merchants. Do you mean just full-RBF, or FSS-RBF as well? 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. Equally if anyone else from Coinbase would like to chime in that'd be great. -- 'peter'[:-1]@petertodd.org 0d7110f3a176228445ed710afd332291384992ed89c5c1a7 signature.asc Description: Digital signature -- ___ 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
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] Mailman incompatibility with DKIM ...
On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn m...@plan99.net wrote: We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I still see footers being added to this list by SourceForge? The new list currently has footers removed during testing. I am not pleased with the need to remove the subject tag and footer to be more compatible with DKIM users. Opinions? I've asked Jeff to not use his @bitpay.com account for now. I'm guessing DKIM enforcement is not very common because of issues like this? It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's. LF seems to pass along their mail but mangles the header/body and makes DKIM verification fail, which causes gmail to toss it into the spam folder. I think this behavior is slightly worse than Sourceforge because it makes the poster think their message was successfully sent (it is in the archive), but many subscribers never see it due to the spam binning. I don't see any good solution to this except an auto-reject for DKIM enforced domain postings. Yes this is rather terrible, but the instant rejection is vastly better than Sourceforge silently dropping the post or LF getting stuck in spam filters. We should also auto-reject any other reason for mail getting stuck in the moderation queue like including non-subscribers. I considered auto-rejecting spam too, but that could go horribly wrong as a false From address could make the Mailman server into a spammer itself. We may have no choice but to silently drop spam for that reason. Warren -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Yeah, but increasing block-size is not a longterm solution. Are you sure? That sort of statement is hard to answer because it doesn't say what you think long term is, or how much you expect Bitcoin to grow. Satoshi thought it was a perfectly fine long term solution because he thought hardware would get cheaper as fast or faster than Bitcoin would grow. You may disagree with him, but as we're talking about the future are you 100% certain he was wrong? I did calculations a long time ago that suggested even with today's hardware (+some software optimisations) it would be feasible to keep up with Visa. Hardware improvements can be unintuitive. There's a spreadsheet here that lets you play with various parameters. https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128 (note: the spreadsheet says avg txn size is 250 bytes, but if you check the formula for the middle column, it does actually use 500 bytes as the multiplier hard coded). Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a mechanism which matches supply and demand. That's not clear either, I'm afraid. Remember that there's an upper limit on how high Bitcoin fees can go. When fees become higher than what the banking system charges, many users won't use Bitcoin for moving money around anymore. Fees cannot really go much higher than that even if you assume the currency is still attractive for other reasons, because people would just sell their coins for fiat, move the fiat, and buy back the coins the other side. The way mining will be funded in future is an open question. There are differing proposals. Still, even with a higher hard block size limit, miners can always refuse to mine transactions that don't include a particular fee. So if you're worried about this, miners aren't being forced into any particular policy. -- ___ 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
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] F2Pool has enabled full replace-by-fee
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 not valid without mining itself, so you could end up in a situation where unless you're part of one of the big pools you can't reliably mine at all because your blocks may get rejected for containing doublespends. One of my goal with standard replace-by-fee is to prevent this scenario by forcing merchants and others to implement ways of accepting zeroconf transactions safely that work in a decentralized
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Hi Adam, I am still confused about whether you actually support an increase in the block size limit to happen right now. As you agree that this layer 2 you speak of doesn't exist yet, and won't within the next 10-12 months (do you agree that actually?), can you please state clearly that you will support Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but does/soon will have some code associated with it. But if we do no RD on layer2, and insist that clients can never change to become layer2 aware, and layer2 is too hard etc I think there's been some confusion here. I, at least, have never argued that other systems can *never* happen. Never is a long time, and I myself maintain a payment channels implementation. These things have their place. The argument is solely around the need to raise the block size *now* and not allow the existing layer 1 to gum up and fall over. If Stroem or Lightning or other block chains or Coinbase or secure hardware tokens or whatever take off and people start moving bitcoins around that way - fine. If they're choosing it of their own free will I have no issue with that, nor does anyone else, I suspect. However you don't seem fully confident that people actually will choose whatever is being cooked up as layer 2, if left to their own devices. Indeed it's impossible for anyone to know that, as no layer 2 actually exists. Any such implementation could have all sorts of flaws that lead to it not gaining traction. No offence but please find a way to gracefully stop and rejoin the constructive process. You can disagree on factors and points and be collaborative others disagree frequently and have done productive work cordially for years under the BIP process. As you know from the discussion with myself and Gavin a few days ago on IRC, neither of us believe any such constructive process exists. There is another thread to discuss the lack of such a process. - Did you accept payment from companies to lobby for 20MB blocks? Oh please. Conspiracy theories, now, Adam? My position has been consistent for years. I don't care whether the figure is 20 or something else (looks like it'll be lucky 8 instead), but I have always been clear that the limit must rise. But for the avoidance of doubt: the answer is no. Gavin is paid by MIT. The MIT deal gives Gavin complete independence. I am currently self employed and most of income comes from a client that is actually interested in Lighthouse. Luckily they have given me some leeway to do general Bitcoin development as well, which this business falls under. I would *much* rather be working on Lighthouse than this, and so would they. But seeing as you've gone there - let me flip this around. Blockstream has a very serious conflict of interest in this situation. I am by no means the first to observe this. You are building two major products: 1. Sidechains, a very complex approach to avoid changing the Bitcoin consensus rules to add new features. 2. Lightning, a so-called layer two system for transaction routing No surprise, the position of Blockstream employees is that hard forks must never happen and that everyone's ordinary transactions should go via some new network that doesn't yet exist. The problem is that rather than letting the market decide between ordinary Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin protocol because you don't trust people to spontaneously realise that they should be using your companies products. I know that many of you guys had these views before joining Blockstream. I am not saying you are being paid to have views you didn't previously have. I realise that birds of a feather flock together. Regardless, that conflict of interest DOES exist, whether you like it or not, because if you succeed in running Bitcoin out of capacity your own company stands to benefit from selling consulting and services around your preferred solutions. With respect to user rights: all the polling done so far suggests users who are paying attention strongly support increasing the block size. For example: Q: Should the bitcoin block size be raised in the next two years A: 92% yes http://www.poll-maker.com/results329839xee274Cb0-12#tab-2 Additionally, many Bitcoin users have explicitly delegated handling the technical details to someone else, like a payment processor or their wallet developers. Those people are nearly all sure that the block size limit should rise too. So please don't engage in idle speculation about users vs companies. They aren't some kind of opposing forces. Companies live for their users, and many of those companies were formed by long time Bitcoin users. And finally, the Bitcoin social contract is not defined by whatever random state the code was in at the time Gavin decided to focus on research. Both Gavin and I have been working on Bitcoin longer than you, Gregory or Peter Todd. The social contract was and still is defined by the
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 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
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
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 Andresen/Harding's double-spend relaying, implemented in Bitcoin XT. It relays up to one double-spend transaction per double-spent txout, with the intended effect to warn
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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 05a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc signature.asc Description: Digital signature -- ___ 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
Chun Wang 1240902 at gmail.com writes: Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. FSS RBF is better than no RBF but we think it is better to use full RBF. We think Full RBF is better for a number of reasons: -user experience -efficiency -cost -code complexity We think FSS RBF is great progress but ultimately less efficient and more complicated to keep alive something that never worked properly. And why would miner pick the option paying less when other miners run the option paying more? It may be soon more than 1-5% of block reward. A lot of users don't have multiple UTXO handy. Full RBF is the best, second FSS RBF and we'd be looking into supporting them both separately so that miners and users can pick whichever they prefer. If users only had one UTXO it makes sense to use Full RBF since there are no other options. Disclosure: GreenAddress always believed zero conf transactions are not secure and that miners have the incentive to run FBF; this bias doesn't make the above less true -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
IPv4 came before IPv6…you pick up on things quickly :) On Jun 19, 2015, at 5:48 AM, Marcel Jamin mar...@jamin.net wrote: At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook… And TCP/IP came before... oh wait... 2015-06-19 14:02 GMT+02:00 Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com: On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: That wont be good for the companies either, but they may not see that until they've killed it, many companies operate on a1 or 2 year time-horizon. They may say screw layer2, I have a runway and I need micropayments to the wazoo and I dont have the dev resources for that. Exactly, Adam. Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums. Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine. First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before we don’t know yet. - Eric Lombrozo -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
A lot of people think a layer2 is needed, that has a higher (algorithmic) scale in use of layer1 block-space but preserves functionality and uplifts security from layer1. An example would be lightning or similar. But there are many things that could be done. Pure offchain is a weak form of layer2. Its running today and maybe its handling 90-99% range of all transactions right now (mostly in exchanges for example). This layer can be incrementally hardened. It can also have standardised APIs across vendors of custodians, and opt-in support of those APIs in wallets. This would provide a convenience choice. Greenaddress also for low-mid assurances solves the unconfirmed transactions. It's probably not reasonable to expect bitcoin directly solve fast unconfirmed transactions. Probably intermediate configurations in complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig) and lightning may exist also. The internet doesnt stop at layer1. (Which would then leave people who are uninterested in changing client software to handle layer2, as layer1 will always be enough die-hards (in the refusing the future and facing the O(n^2) scaling wall or centralisation death with perplexing optimism :) Ok, not so constructive but maybe a gentle reminder that it is not constructive in the reverse direction either to throw around often false characterisations. We're here now to improve bitcoin so lets do that. What I said here seemed like it maybe subject to misinterpretation so to clarify: On 19 June 2015 at 11:22, Dr Adam Back a...@cypherspace.org wrote: For example it could hypothetically allow 10MB blocks on one chain and 100kB blocks on the main chain. People say complexity, scary. Sure I am talking longer term, but we have to also make concrete forward progress to the future or we'll be stuck here talking about perilously large constant changes in 5 years time! I should clarify that I meant there I was assuming we do one increase within the next 12 months frame that gives buffer for 5 years rd to improve things and build layer2. But if we do no RD on layer2, and insist that clients can never change to become layer2 aware, and layer2 is too hard etc then our risk would be we'd be back in the discussion of kicking the can afresh again in some years with some even more centralising size change. Sure we should make the transition and introduction to layer2 and an intermediate crunch smoother, but 20MB now or else isn't really helping. It did help get the conversation revived, but at this point its a hindrance. Seriously a big hindrance. No offence but please find a way to gracefully stop and rejoin the constructive process. You can disagree on factors and points and be collaborative others disagree frequently and have done productive work cordially for years under the BIP process. About scaling again: Here is what I said before in my TL;DR post about my thoughts on how we would start on throughput short-term to have space to do layer2 development. I think almost everybody is on board with a combination plan: 1. work to improve decentralisation (specific technical work already underway, and education) 2. create a plan to increase block-size in a slow fashion to not cause system shocks (eg like Jeff is proposing or some better variant) 3. work on actual algorithmic scaling In this way we can have throughput needed for scalability and security work to continue. As I said you can not scale a O(n^2) broadcast network by changing constants, you need algorithmic improvements. People are working on them already. All of those 3 things are being actively worked on right now, and in the case of algorithmic scaling and improve decentralisation have been worked on for months. Btw I wonder if Gavin or Mike would be willing to answer another question I forgot from my TL;DR post which was: - Did you accept payment from companies to lobby for 20MB blocks? Do you consider that something appropriate to publicly disclose if so? Do you consider that user rights should come above or below company interests in Bitcoin? FWIW on pondering that last question should user rights come above or below company interests I think my view of the guiding principle is starkly clear to me: that user rights should be the primary thing to optimise for. Businesses are providing service to users, their interests are secondary in so far as if they are enabled to provide better service thats good. Bitcoin is a user p2p currency, with a social contract and a strong user ethos. Importing and forcing company interests would likely be the start of a slippery slope towards an end to Bitcoin. If we allow business rights to be paramount it seems likely that we will end back at the status quo as bitcoin payment processors grow, conglomerate and become paypal/bank like or actual banks and then their interests and exposures are the same as the banks and they'll want to import their business models into
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back a...@cypherspace.org wrote: payment protocol layer in my view. (If thats not obvious to some lurkers I elaborate on that argument amongst other things here: https://www.youtube.com/watch?v=3dAdI3Gzodo ) Someone might find it more convenient to consume that in the form of text instead: http://diyhpl.us/wiki/transcripts/bitcoin-adam3us-fungibility-privacy/ - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fee Market Effects
A lot of standpoints for keeping the current block size are focused on creating a healthy fee market. I have some open questions for this list in regards to the user incentives of using bitcoin, when such a strong fee market is in place. In my scenario the average fee for a normal transactions will be around 1$ to put in on the blockchain with a reasonable confirmation time. 1. How will we get user adoptions if the fees on bitcoin transactions our not competitive with other services like PayPal and the like. (from a payment solution viewpoint) It is one of the main ‘pitch lines’ to get people to adopt bitcoin. “Send value to the other side of the world for almost 0 fees” 2. Many suggest the use of a level 2 layer will facilitate the scalability for bitcoin with technologies like the lightning network. But to my knowledge, all these solutions still need to publish to the actual blockchain when they need to settle. Meaning you will have to pay the fees at least once. In case of lightning this will be when the channel is closed. This means moves more to a monthly payed service, where you open a payment channel each month and pay the fee at the end. But a system like this keeps money locked for the duration of the channel. And one of the main ‘pitch’ point of the bitcoin economy was you get your money instantly, not at the end of the month when the payment channel is closed. 3. The idea of the fee market is people will start using the layer 2 systems. When this happens, what are the incentives to keep running a node? The incentives today are already quite small, the only real one is to support the network or make payments through your own trusted node. If you are only using a layer 2 solution, are there any reasons left to run my own bitcoin node, resulting in less decentralization. 4. Do we need a fee market right now? It seems to me the current block reward is still high enough for miners to be able to make money and secure the network. No real fee market is therefore needed to help these miners. Regardless of our opinion, why don’t we let the miners decide? The BIP100 proposal seems to do this. If the majority of miners decide they want bigger blocks they just vote for this. If they want a fee market because their return is enough, they can keep the limit and let the demand for more blockspace result in a higher fee market. Just some of my thoughts about the results of full blocks and the resulting fee market. It seems to me a strong fee market might hurt the young ecosystem more, then it might help it (miners are currently compensated enough). The same goes for decentralization, when people more their resources to the level 2 solution or stop using bitcoin due to the higher fees compared to comparable services. Cheers, Tim Witters -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
When is the right time to allow space pressure to rise that ratio? When the subsidy is at 1.5625, for example, it may be too late to I don¹t believe we have to decide, the miners will do that and are doing that already. start a non-catastrophic transition from subsidies to fees. I don't claim to know that, but it's something that worries me. No matter how many people say that's too far away in the future to worry about it, I still worry about it and I'm sure more people do. What if when it's time to care about it we discover that we should have started to do things about it long ago to minimize the risks of this transition? Hmmm. What should be the price of an email? How much should DARPA have charged for using TCP/IP? I see a lot of well-paid, first-world technologists arguing for commercial returns on a nacent protocol which could could offer benefits to the unbanked. Is that really the vision: to (re)build a de-centralized Paypal with slightly cheaper fees and cool hooks into off-chain commercial systems providing profits for the already rich? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn m...@plan99.net wrote: The new list currently has footers removed during testing. I am not pleased with the need to remove the subject tag and footer to be more compatible with DKIM users. Lists can do what are effectively MITM attacks on people's messages in any way they like, if they resign for the messages themselves. That seems fair to me! :) Mailman isn't resigning it. Should it be? Does other mailing list software? I'm guessing DKIM enforcement is not very common because of issues like this? DKIM is used by most mail on the internet. DMARC rules that publish in DNS statements like All mail from bitpay.com is signed correctly so trash any that isn't are used on some of the worlds most heavily phished domains like google.com, PayPal, eBay, and indeed BitPay. These rules are understood and enforced by all major webmail providers including Gmail. It's actually only rusty geek infrastructure that has problems with this, I've never heard of DKIM/DMARC users having issues outside of dealing with mailman. The vast majority of email users who never post to technical mailing lists benefit from it significantly. Really everyone should use them. Adding cryptographic integrity to email is hardly a crazy idea :) I understand the reason to protect the heavily phished domains. I heard that LKML does not modify the subject or add a footer, perhaps because it would make it incompatible with DKIM of the several big corporate domains who participate. I suppose it is somewhat acceptable for us to remove subject tags and footers if we have no choice... Warren -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Jun 19, 2015, at 2:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. By definition if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: some users will find their bitcoin savings have become uneconomic to spend. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. These sorts of complaints will get more frequent and more extreme in the coming months. I realise that nobody at Blockstream is in the position of running an end user facing service, but many of us are and we will be the ones that face the full anger of ordinary users as Bitcoin hits the wall. Mike, With all due respect, many of us DO run end user facing services…and would rather see a fundamental problem *fixed* rather than merely covered up temporarily…hoping nobody notices. The user experience of Bitcoin is already horrendous…unless you use a centralized validator web wallet. Even SPV is fundamentally broken (and I would have pegged you for being one of the people most directly aware of this fact). If we’re going for centralized validation, why even use a blockchain in the first place? We already have much faster, more efficient technology that can do that kind of stuff at a fraction of the cost. If you have well-established entities running banking services, we have other mechanisms in place that can help keep them honest…other far more efficient protocols. We’re basically defeating the very purpose of this invention. Then there are a bunch of other “inconveniences” about the way Bitcoin currently works. For instance, have you ever received a bunch of small payments (i.e. a crowdsale) and then found yourself in the position of having to suddenly move a big chunk of that on the blockchain…only to discover all the txouts you were spending added up to hundreds of kB or more? Or have you ever had to send a small payment but only had one large output in your wallet…which meant that the entirety of those funds were tied up until the first transaction got signed and propagated? Yes, the protocol has MANY serious issues…of which the “send and forget” fee model as opposed to the “send and bid model” is just one. Bitcoin was designed from the beginning with the idea that sooner or later fees would be a significant component of the network. The problem was never really fully addressed and solved - I’m glad to see that finally some good people in this space are starting to seriously think about solutions. Mike, are you telling us you’d rather avoid user complaints at all costs even if that means building something shitty for them that doesn’t really serve its stated purpose? If those are your standards then no thanks, I don’t want to be part of your fork. And I don’t think I’m alone in this sentiment. - Eric Lombrozo -- ___ 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: That wont be good for the companies either, but they may not see that until they've killed it, many companies operate on a1 or 2 year time-horizon. They may say screw layer2, I have a runway and I need micropayments to the wazoo and I dont have the dev resources for that. Exactly, Adam. Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums. Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine. First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before we don’t know yet. - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Yeah, but increasing block-size is not a longterm solution. Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a mechanism which matches supply and demand. On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. By definition if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: some users will find their bitcoin savings have become uneconomic to spend. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. These sorts of complaints will get more frequent and more extreme in the coming months. I realise that nobody at Blockstream is in the position of running an end user facing service, but many of us are and we will be the ones that face the full anger of ordinary users as Bitcoin hits the wall. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Benjamin, Timeframe for network congestion and users experiencing service degradation = between now and middle of next year. Timeframe for transaction fees topping block reward fees = many years in the future, based on current ratio of block reward to fees. What is the more pressing requirement now? A working ³fee market² or a reliable, useful payment network that scales without falling over in the next 2-3 years. On 19/6/15 4:53 pm, Benjamin benjamin.l.cor...@gmail.com wrote: Yeah, but increasing block-size is not a longterm solution. Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a mechanism which matches supply and demand. On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. By definition if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: some users will find their bitcoin savings have become uneconomic to spend. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to _pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. These sorts of complaints will get more frequent and more extreme in the coming months. I realise that nobody at Blockstream is in the position of running an end user facing service, but many of us are and we will be the ones that face the full anger of ordinary users as Bitcoin hits the wall. - - ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] F2Pool has enabled full replace-by-fee
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 Andresen/Harding's double-spend relaying, implemented in Bitcoin XT. It relays up to one double-spend transaction per double-spent txout, with the intended effect to warn recipients. In practice however this functionality makes it easier to double-spend rather than harder, by giving an efficient and easy way to get double-spends to miners after the fact. Notably my RBF implementation even connects to Bitcoin XT nodes, reserving a % of all incoming and outgoing connection slots for them. Additionally Bitcoin XT's double-spend relaying is subject to attacks include bandwidth exhaustion, sybil
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. By definition if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: some users will find their bitcoin savings have become uneconomic to spend. He doesn't mean that: he means solving the mempool and crashes and hitting the limit would have. If the chain has limited size it is a scarce resource and people have to bid for it: nothing unexpected or wrong about that. Of course, people that believe the limit should be completely removed eventually because they don't care about mining being decentralized (or fail to see the relation between the two) may have a very different view about this. On Fri, Jun 19, 2015 at 12:08 PM, GC slashdevn...@hotmail.com wrote: Timeframe for transaction fees topping block reward fees = many years in the future, based on current ratio of block reward to fees. Do you think that this ratio is unrelated to an abundant (non-scarce) block size? When is the right time to allow space pressure to rise that ratio? When the subsidy is at 1.5625, for example, it may be too late to start a non-catastrophic transition from subsidies to fees. I don't claim to know that, but it's something that worries me. No matter how many people say that's too far away in the future to worry about it, I still worry about it and I'm sure more people do. What if when it's time to care about it we discover that we should have started to do things about it long ago to minimize the risks of this transition? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: *some users will find their bitcoin savings have become uneconomic to spend*. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. Has there been any talk about reducing the time between blocks? If blocks were allowed to come twice as fast, they would be able to clear pending transactions in the mempool the same as if the block size doubled, but would allow mining to stay more decentralized since miners wouldn't be working on such large-scale blocks? It would still take more storage space to store the blockchain, though. Brooks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
Mailman isn't resigning it. Should it be? Does other mailing list software? Mailman must take responsibility for the mail itself. It doesn't have to actually sign with DKIM to do so: for backwards compatibility, spam filters fall back to other heuristics to try and figure out the 'owner' of the mail if it doesn't use DKIM. Those heuristics can go wrong of course. Ideally all mail would be DKIM signed. There's no reason not to do it, really. Yes mailing lists that edit people's emails resign. For example, from a recent message to the bitcoinj list DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; *d=googlegroups.com http://googlegroups.com*; s=20120806; h=to:from:subject:date:lines:message-id:references:mime-version :content-type:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; I suppose it is somewhat acceptable for us to remove subject tags and footers if we have no choice... Good email clients can extract the same information from the headers anyway. I filter all my mail based on them, and the headers also contain unsubscribe instructions. Gmail is capable of using them programmatically. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Mailman incompatibility with DKIM ...
Both you and jgarzik experienced mail getting tossed into gmail's spam folder thanks to DKIM... I am concerned that DKIM is too fragile and not very compatible with mailing lists. We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I am already concerned that the lack of the Mailman footer will make it hard to identify where exactly subscribers need to go to unsubscribe or look at archives. Removing the subject tag might make DKIM enforcement work a lot better, but I can easily see our obtuse subscribers as being extra confused by this. Opinions? Warren On Thu, Jun 18, 2015 at 11:38 PM, Arthur art...@powaaa.com wrote: warren | bad_duck: try manually adding [Bitcoin-dev] to the beginning of the subject -- Arthur -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Nicely put Eric. Relatedly my initial experience with Bitcoin in trying to improve bitcoin in fungibility, privacy decentralisation, I found some interesting things, like Confidential Transactions (that Greg Maxwell has now optimised via a new generalisation of the hash-ring signature construct he invented and with Pieter made part of the alpha side-chain release) and a few other things. As I went then to discuss and learn: a) what are the characteristics needed for inclusion (clearly things need to fit in with how things work, not demand massive rewrites to accommodate and to not conflict with existing important design considerations), so that I could make proposals in a practically deployable way, and then b) the practicality of getting a proposed change that say people found clearly useful. Then I bumped into the realisation that this is actually really high risk to change, and consensus critical coding security is very complex and there are some billion $ resting on getting this rigidly correct under live conditions, so that deployment must be cautious and incremental and rigorously tested. So then I focussed instead on question of whether we could improve bitcoins development model: how could we allow bitcoin to more rapidly and agilely test beta features or try novel things to see how they would work (as someone might do in a feature branch of a normal FOSS project, to code and test a proposal for later addition), but with criteria we want real bticoins so there is economic incentive as that is actually part of the bitcoin protocol so you've not validated something unless you're run it in a real network with money. I was hypothesising therefore we need a way to run bitcoin beta network. There's a thread about this here stretching back to may 2013. Or similarly to run in parallel kind of subnets with different trade-offs or features that are not easy to merge or high risk to apply all at once to bitcoin with the inflight billions in capital and transactions on it. Anyway I thought that was a productive line of thinking, and generally people seemed to agree and problem statement of 2wp: then 1wp mechanism was proposed and then Greg extracted a concept from his SNARK witness idea (which encapsulates a snark variant of a 2wp) but now without snarks, then 2wp a conservative crypto 2wp proposal was made. This was dec 2013 I think on wizards channel. The sidechain alpha release now makes this a (alpha quality and so testnet coin, and without DMMS peg) reality. I could imagine others who have a desire to try things could elect to do so and copy that patch-set and make more side-chains. This is inherently non-coercive because you largely do not directly change bitcoin by doing this, people elect to use which ever chain suits them best given their usecase. If the sidechain is really early stage it should have test-net coins in it not bitcoins in it, but still its caveat emptor kind of beta chain, with good testing but non-trivial to soft-fork on bitcoin but managable refactor a sidechain to integrate something novel or try some existing feature (like the segregated witness which robustly addresses malleability for example) So I dont want to say side-chains are some magical solution to everything, but its a direction that others may like to consider for how to test or even run alternative trade-offs bitcoin side-chains in parallel. For example it could hypothetically allow 10MB blocks on one chain and 100kB blocks on the main chain. People say complexity, scary. Sure I am talking longer term, but we have to also make concrete forward progress to the future or we'll be stuck here talking about perilously large constant changes in 5 years time! This approach also avoids the one-size fits all problem. Extension-blocks are an in-chain sub-net type of thing that has a security boost by being soft-fork enforced (relative to side-chains which are looser coupled and so more flexible relative to the simplest form of extension-blocks) Adam On 19 June 2015 at 07:59, Eric Lombrozo elombr...@gmail.com wrote: I don’t think the issue is between larger blocks on the one hand and things like lightning on the other - these two ideas are quite orthogonal. Larger blocks aren’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and will likely need to move to a model where it isn’t necessary for everyone to validate everyone else’s latte purchases. Larger blocks might, at best, keep the current system chugging along temporarily - although I’m not sure that’s necessarily such a great thing…we need to create a fee market sooner or later, and until we do this, block size issues will continue to crop up again and again and economic incentives will continue to be misplaced. It would be nice to have more time to really develop a good infrastructure for this…but without real market pressures, I’m not sure it will happen at all.
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: *some users will find their bitcoin savings have become uneconomic to spend*. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. These sorts of complaints will get more frequent and more extreme in the coming months. I realise that nobody at Blockstream is in the position of running an end user facing service, but many of us are and we will be the ones that face the full anger of ordinary users as Bitcoin hits the wall. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I still see footers being added to this list by SourceForge? Opinions? I've asked Jeff to not use his @bitpay.com account for now. The only real fix is to use a mailing list operator that is designed to operate correctly with DKIM/DMARC, either by not modifying messages in transit, or by re-sending (and ideally re-signing) under their own identity. Though I'm sure this won't be an issue for the Linux Foundation, the latter approach is dangerous because it means the list operator takes full responsibility for any spamming that occurs from that domain. If the mail server is ever hacked or spammers start posting to the lists themselves, all that spam will be seen as originating from the listserv itself and the reputation will be degraded. It can end with everyone's mail going to the spam folder. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
The new list currently has footers removed during testing. I am not pleased with the need to remove the subject tag and footer to be more compatible with DKIM users. Lists can do what are effectively MITM attacks on people's messages in any way they like, if they resign for the messages themselves. That seems fair to me! :) I'm guessing DKIM enforcement is not very common because of issues like this? DKIM is used by most mail on the internet. DMARC rules that publish in DNS statements like All mail from bitpay.com is signed correctly so trash any that isn't are used on some of the worlds most heavily phished domains like google.com, PayPal, eBay, and indeed BitPay. These rules are understood and enforced by all major webmail providers including Gmail. It's actually only rusty geek infrastructure that has problems with this, I've never heard of DKIM/DMARC users having issues outside of dealing with mailman. The vast majority of email users who never post to technical mailing lists benefit from it significantly. Really everyone should use them. Adding cryptographic integrity to email is hardly a crazy idea :) It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's. It's not SourceForge, it's your spam filter. His mail gets through to me but it's all in the spam folder. -- ___ 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
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] F2Pool has enabled full replace-by-fee
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 15:11, Peter Todd wrote: If you ask me to pay you 1BTC at address A and I create tx1 that pays 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not defrauding you, I'm just reducing the value of my change address to pay a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C. Yet from the point of view of an external observer they have no idea why the transaction outputs reduced in size, nor any way of knowing if fraud did or did not occur. If there are two transactions which spend the same inputs, and each transaction has completely different output scripts, then this is prima facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie If the two transactions have identical output scripts, and one output is reduced in value to increase the transaction fee, that has the appearance of honest dealing. There is a possibility that the payer has chose to under-pay their payee in order to over-pay the miner, but that's not what a reasonable observer would assume at first glance. Adding outputs to a transaction, while keeping all the existing outputs exactly how they are is another way of increasing the transaction fee of a transaction and is prima facie non-fraudulent. Note that child-pays-for-parent has none of this ambiguity. What do you think of Bitcoin XT then? It relays double-spends, which makes it much easier to get double-spends to miners than before. In particular you see a lot of zero-fee transactions being replaced by fee-paying transactions, relayed through Bitcoin XT nodes and then mined. Is that encouraging fraud? I haven't closely looked into the features of Bitcoin XT because I'm hoping that it never becomes relevant. I do want to see a heterogenous implementation network develop, but Bitcoin XT doesn't really count since it's a derivative of the Bitcoin Core codebase. In general, I think every signed Bitcoin transaction sent between different parties is part of a valid, enforceable contract (using common law definitions which predate any particular legal jurisdiction). Handling contracts and money is Serious Business and so the decision of how software should respond to double spends should not be made frivolously. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1 7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ 4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7 xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u 8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl uEW4Vcn+HxlNI/rhxBw4 =odRL -END PGP SIGNATURE- -- ___ 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
Yes, FSS RBF is far better. On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang 1240...@gmail.com wrote: 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
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
OK, a few things here: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked…and lack a proper recovery plan. Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint…where signing multiple conflicting blocks results in loss of one’s funds…then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address. Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds…they must remain in limbo forever. - Eric Lombrozo On Jun 19, 2015, at 8:11 AM, Peter Todd p...@petertodd.org wrote: On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote: On 2015-06-19 10:39, 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. Intentional fraud is a bad thing to add to a financial protocol. A user who creates conflicting transactions, one that pays someone else and another which does not pay them, and broadcasts both of them, has just self-incriminated themselves by producing prima facie evidence of fraud. Depends. If you ask me to pay you 1BTC at address A and I create tx1 that pays 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not defrauding you, I'm just reducing the value of my change address to pay a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C. Yet from the point of view of an external observer they have no idea why the transaction outputs reduced in size, nor any way of knowing if fraud did or did not occur. Equally, maybe you tell me Actually, just give me 0.5BTC to cancel out that debt, in which case I'm not breaking any contract at all by giving you less money than I first promised - the contract has changed. Again, none of this can or should be observable to anyone other than the parties directly involved. It may be the case that since Bitcoin spans multiple legal jurisdictions and can be use anonymously that the victims of such fraud can not rely on legal recourse, and it may also be the case that proof of work is how Bitcoin deals with the aforementioned factors, but regardless un-prosecutable fraud is still fraud and anyone who encourages it should be recognied as a bad actors. Committing vandalism and encouraging fraud to prove a point may be something the network can't stop on a technical level, but there's no reason not to call it out for what it is. What do you think of Bitcoin XT then? It relays double-spends, which makes it much easier to get double-spends to miners than before. In particular you see a lot of zero-fee transactions being replaced by fee-paying transactions, relayed through Bitcoin XT nodes and then mined. Is that encouraging fraud? -- 'peter'[:-1]@petertodd.org 03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717 -- ___ 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 -- ___ 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
On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote: On 2015-06-19 10:39, 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. Intentional fraud is a bad thing to add to a financial protocol. A user who creates conflicting transactions, one that pays someone else and another which does not pay them, and broadcasts both of them, has just self-incriminated themselves by producing prima facie evidence of fraud. Depends. If you ask me to pay you 1BTC at address A and I create tx1 that pays 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not defrauding you, I'm just reducing the value of my change address to pay a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C. Yet from the point of view of an external observer they have no idea why the transaction outputs reduced in size, nor any way of knowing if fraud did or did not occur. Equally, maybe you tell me Actually, just give me 0.5BTC to cancel out that debt, in which case I'm not breaking any contract at all by giving you less money than I first promised - the contract has changed. Again, none of this can or should be observable to anyone other than the parties directly involved. It may be the case that since Bitcoin spans multiple legal jurisdictions and can be use anonymously that the victims of such fraud can not rely on legal recourse, and it may also be the case that proof of work is how Bitcoin deals with the aforementioned factors, but regardless un-prosecutable fraud is still fraud and anyone who encourages it should be recognied as a bad actors. Committing vandalism and encouraging fraud to prove a point may be something the network can't stop on a technical level, but there's no reason not to call it out for what it is. What do you think of Bitcoin XT then? It relays double-spends, which makes it much easier to get double-spends to miners than before. In particular you see a lot of zero-fee transactions being replaced by fee-paying transactions, relayed through Bitcoin XT nodes and then mined. Is that encouraging fraud? -- 'peter'[:-1]@petertodd.org 03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717 signature.asc Description: Digital signature -- ___ 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
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org wrote: 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 This is no excuse for further degrading the overall network security. There are many issues to address in the bitcoin ecosystem. It negatively impacts users to roll out scorched earth replace-by-fee given today's ecosystem. Yes, zero conf security is poor. An outright attack on zero conf degrades user security even more. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 10:39, 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. Intentional fraud is a bad thing to add to a financial protocol. A user who creates conflicting transactions, one that pays someone else and another which does not pay them, and broadcasts both of them, has just self-incriminated themselves by producing prima facie evidence of fraud. It may be the case that since Bitcoin spans multiple legal jurisdictions and can be use anonymously that the victims of such fraud can not rely on legal recourse, and it may also be the case that proof of work is how Bitcoin deals with the aforementioned factors, but regardless un-prosecutable fraud is still fraud and anyone who encourages it should be recognied as a bad actors. Committing vandalism and encouraging fraud to prove a point may be something the network can't stop on a technical level, but there's no reason not to call it out for what it is. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhCsXAAoJECpf2nDq2eYjA08P/ApDFcIGws55TsgDFxPhDpN+ Iq9a06mPbXVjUfRxP5ZwmJuiM+XzHQ4QL3C2BH0OETatIV+bh7GP2mGHPcUAISYt 1j4TKhurnC+mqN+YAsiI5hQsws8DvPYXBTYYn0savaJTbq6/Q77+xvfRgNxofcPW EHpnl/5wcmYGgp3mVyStGJ+qIP17yywzCLnSA3WEPaZG/9/FPrIq3Ptw2+RHod79 nzDiFBiKLK8E5NPbdbXS+gkjkkBA/QeCzZObpMOeWMriu/PIifVi8KssLSznnEwx r7hiv6ISW47BTzkRbjxmXmGep3wfl8MjH7BZq3g0uyiApMdmjohIJ2lyuvOXdh7s 47+4r2xA8gG+z0aQTmCx5TS75T0Hnj3I78ZtCVr31Ip2OLbNI1mQ2gPR2zaoZkUZ atp2XCssHDlY2s30k5hAnIHxuN6CkyGkZCECSuv46Z3ok6ll/nIP80qB7BBzVlP1 xfSOPZh57J31U8PxZBZcwgdRg+HBiExvg484grE+h18izxcrjNfPRSWP4+7nEZtK LN7JL7YcmhVfhqKTSd6+C4bD2LsKsrcMiUhH1xHkD/hzAxc7egL6lgYTHJjU+yPu BTIh0VHJxBgroHB45Vq6loa4B3l4ZCl4Ykw8Opm7NJIfueJ0l0ySyJXi6ix4bjVf ZRF0Ot9RP0M0fHEwOpT6 =s0w/ -END PGP SIGNATURE- -- ___ 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
On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote: 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. 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. You realise how the fact that F2Pool is using full-RBF right now does strongly suggest that the chances of a double-spend are not only low, but more importantly, vary greatly? Any small change in relaying policy or even network conditions creates opportunities to double-spend. 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). 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. 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. -- 'peter'[:-1]@petertodd.org 0fe727215265d9ddacb2930ad2d45920b71920b7aed687f1 signature.asc Description: Digital signature -- ___ 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 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] F2Pool has enabled full replace-by-fee
This is very disappointing. scorched earth replace-by-fee implemented first at a pool, without updating wallets and merchants, is very anti-social and increases the ability to perform Finney attacks and double-spends. The community is progressing more towards a safer replace-by-fee model, as indicated by the following code change: https://github.com/bitcoin/bitcoin/pull/6176 On Fri, Jun 19, 2015 at 3: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 Andresen/Harding's double-spend relaying, implemented in Bitcoin XT. It relays up
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
On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd 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: Incidentally, because someone asked that message was sent two weeks ago. Also, a shout-out to Marshal Long of FinalHash for his help with (FSS)-RBF deployment and for getting F2Pool and myself in touch, as well as his work in talking getting pools on board with BIP66. -- 'peter'[:-1]@petertodd.org 0bb4abd88c6b023e9f19a1c1deaac120467279c330a803cf signature.asc Description: Digital signature -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 16:36, Matt Whitlock wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. If we have ECDSA proof that an entity intentionally made and publicly announced incompatible promises regarding the disposition of particular Bitcoins under their control, then why shouldn't that be assumed to be a fraud attempt unless shown otherwise? There are ways of achiving transaction fee adjustment after broadcast that do not present the appearance of, or opportunity for, fraud. If those options are available and the user chooses not to use them in favor of the option that does, that makes bad intentions even more probable. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhEasAAoJECpf2nDq2eYjcwIP/25yoRpNvZkkdFfYiBKaiL/g XRH8iFAyM5q3/75sA23vD/fzCNGIRRWYyp8PWk+23NF1gdsgVU6gFNNCUmDbjANv nWTt2Bd926St24jcU+OxMewSGlxpenDSFDNQVtxhNFKst6hoPatwK1Zfa0Eq7/Qw +r0H2Pse1ulrN4P1n5xnrYMq2w/GF3zinNZbrn2KOZCnsDa8lKlP8y9eNFHBJ//Z wDrOcfZ1WLhf5/5xlV1NiH0tdxzABilH0ITimm2LCKbj3JcSJayZlyu4n3NypE0E cVFeYpBaVZW9wuKUv/va5fzcyWDFPAo+OrR2B3siAb8nfY1jONXNhuV3yZ76pzMr j39lvuSpoTbLobnEWMCJQ5bI/ngbhatT57gqMfF92sO0YjMe/gi/iU6urR9fi5Gz 3Ov6QA78vxzy/YduFjkc/1FV2dNdbGJtq6b0stmz5TtM1uljeGUoj6JZ8kOJ0EXn 857KFAqEd3hG9eYtBdFQcYeV2ShndALBQE0k3cqQvV6XYdHwHuTY15i1nq+u91MZ VwsR1M69PrDX5Ps6qo1F6QYJA/fA4fyOZ9dwIvh+cgtu4wBptr/NOpL3XH0kE2+G b2FRGOwdb2KlejIXSL9p4mfJTX9lmk4twbZe2Spjiy4FinOUyzxEobNoUTMcFCU7 Zu2i5yjMlJzrDB8yXz/N =xtXD -END PGP SIGNATURE- -- ___ 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
prima facie generally means that in a court case the burden of proof shifts from one party to another. For instance, if you have a federal trademark registration that is prima fascia evidence of those rights even though they could still be challenged. To say a prosecutor would have prima fascia evidence of a crime because double spend was detected is quite a stretch. On 6/19/2015 12:36 PM, Matt Whitlock wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 16:42, Eric Lombrozo wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Again, I'm not talking about any changes to the protocol. The mining mechanism in the Bitcoin protocol is the fallback method of resolving fraud that isn't prevented or resolved via other mechanisms. There are plenty of other ways economic actors resolve their disagreements other than blockchain adjudication. Sometimes when both parties are identified and reside in the same legal jurisdiction, contract violations and fraud can be adjudicated in courts. In some situations, the parties involved may have access to private dispute resolution techniques. Sometimes the stakeholders in the network act to preserve the long term value of their investments, even if it means passing short-term profits. The more of those stakeholders there are in Bitcoin, the more effective it is to make the case for choices that are long-term beneficial. The degree to which anyone should rely on a signed transaction as assurance of future payment is not a question with a universal answer. It depends on the particular details of the situation, and the parties involved, and their own risk tolerances and time preferences. There's no right answer for everyone, which is why let's break zeroconf because *I* don't think it's safe enough is a kind of vandalism. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhEkhAAoJECpf2nDq2eYj8qAP/0qYP7FJDjke1qNARGkySjC5 8fSuefu8bus/O2fNYsvPf0OcHeqepLUtQ/hgTml5AHaF1Fa9iZopVr8nZv0NFMuF sv9RfkBKvnnrLWre3e/kQIdKzdMXompEsDwGfIeM3qvVV9AD3mKrz/YNmjs60+hU rEdLCX8xw3ZvF3CGOzE1KnOMbADEd7i3E/Pm1n7pLVdRAg2CIU+w6mjErgucSdvB kQ9SNAVQngjhMJyVbxsQh/+/xgecdqeZ07aaGsLhiw6zML2Tz8KMhrjJ9xw9+7h0 Gze+JdqxpgH4QrvD8KMDnlZjM+cWDUGyoVfsRvrVvPdW6kejU1r1B5Pf6dJg9TwZ kK48RJFdd2rpAkz/kAbvQtoNMxSxhm2gKKFLEMi7g8MZUiGa/Rxj0tWL7OL9SA1U VfpUzgAovoat9lBQM92T5vcS6kfhiNgAmF24ULGGYIhts77Ae6h8Fl3TECtnR0dM 1U1yio4Im1TfUDfjqNSK+ZjVpzkQli0R057y6XzI9HWkSYo94WyjNVoUlUozuAam /2+tUMTrMYPeApRv+1nv13InYO8RZiFqs0E4w4TmB5V4Xt6uGUz4Olioyuo0NqMO lBZwa1ZWKw4fLgHHDu9FhTEOXsOcX5W0gEgcoqMlzTzyoapekk9Esd0pAFLYxYMY YQyAWtWUA4JBbgLxlB8Y =x8eh -END PGP SIGNATURE- -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 15:37, Eric Lombrozo wrote: OK, a few things here: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked…and lack a proper recovery plan. Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint…where signing multiple conflicting blocks results in loss of one’s funds…then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address. Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds…they must remain in limbo forever. I'm not talking about changing the protocol - I'm talking about the business relationships between users of Bitcoin. I would expect a payment processor to inform the merchants of relevant double spends that it observes on the network, even if the payment is actually successful, so that the merchant can decide for themselves whether or not to pursue it out of band. Mining is a kind of technical fallback that allows the network to resolve human misbehavior without human intervention. If nobody ever attempted to make a fraudulent payment, we wouldn't need mining at all because the signed transaction itself is proof of intention to pay. That it exists doesn't suddenly make fraud less fraudulent and mean that users who are in a position to pursue out of band recourse shouldn't do so. I agree that there are valid reasons for replacing transactions in the mempool, I just think they should be implemented in a way that doesn't facilitate fraud. I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk 3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq 7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3 oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+ unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10 +oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46 4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle eWvElyVQJsJHgAU8ygvn =77NP -END PGP SIGNATURE- -- ___ 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
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote: 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. Ah, seems you misunderstand the problem. By properly we're concerned that things do get relayed, not that they do not. In particularl with blocks a fairly to relay valid blocks will quickly lead to a loss of consensus. 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. Right, so those dozen nodes, how many outgoing connections are they making? 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. While your goals may be reasonable, again, the question is how are you going to achieve them? Do you accept that you may be in a position where you can't guarantee confirmations? Again, what's your plan to deal with this? For instance, I know Coinbase is contractually obliged to accept zeroconf payments with at least some of your customers - how strong are those agreements? What we're worried about is your plan appears to include nothing concrete beyond the possibility of getting contracts with hashing power, maybe even just a majority of hashing power. This is something that should concern everyone in the Bitcoin ecosystem, and it'd help if you clearly stated what your intentions are. -- 'peter'[:-1]@petertodd.org 1128683847671e0ca022f9c74df90a3dc718545379101b72 signature.asc Description: Digital signature -- ___ 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
On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Indeed. For instance, one of the ideas behind my Proofchains work is that you could hind all details of a smartcontract-whatchamacallit protocol behind single-use-seals in a consensus blockchain. Closing those seals, that is spending the appropriate txouts, represents things in the protocol which are absolutely unobservable to anyone without the data behind those hashes, an extreme version of the above. Incidentally, some patent prior-art exposure: https://github.com/proofchains/python-proofchains :) -- 'peter'[:-1]@petertodd.org 0a203bd78c8536399f67275064107def6c7afea29c4e3a7b signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
- Did you accept payment from companies to lobby for 20MB blocks? Do you consider that something appropriate to publicly disclose if so? Do you consider that user rights should come above or below company interests in Bitcoin? FWIW on pondering that last question should user rights come above or below company interests I think my view of the guiding principle is starkly clear to me: that user rights should be the primary thing to optimise for. Businesses are providing service to users, their interests are secondary in so far as if they are enabled to provide better service thats good. Bitcoin is a user p2p currency, with a social contract and a strong user ethos. Importing and forcing company interests would likely be the start of a slippery slope towards an end to Bitcoin. I always thought is was the exact opposite. I thought it was expected that the only incentive for developers (other than increasing the value of coins they hold) is to lobby for changes that will benefit the companies that fund them. That is the only way you are going to get more full time developers on board. It focuses their efforts on products and services people want rather than some sort philosophical agenda that may be unrealistic. The notion that large numbers of volunteers will do all this work at little or no pay to improve user experience is not a realistic long term plan. I also think it is incorrect to assume some kind of social contract and strong user ethos. While many early users are like that I think most potential users of Bitcoin don't think that way. Russ -- ___ 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
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
If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… On Jun 19, 2015, at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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
Even if you could prove intent to pay, this would be almost useless. I can sincerely intend to do a lot of things, but this doesn't mean I'll ever actually do them. I am in favor of more zero-confirmation transactions being reversed / double-spent. Bitcoin users largely still believe that accepting zero-conf transactions is safe, and evidently it's going to take some harsh lessons in reality to correct this belief. On Friday, 19 June 2015, at 9:42 am, Eric Lombrozo wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… On Jun 19, 2015, at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. -- ___ 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
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Outputs could be marked as locked. If you are performing a zero confirmation spend, then the recipient could insist that you flag the output for them as non-reducible. This reduces privacy since it would be obvious which output was change. If both are locked, then the fee can't be increased. This would be information that miners could ignore though. Creating the right incentives is hard though. Blocks could be discouraged if they have a double spend that is known about for a while which reduces payment for a locked output. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Remove Us Please
This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 17:50, Jeff Garzik wrote: No. You cannot know which is the 'right' or wrong transaction. One tx has obvious nSequence adjustments, the other - the refund transaction - may not. I'm still not seeing a case where a node could see conflicting transactions on the network as part of a micropayment channel, and not know it was observing the resolution of a channel rather than a likely retail double spend. If both transactions have been broadcast, then one of the conflicting members of the set will have nSequence adjustments. Maybe a clever griefer could try to make their retail double spend look like a micropayment channel, but it seems like they'd be missing the other identifiable markers of that protocol. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3 yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4 YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1 cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW 9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG 4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax TrbPXPlN55NarQ3nmPIW =Hj0x -END PGP SIGNATURE- -- ___ 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
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net wrote: If we have ECDSA proof that an entity intentionally made and publicly announced incompatible promises regarding the disposition of particular Bitcoins under their control, then why shouldn't that be assumed to be a fraud attempt unless shown otherwise? Making multiple incompatible versions of a spend is a -requirement- of various refund contract protocols. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ 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
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net wrote: On 2015-06-19 17:40, Jeff Garzik wrote: Making multiple incompatible versions of a spend is a -requirement- of various refund contract protocols. Is there not a dedicated field in a transaction (nSequence) for express purpose of indicating when a protocol like this is in use? No. You cannot know which is the 'right' or wrong transaction. One tx has obvious nSequence adjustments, the other - the refund transaction - may not. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Remove Us Please
from their website, humorous bits highlighted *October 14, 2014 *In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided it would be a good investment to launch its own coin and back it itself. The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015. Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project. On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp jameson.l...@gmail.com wrote: You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. corpor...@gigasgaming.com wrote: This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Remove Us Please
You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. corpor...@gigasgaming.com wrote: This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Video summarizations of blocksize issues?
On Thu, Jun 18, 2015 at 4:54 AM, odinn odinn.cyberguerri...@riseup.net wrote: Recently I saw the following video: https://www.youtube.com/watch?v=8JmvkyQyD8wt=47m58s For those loosely following the technical issues from outside development circles, but who may be pressed into a voting/adoption type position (miners, users, investors)... is there a parallel presentation of the concepts and arguments from the other side (both, or the various, sides) that they can refer to? Someplace where they are collated and presented? A wiki perhaps? Are these even valid or necessary questions? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
And allegations that the project is run like wikipedia or an edit war are verifyably untrue. Check the commit history. This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it. And I fully believe he would do so! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
If you think it's not clear enough, which may explain why you did not even attempt to follow it for your block size increase, feel free to make improvements. As the outcome of a block size BIP would be a code change to Bitcoin Core, I cannot make improvements, only ask for them. Which is what I'm doing. I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany his patch, because BIPs are best when they describe working code, and BIP 1 *is* at least clear about that. Otherwise it can turn out during implementation that something was different to what was anticipated. I'm sure you agree with this. So a BIP is coming. However, BIP 1 also says this: Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time and BIP authors are responsible for collecting community feedback on a BIP before submitting it for review OK. Gavin has been vetting the idea publicly and collecting community feedback. Note that the entire Bitcoin community is not on this list, so he published a series of blog posts to get wider feedback, and then was criticised for not doing it all here instead. But anyway - so far, so good. The procedure is being followed. What happens once a BIP is written? The process says: For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. Once a BIP has been accepted, the reference implementation must be completed. This is where the problem starts. The BIP process you refer to *does not state how acceptance will happen*. It merely sets out a few minimum requirements like making some sort of sense, having code. It's also full of extremely vague descriptions like must represent a net improvement. Improvement according to who? That's left unexplained. And then it says what happens once a BIP is accepted. The middle bit is missing. When there is disagreement over a consensus BIP, how are decisions made? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net wrote: Dude, calm down. Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. Nobody is worried about Gavin or anyone else making commits to git repositories. You'll notice that this wasn't even mentioned in the original email you were replying to. Instead, the email was talking about commit access, which is a property of GitHub's repositories. So why did I say it? Because it's consistent with what I've always said: (That's not a good reason.) you cannot run a codebase like Wikipedia Wikipedia is a top-down centralized authority-based hierarchy. That's pretty close to what you're proposing. That's what everyone else is disagreeing with. You seem to have switched your position mid-flight...? This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. There are a number of reasons why that perspective is broken; throughout our conversations others have repeatedly reminded you (such as in -wizards) that forking an open-source repository is not at all like a hard-fork of the blockchain. Anyone can be glorious leader of any repository they want, that's how open-source works. However, it's critical that bitcoin users are never convinced to trust BDFLs or anything else that can be compromised. Should all bitcoin users suddenly start using software with BDFLs, even multiple implementations with separate BDFLs, then those users can be trivially compromised through their trust in those individuals and projects. The alternative is that every developer and every user is personally responsible for self-validation of the rules, checking for correctness and validity. Happy coincidence that this seems to match the strategy of operating the bitcoin network itself, which is to run a node that sees everything and validates all the transactions. Anyone is able to find an error in logic or flaw in the system rules, and they should make it known as widely as possible so that others may evaluate the evidence and consider which solutions preserve the important properties of the system. This is not a matter of majorities or minorities; these arguments should be true for anyone independent of who or what they are, or what level of unpopularity they may have. Anything other than this is somewhat radical, and I am confused as to why others have been talking about developer consensus. I suspect that the reason why they have been saying developer consensus is because they are talking about the Bitcoin Core project on GitHub at the moment. But the topic switched to contentious hard-forks already, which is not a topic of repositories but a topic of the blockchain and network; and in the context of contentious hard-forks it is clear why everyone individually must evaluate the rules and decide whether they the software is correct, or whether changes can trivially cause catastrophic broken hard-forks. These lines of reasoning should be true for everyone, and not merely true for one person but not another. Users, companies and developers must be aware of this, even though it's different from their usual expectations of how systems operate and are maintained. And it is important to be careful to not misconstrue this to others because it is entirely possible to unintentionally convince others that traditional and centralized models are safely applicable here. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. Well, if you're talking about the recent disputes regarding a certain patch to hard-fork the blockchain, a decision to not include such a patch seems like the very definition of a decision. Gavin and I say - there is a process, and that process is a hard fork of the block chain. I doubt that other bitcoin software maintainers would agree with that sort of toxic reasoning; contentious hard-forks are basically a weapon of war that you can use against any other collaborator on any bitcoin project. Why would anyone want to collaborate on such a hostile project? How would they even trust each other? - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Ninki Wallet view on blocksize debate
Ben, How does your wallet calculate the fee that should be paid to miners? Do they automatically adjust when transactions take a long time to be confirmed? And how does it respond when transactions are not mined successfully, such as when blocks are full? I strongly urge Gavin to withdraw from this standoff and work with the bitcoin core devs via the existing and successful bip process. The BIP process has not resulted in any hard forks, so this is a little different. While I don't like MG's proposed solution of convincing miners and services to switch to Bitcoin-XT, I recognize that it is done out of a sense of urgency. These types of changes take a long time to roll out, and we should start them before it is too late. This whole debate comes down to: what is more risky, a consensus hard fork or letting bitcoin exceed its imposed capacity limits? The former could result in many services not being compatible and even loss of funds. The latter could result in software failures, instability, and inability to transact: essentially, what bitcoin is supposed to be good at. Both are dangerous and could result in a significant loss of public confidence. Something needs to be done, that's for sure. In the short term, I think we need to do one of two things: 1. All miners and wallet developers need to upgrade to support first-safe RBF, to allow for double spending one's own transactions when they lack sufficient fees to merit confirmations. Wallets also need to randomly request transactions from blocks to see what kind of fees are being paid to get confirmations, so that fees can be paid dynamically instead of with hard-coded values. 2. We can implement either Gavin's or Jeff Garzik's proposal to change the consensus parameters around the block size limit. So Ben, if really don't think that going with #2 is the right way to go (even though everyone agrees that we will need to increase the block size limit eventually anyway, why not now?), then I hope you start to work hard on implementing #1 so that your wallet software can handle hitting capacity limits gracefully. Best, Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
So I'm *not* the decider for anything that concerns the behavior of the global consensus, and I cannot be, as I have explained in the previous post. The person who decides if a pull request is accepted is a decider and significantly affects the behavior of the global consensus. The only option for someone who doesn't agree is to hard fork. There is no way around that and you should just accept that fact and move on. Russ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net wrote: The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of core developers and if so, who are these people? Is it whoever reverts the change last? Could I write down in a document a precise description of how decisions are made? No, and that's been a fairly frustrating problem for a long time. There is a quote from United States Supreme Court Justice Potter Stewart to describe his threshold test for obscenity which is relevant here: I know it when I see it. It is hard certainly, and perhaps even impossible to write down a system of rules that is used to resolve every dispute among core developers. But that doesn't mean it isn't obvious to all the participants what is going on. If a contentious change is proposed, and if after sufficient debate there are still members of the technical community with reasoned, comprehensible objections who are not merely being obstinate in the views -- a neutral observer would agree that their concerns have not been met -- then there is a lack of consensus. If there was some sort of formal process however, the system wouldn't work. Rules can be gamed, and if you add rules to a process then that process can be gamed. Instead we all have a reasonable understanding of what technical consensus is, and we all know it when we see it. Where we do not see it, we do not proceed. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This kind of thing always happens as projects become larger and more diverse. Something that was once a small group turns into a big group of diverse stakeholders. When it gets too big for the informal processes then some people get upset and defensive. Happens all the time but it is not really a good excuse to keep doing things in an inefficient manner. The old ways just don't scale and if you ever worked on massive projects then you know these formal processes work better. So then: make a proposal for a better process, post it to this list. In practice there has been zero interest in improving the BIP process. E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= =dMO9 -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
So then: make a proposal for a better process, post it to this list. Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after What belongs in a successful BIP?. Let me know what you think. The following section applies to BIPs that affect the block chain consensus rules or the peer to peer protocol and thus require changes to Bitcoin Core. Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. The verdict will meet the following criteria: - It will address the latest version of the BIP at the time the verdict is rendered. - In case of a rejection, it will spell out and describe the technical rationale for this decision. Opinions held by other people are not considered technical rationales: if the maintainer agrees with a technical point made during discussion, he must own that opinion for himself. Therefore no BIP will be rejected on grounds of controversy, disagreement, lack of consensus or otherwise. - In case of rejection, the maintainer will provide a clear, specific list of actionable steps the BIP author can take next. For example, a list of what changes would address the technical objections raised. In case the maintainer believes no change could ever make the BIP acceptable, the list must consist of instructions for how to create a patch set and, in the case of changes to the consensus rules, how to initiate a hard fork. A BIP, even once rejected, may live on in the BIPS repository, though its entry in the index may be sorted below others. The BIP author may update the BIP with a summary of any resulting discussion. As such a summary may be inherently contentious in case of a dispute, the authors wording of that summary is final and may not be subject to meta-debate. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
You misunderstand what I am saying. I am not saying I have a specific process that should be followed, I am saying that whatever the process is then it should be formalized or at least written down. That way the stakeholders have something to work with and keeps people on track. Since some people are saying they don't really know what the process is the first step would be to describe the current process. I don't fully understand the current process but I can see it is not formalized and nobody can even give me a clear description of what it is. Once you have it written down then changes/improvements can be proposed. The first baby step was already done by the Foundation in developing that risk study. A NIST guide for developing such a document is at http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf. No one person can come up with this and it would take buy in from several different people who have expertise in specific technical areas as well as experts in coming up with test plans. I recently suggested to the people running the MIT lab that they look into developing a program along those lines. Gavin also recently suggested that list of Bitcoin metrics be developed to help resolve the current disputes. I can help develop this process if there is interest. Russ On 6/18/2015 11:46 AM, Wladimir J. van der Laan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This kind of thing always happens as projects become larger and more diverse. Something that was once a small group turns into a big group of diverse stakeholders. When it gets too big for the informal processes then some people get upset and defensive. Happens all the time but it is not really a good excuse to keep doing things in an inefficient manner. The old ways just don't scale and if you ever worked on massive projects then you know these formal processes work better. So then: make a proposal for a better process, post it to this list. In practice there has been zero interest in improving the BIP process. E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from some spelling and grammar corrections. It is not specifically adapted to Bitcoin, and doesn't make a distinction between for example, consensus changes and non-consensus changes. So that's up to someone to do. You seem to be enthousiastic about it, so go ahead. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+ U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw= =dMO9 -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net wrote: On 2015-06-18 14:53, Jeff Garzik wrote: Consensus changes - worded another way - change Bitcoin's Constitution - The Rules that everyone in the system is -forced- to follow, or be ignored by the system. Bitcoin does not and can not function as a set of rules imposed by some people onto other people. This is an engineering list. The quote precisely describes how the bitcoin consensus system functions. Users' choice is largely binary: Follow the rules, or bitcoin software ignores you. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote: Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. Again, for the last time: Bitcoin Core maintainer does not decide about protocol or consensus level changes. This is not a role for me. Find someone else, if you think you need an arbiter. There was an idea about a Bitcoin Standards Body once, but as far as I know that's not actively being worked on. BTW: for more exposure a proposal is better posted as a new thread, not as a deep reply to an existing topic. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
