[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
