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 >> > 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-06-20 18:20, Jorge Timón wrote: > On Fri, Jun 19, 2015 at 6:42 PM, 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… > > 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVhfkXAAoJECpf2nDq2eYjTwIP/ApsURTKJgAsSYb4/lvoujAE EhOUBfmb+WkrEceASWGgmXFfQBQW7c99sT46cA1HdCPLZMtYhZYPubtYRouSupfF vOfeKLsZsUXCadeLuzxP7av3PJhmvB1CO1Rv8CLBQptKUFkzyM3CypBviNTy33X6 KL2zyAMERpCVOejg7MSP3IUXIjgG1ayEm+mzwqi4j2Ms0h+oT6I/krAKV0J9SwJC PtLq/JRRriVtb2FE+biEqYRYfeOcZDYNbr+/y0HPtqqMxg6azNwx1z2aG5A+ziCd EvVqVJXU3TAINQdIvVS4ACF1J+ttMJ99r8VW0yN7o3fEckuRr3pyymx4I+XExSX5 ujflqadRGUS8ZenUPTPUbLfhARnmBwLM94L+xiQvIwiinxxtOKn3WW1oDv9FNp0l 99fkv9mbV5RnYlkMfWMn2AcwcBv7TSgpFGsZY4wBn/mgFh1PotGc2tA5kU79cz8R +F/k49+GwfgTPML7UhIGtjQjPreeqDyHNtv9XHtyp8LF5vO1na4oHSO6SeU4rIXH 4oIjw+Q6X/2L/fp8QNLB+onmKWobcl1Ec+0H+ZfQBujtew5BHFwcPwFmlC4tofiJ 7r8QjoPsRhJmaxm+MJOK/BIzhZErkMz26AQ/tfY4jtJCuLbEDdMLtC9hYVuiDHIb HBxxif83dALjX1Sgid66 =o9dG -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 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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? As far as I know, transactions which are using those protocols can be easily differentiated from those that aren't (which is probably good from a payment assurance standpoint and bad from a privacy standpoint). -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVhFW3AAoJECpf2nDq2eYjkegQAINcnzIPbO/bKqNv14TOonb8 9g/pfvMSQyZjUiu4rB6Iwtn+h1hyLkPc3cdSFV4diQSWeG7Q27ZJzH1T1kYdKp4W DDH8DwD8PtOu+dgRK9eBsy9h72OncA4JTFhnAXMgfLVBY9eRqXk/DWlzwV/WOn/j 3G5xKKOOeHmKJCaKFwdpZghraLouS72AKSdxCNvleRc4zllV+zqWyHHssNDg7sGH b/62O3DBZXdlzIEzK8/IeaNMY+UXd984/yQ8KCrHCKjc9uiUjNUCCw4JPo4rB/ZA Itoc8b6pexRs8h40FdXGYAwvN5xQgcaOL7SsN2nNx/DQWYf+1krBO8Iy4kYw2KGl 8JctcHBOI2gLCxTpB2cWeGPwBQbKJhPsmxTxaTNw5fC6ycAnjoJ2bO1Uz0KfwdnI 2jmwxccB9KauC9zNthxGbvdsHOxE8foZ6AnSDI/qbYQK6MqtSnsa7BUn8vc/y4Uf bVCsxiywVlHttCJqPh5v16rejCcH2el5Rd5PVCkEagxYFfLA3681ZJKD22UV742l n8ii7RUJXeps6zjRAc35Ccj5qjhB4SP4qYvKmyEoltYbw1EwXbm93UCsFpuxmQ9g GbQ/jZXsB1cmHBC+c+3X6SaU6eZdy2jDHsICP7sMx2CrZpcZZO058bqRbmdk8JE6 JI17MYG0ofTLfdCfkgEG =en1q -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 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 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
-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
-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
-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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-18 16:28, Jeff Garzik wrote: > 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. Software engineers should understand that they have a binary choice: produce the software that your customers want, or the world will ignore your software. There is *no inherent value* to Bitcoin's software rules. The only value that is exists is that produced by the individuals who voluntarily choose to run the software. Failing to account for all design requirements is bad engineering. Nobody cares about the design features of a bridge to nowhere. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9 FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6 Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G 0A+51wwSZnAdMIw7lwIb =r4Co -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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. Force is not a helpful or accurate way to describe the situation. The purpose of Bitcoin to let people trade with each other, and trade requires mutual agreement. If some people choose not to trade under certain terms, they aren't "forcing" anybody to do anything. They are simply refraining from proposed interactions. Not granting them the right to do this would actually be forcing them to engage in interactions against their will. It's an unavoidable reality that Bitcoin's usefulness is related to the size (really: economic output) of the group of people who can be convinced that it's in their best interest to agree on a common trade protocol. Conversations that feature untrue claims about someone forcing someone else to do something is the opposite of a viable strategy for growing the size of that group. Arguments about who violated what Bitcoin Core internal governance procedures are not interesting to most Bitcoin users, who generally don't know or care who has commit access to the repository. Getting angry at Gavin and Mike for providing Bitcoin users with an alternative which they can freely choose or reject is not helpful in persuading users to stay with Bitcoin Core. Making the case why the changes in Bitcoin XT are not beneficial to Bitcoin users could be. For better or for worse, Bitcoin coin users are going to run the software they perceive to be in their best interests. Nobody can stop them from making that choice and any effort directed at that end is wasted. It's more productive to expend effort making sure the current and future Bitcoin users are as informed as possible about the long term and short term consequences of their choices. Circling back to the original quote: 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. Bitcoin is a negotiation about the best way for money to function in the future. The only way we get people to use Bitcoin is to convince them that the benefits they gain from agreeing to its protocol outweigh the downsides they encounter. I'm confident that this case can be made successfully but a prerequisite to a successful negotiation is recognizing that it is, in fact, a negotiation, and that the other parties have full agency and the right to walk away if mutual agreement is not reached. My suggestion is to spend less time talking about procedural violations and more time convincing Bitcoin users that Bitcoin Core is the best client for them to use, especially if the process of convincing them involves making improvements which the users are asking for (or making a very compelling case about why the users should reconsider). -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVguyLAAoJECpf2nDq2eYjTPgP/A16QGWSWkh50OhSjHx7hdY5 v0ZqNvfKSm6a94o22yTQF8VZm7NEJJcNY0Vvu1ro95v27Bm37VodGGOXh4ao9gYQ ETdzX35OLWUua1e9kfEwgo2Uu2l9AdALOLK5IHyLZdtxJQwUhcdeIhaSMzlZqgEk n+gbAZXV7JdnK+oejh5s8zgfOY3MqhZC3TQBVWHWx0K0CE75rm0j4ZShYL2eKOua CmWkcEkfeugrnQQv/BB+oe1TAJoHY4bZAr+amYLZMiC8wRcGGeVBOOFykLNd4rSV DE+iiGHmgi/wrZjy/xT5kflX55GE8NNVjM2MMNOyD+gWbBn5INahya+DkDWupeQB iy71NQQVnB/5U5Yhm/oVUax+Cjj/7001cf1q2rXPcjE+4ntw5ad9oCuRW3kSUpzq C0LqEN2lbagrmk/xHSv/GQl+iWulD1mXJl63y3LdXYWno67eVYqzvRK0UB7ZSVww 3P7p8h2yuvtPtAUDyoOPn7Ghyd1U1lJWGsyffRzd2hWhEYs44cfAv6S2QWIBWbm5 j8C2ao7m6j2mirRZem+bGrN8idR/fOUIjnwqQmNIObsviMrvgXlHvORjsBcdHoKO 9Ir8CvqGWftIG5lLCJvjsnP8E3MRToo6pOsD/Ii9223Pn6DxsMvXF+IkZzUJfWDR W+t/BYV6XtsAUKI+dAly =3KeB -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
On 2015-06-16 07:55, Aaron Voisine wrote: >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. >> Who >> would provide the nodes they would need connect to? > > The SPV wallet author would if they wanted their wallet to function. How will the SPV wallet users pay for this service? With their money, or with their privacy? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
On 2015-06-16 03:49, Kevin Greene wrote: > Hah, fair enough, there is no such thing as the "right" way to do > anything. But I still think punishing users who use SPV wallets is a > less-than-ideal way to incentive people to run full nodes. Right now > SPV is > the best way that exists for mobile phones to participate in the > network in > a decentralized way. This proposal makes the user experience for mobile > wallets a little more confusing and annoying. Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who would provide the nodes they would need connect to? The decentralization fairy? There's absolutely no reason that paying for connectivity would be any more confusing or annoying than transaction fees are. If some full nodes in the network started offering paid connection slots, that would just mean that users who checked the "pay subscription fee" box in their wallet configuration would have an easier time connecting than the users who did't, just like how your transaction might eventually get mined without a fee but paying one makes it faster and more probable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
