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
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] 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
[Bitcoin-development] F2Pool has enabled full replace-by-fee
and Android Bitcoin Wallet, Peter Todd, May 23rd 2015, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html 2) From Zero to Hero: Bitcoin Transactions in 8 Seconds, June 2nd, 2014, Erik Voorhees, https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734 3) Coinbase Merchant API, Accessed Jun 19th 2015, https://developers.coinbase.com/docs/merchants/callbacks#confirmations 4) Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network, March 14th 2015, Grace Caffyn, Coindesk, http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/ 5) First-Seen-Safe Replace-by-Fee, May 25th 2015, Peter Todd, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html 6) Cost savings by using replace-by-fee, 30-90%, May 25th 2015, Peter Todd, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html 7) Tampering with the Delivery of Blocks and Transactions in Bitcoin, Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015, http://eprint.iacr.org/2015/578 -- 'peter'[:-1]@petertodd.org 070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad 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 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
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
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
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] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org wrote: Dear Adam, All: At the community's convenience, it would be an honour to arrange an initial open summit to meet with representatives of the Chinese miners in Hong Kong (UTC+8) to facilitate a better understand between the different stakeholders of the Bitcoin ecosystem on this important issue. This could be arranged for this October, or earlier, if deemed necessary. Great! FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a blockchain-tech conference October 14th-15th in Hong Kong as well; coordinating your summit with that conference could be useful. http://blockchainworkshops.org/ This workshop series has been attracting audiences of people looking to use blockchain tech in general; many of these use-cases will likely involve the Bitcoin blockchain in unpredictable ways. Importantly, these ways can drive demand significantly beyond our current assumptions based on most demand being consumer-merchant transactions. In addition, many of the attendees have significant experience with regulatory issues and interacting with governments on regulation of blockchain tech. Bitcoin faces existential risks to its existence by these regulation efforts, which include things like efforts to setup industry wide Anti-Money-Laundering/Know-Your-Customer programs, including programs that would tie on-chain transactions to identity information. Any blocksize discussion needs to be informed by these potential threats to usage of the technology, as well as challenges to using scaling solutions. Remote online participation would be welcome from those who might not be able to attend in person. However, it is hoped that such a meeting would be primarily document driven to facilitate orderly translation, discussion and decision. Agreed. Pieter Wuille's recent work is a great example of the kind of science-driven investigations that need to be done - and haven't been done very much - to get us some hard data to make decisions on. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] Reusable payment codes
On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote: This is very well done. Have you seen this discussion that I started regarding BIP 63? https://bitcointalk.org/index.php?topic=1083961.0 I have no response from Peter Todd back on it other than my time is better spent focusing on more fundemental issues and I've also got no-one interested in funding stealth address development right now, when several people (myself included) offered to send donations to see the BIP (63) advance, no donation address was posted, so... waiting for him to act on that. Sorry, but I'm looking at the huge amount of work that I'll likely have responding to the blocksize issue, so I think I'm inclined to shelve work on BIP63 for now. Feel free to take it up; a (=2)-part standard describing the resuable codes aspect, and separately how the ephemeral key is transmitted to the recipient makes sense to me. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] Scaling Bitcoin with Subchains
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote: On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille pieter.wui...@gmail.com wrote: It's simple: either you care about validation, and you must validate everything, or you don't, and you don't validate anything. Sidechains do not offer you a useful compromise here, as well as adding huge delays and conplexity. As noted to Adam last night - although I agree it adds complexity - side chains are one solution that will indeed help with scaling long term. Similar to the graph you see with git repos and merges, having aggregation chains that arbitrarily fork and then rejoin the main chain are both feasible and useful. That code future is a ways away from production, so doesn't help us here. Still, let's not dismiss it as a solution either. To be clear, it depends on what kind of sidechain. My off-chain transaction notions are federated sidechains with an economic incentive to not commit fraud using fidelity bonds; they were definitely proposed as a scaling solution. Merge-mined sidechains are not a scaling solution any more than SPV is a scaling solution because they don't solve the scaling problem for miners. Some kind of treechain like sidechain / subchains where what part of the tree miners can mine is constrained to preserve fairness could be both a scaling solution, and decentralized, but no-one has come up with a solid design yet that's ready for production. (my treechains don't qualify for transactions yet; maybe for other proof-of-publication uses) Keep in mind that other than preserving mining decentralization/resisting censorship, we've known how to scale up blockchains for ages w/ things like (U)TXO commitments and fraud proofs. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] Mining centralization pressure from non-uniform propagation speed
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote: The configuration used in the code right now simulates two groups of miners (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected internally, but are only connected to each other through a slow 2 Mbit/s link. Here are some results. This shows how the group of smaller miners loses around 8% of their relative income (if they create larger blocks, their loss percentage goes up slightly further): To be clear, when you say 8% of their income, you mean revenue, not profit? Actual profit margins of something like 5%-10% are likely, so that's an enormous hit that could make their mining operation completely non-viable. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain the same 1 0 = vote for the limit to be halved 1 1 = vote for the limit to be doubled User transactions would follow the same usage. In particular, a user vote of 0 0 (no preference) could be included in a block casting any vote, but a block voting 0 0 (no preference) could only contain transactions voting 0 0 as well. Sounds like a good encoding to me. Taking the median of the three options, and throwing away don't care votes entirely, makes sense. Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users. Thanks! I personally expect disaster to ensue with this kind of proposal, but I'm less concerned if the disaster is something users explicitly allowed to happen in a consensual way. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] User vote in blocksize through fees
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users. Exactly. I very explicitly am proposing that we consider giving users a mechanism to pay for votes to give them a way to directly influence the outcome. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] Mining centralization pressure from non-uniform propagation speed
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote: Nice work, Pieter. You're right that my simulation assumed bandwidth for 'block' messages isn't the bottleneck. But doesn't Matt's fast relay network (and the work I believe we're both planning on doing in the near future to further optimize block propagation) make both of our simulations irrelevant in the long-run? Then simulate first the relay network assuming 100% of txs use it, and secondly, assuming 100%-x use it. For instance, is it in miners' advantage in some cases to sabotage the relay network? The analyse say yes, so lets simulate that. Equally even the relay network isn't instant. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66
Summary --- The BIP66 soft-fork recently passed the 75% support threshold. This means that 75% of the hashing power has upgraded to support BIP66; 25% of the hashing power has not. Once 95% of the hashing power has upgraded, blocks created by the 5% who have not upgraded will be rejected. If you operate a pool, solo-mine, or mine on p2pool you'll very likely need to upgrade your Bitcoin Core node to support the BIP66 soft-fork, or your blocks will be rejected. If you only sell your hashing power to a centralized pool you do not need to do anything. How does the Bitcoin protocol measure BIP66 support? Miners that have upgraded to support BIP66 create blocks with the version field set to 3; non-upgraded miners set the version to 2. Bitcoin Core measures BIP66 support by counting how many blocks with version = 3 exist in the blockchain within the last 1000 blocks. If 750 out of the last 1000 blocks support BIP66, blocks with the version set to = 3 that do not follow the BIP66 rules are rejected; if 950 out of the last 1000 blocks support BIP66, blocks with version 3 are rejected. When will the 95% threshold be reached? --- It's unknown exactly when the 95% threshold will be reached. The BIP34 soft-fork went from 75% to 95% support in a about two weeks, however more or less time is possible; it's possible that the 95% threshold will be reached in just a few days. How can I monitor BIP66 adoption? - See Pieter Wuille's graphs: http://bitcoin.sipa.be/ver-ever.png http://bitcoin.sipa.be/ver-50k.png http://bitcoin.sipa.be/ver-10k.png http://bitcoin.sipa.be/ver-2k.png The 'ever' and '50k' graphs show the 75% and 95% thresholds. What software supports support BIP66? - Bitcoin Core releases later than v0.10.0 support BIP66. In addition, v0.9.5 supports BIP66, however we recommend that you upgrade to v0.10.2 If you run a pool, you may also need to upgrade your pool software as well. For instance, eloipool versions prior to May 22nd 2015, git commit f5f4ea636fb38f38e6d9a04aad1f04427556a4bc, do not support BIP66. (For Eloipool, cb8a5e8fbb4bfdfe9e35f670082603caff65e1b2 is a clean merge that should work for any branch more recent than 2013 April 6) Solo miners and decentralised miners using GBT need to also update their mining software to a currently supported version of BFGMiner to get support for v3 blocks. The official BFGMiner binaries include this update with 5.1.0, 4.10.2, and 3.10.9. What is BIP66? -- BIP66 - Strict DER signatures - is a soft-fork that tightens the rules for signature verification, specifically the way that signatures are encoded. The Bitcoin Core implementation currently relies on OpenSSL for signature validation, which means it implicitly defines Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. (see CVE-2014-8275) By tightening these rules BIP66 reduces the risk that changes to OpenSSL will cause forks in the Bitcoin blockchain, as seen previously by the March 2013 fork. Secondly reducing our dependency on OpenSSL is a step towards replacing OpenSSL with libsecp256k1, a signature validation library from Pieter Wuille and Gregory Maxwell, that is designed for consensus-critical applications, as well as being significantly faster than OpenSSL. Is it possible that the BIP66 soft-fork will not happen? In theory yes, though it is unlikely and rejection of BIP66 would be a very ugly process. Unfortunately the existing soft-fork mechanism provides no mechanism for a soft-fork to expire, so once set in motion there is no clean way to stop a soft-fork. There is a proposal from Wuille/Maxwell/Todd, to reform how soft-forks are adopted that aims to fix this issue, as well as allow multiple soft-forks be adopted in parallel: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] First-Seen-Safe Replace-by-Fee patch against Bitcoin Core v0.10.2
First-seen-safe Replace-by-Fee is now available as a patch against v0.10.2: https://github.com/petertodd/bitcoin/tree/first-seen-safe-rbf-v0.10.2 I've also had a pull-req against git HEAD open for a few weeks now: https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829 I've got some hashing power interested in running this patch in the near future, so I'm offering a bounty of up to 1 BTC to anyone who can find a way to attack miners running this patch. Specifically, I'm concerned about things that would lead to significant losses for those miners. A total crash would be considered very serious - 1 BTC - while excess bandwidth usage would be considered minor - more like 0.1 BTC. (remember that this would have to be bandwidth significantly in excess of existing attacks) For reference, here's an example of a crash exploit found by Suhas Daftuar: https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829 If two people report the same or overlapping issues, first person will get priority. Adding a new test that demos your exploit to the unit tests will be looked upon favorably. That said, in general I'm not going to make any hard promises with regards to payouts and will be using my best judgement. I've got a bit over 2BTC budgetted for this, which is coming out of my own pockets - I'm not rich! All applicants are however welcome to troll me on reddit if you think I'm being unfair. Suhas: speaking of, feel free to email me a Bitcoin address! :) -- 'peter'[:-1]@petertodd.org 06dd456cf5ff8bbb56cf88e9314711d55b75c8d23cccddd5 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] Proposal: SPV Fee Discovery mechanism
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote: On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com wrote: It could be done by agreeing on a data format and encoding it in an op_return output in the coinbase transaction. If it catches on it could later be enforced with a soft fork. Sounds plausible, except SPV protocols would need to include this coinbase txn if it's going to help SPV clients. (Until a softfork is activated, SPV clients should not rely on this encoding, since until that time the results can be fabricated by individual miners.) Fee stats can always be fabricated by individual miners because fees can be paid out-of-band. -- 'peter'[:-1]@petertodd.org 1245bd2f5c99379ee76836227ded9c08324894faabc0d27f 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] Lexicographical Indexing of Transaction Inputs and Outputs
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: Two other things: On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” I'd keep it even simpler than that, and just say for now that such use-cases are out of the scope of this BIP, however those standards should come up with some kind of deterministic standard that meets the needs of the protocol. Again, there's a bunch of possible use-cases here and we just can't predict them; focus on the fact that the *spirit* of what this BIP is about is applicable and future standards should be developed. So I'd change the Applicability section to: This BIP applies to all transactions where the order of inputs and outputs does not matter. This is true for the vast majority of transactions as they simply move funds from one place to another. Currently this generally refers to transactions where SIGHASH_ALL is used, in which case the signatures commit to the exact order of input and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE has been used (e.g. crowdfunds) the order of inputs and/or outputs may not be signed, however compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. In the event that future protocol upgrades introduce new signature hash types, compliant software should apply the lexographic ordering principle analogously. While out of scope of this BIP, protocols that do require a specified order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should consider the goals of this BIP and how best to adapt them to the specifics needs of those protocols. Then remove the handling input/output deps section. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. re: the actual ordering algorithm, having txids be sorted by with the hex-based algorithm is odd. I'd simply say they're sorted as little-endian byte arrays, or in other words, with the bytearr_cmp() function, but with the order of bytes reversed. You also should say that we're doing that to make the user see them in visually sorted order to match expectations because txids are displayed as little-endian. For outputs, don't say locking script, say scriptPubKey. Secondly, scriptPubKeys are not in little-endian representation - they have no endianness to them. With output amount, there's no need to say that they're unsigned or little-endian satoshies, just say they're sorted largest/smallest amount first. For the sake of efficiency, amounts will be considered first for sorting, since they contain fewer bytes of information (7 bytes) compared to a standard P2PKH locking script (800 bytes). - where the heck did you get these numbers from? Amounts are 8 bytes, and P2PKH scriptPubKeys are 25 bytes. Backwards Compatibility - I'd just remove this whole section; we're unlikely to make this an IsStandard() rule anytime soon. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote: FWIW, The Open Assets colored coin protocol (CoinPrism) places special significance on the zeroth input and the position of the OP_RETURN colored coin marker output to distinguish colored coin issuance outputs from transfer outputs. Reordering the inputs or the outputs breaks the colored coin representation. Recommending sorting of the inputs and outputs as a best practice is fine (and better than random, IMO), but not as part of IsStandard() or consensus rules. There are cases where the order of the inputs and outputs is significant. Timestamping is another case where order matters: if you put the digest in the last vout you can use SHA256 midstate's to reduce the size of the timestamp proof. Anyway, there's no reason to rush re: changes to IsStandard() -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. Bitcoin is a global consensus system - if you're bandwidth isn't sufficient to keep up you are not part of the consensus. The blocksize limit *is* what determines the minimum bandwidth required to stay in consensus. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. Again, in your scenario if the bandwidth consumed by those transactions was sufficiently high, the network would collapse because consensus would fail. Why wouldn't that bandwidth be high enough to cause that collapse? Because of the blocksize limit! (combined with an intelligent mempool that increases the minimum fee/KB appropriately - we don't have that yet) The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. I already did the math for you on that: the maximum transaction fee you'd see in that kind of attack is around $2.5 USD/tx. That definitely is not high enough to make Bitcoin non-viable - I personally could easily afford fees like that for about 90% of my transactions this year by value, as I mainly use Bitcoin to get paid by my clients around the world. In fact, just today O'Reilly paid $15 USD to send me a wire transfer for expenses related to a conference I was invited too. A much more realistic transaction flood scenario - one that didn't raise serious questions about whether or not the attacker could afford to 51% attack Bitcoin - would raise tx fees to something more like $0.25/tx -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote: There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too. You know, you can think of Bitcoin as a system that maintains a ledger for transferrable hashcash... Which means transaction fees *are* paid in hashcash. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality. There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. Keep in mind, that at some point it'd be cheaper to just 51% attack the network. Based on the current block subsidy of 25BTC/MB that's at the point where transaction fees are 25mBTC/KB, which corresponds to $2/tx fees - not that cheap, but still quite affordable for a large percentage of Bitcoin's users right now. And that's the *absolute worst-case* attack possible. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote: With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and $23k/GB (assuming $23 * 1000, as each $23 is 1mb). Only pointing out as it highlights thats it's even more expense to do. Mike Hearn reduced the minimum relay fee to 0.01mBTC/KB: https://github.com/bitcoin/bitcoin/pull/3305 -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 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] Proposed alternatives to the 20MB step function
On Thu, May 28, 2015 at 01:19:44PM -0400, Gavin Andresen wrote: As for whether there should be fee pressure now or not: I have no opinion, besides we should make block propagation faster so there is no technical reason for miners to produce tiny blocks. I don't think us developers should be deciding things like whether or not fees are too high, too low, . Note that the majority of hashing power is using Matt Corallo's block relay network, something I confirmed the other day through my mining contacts. Interestingly, the miners that aren't using it include some of the largest pools; I haven't yet gotten an answer as to what their rational for not using it was exactly. Importantly, this does mean that block propagation is probably fairly close to optimal already, modulo major changes to the consensus protocol; IBLT won't improve the situation much, if any. It's also notable that we're already having issues with miners turning validation off as a way to lower their latency; I've been asked myself about the possibility of creating an SPV miner that skips validation while new blocks are propagating to shave off time and builds directly off of block headers corresponding to blocks with unknown contents. -- 'peter'[:-1]@petertodd.org 0327487b689490b73f9d336b3008f82114fd3ada336bcac0 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] Consensus-enforced transaction replacement via sequence numbers
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote: Can you update it so that it only applies to transactions with version number 3 and higher. Changing the meaning of a field is exactly what the version numbers are for. You could even decode version 3 transactions like that. Version 3 transactions have a sequence number of 0x and the sequence number field is re-purposed for relative lock time. This means that legacy transactions that have already been signed but have a locktime in the future will still be able to enter the blockchain (without having to wait significantly longer than expected). For that matter, we probably don't want to treat this as a *version* change, but rather a *feature* flag. For instance, nSequence is potentially useful for co-ordinating multiple signatures to ensure they can only be used in certain combinations, a use-case not neccesarily compatible with this idea of a relative lock. Similarly it's potentially useful for dealing with malleability. nSequence is currently the *only* thing in CTxIn's that the signature signs that can be freely changed; I won't be surprised if we find other uses for it. Of course, all of the above is assuming this proposal is useful; that's not clear to me yet and won't be without fleshed out examples. -- 'peter'[:-1]@petertodd.org 08464a6a19387029fa99edace15996d06a6343a8345d6167 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] Consensus-enforced transaction replacement via sequence numbers
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote: On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote: Equally this proposal is no more consensus enforcement than simply increasing the fee (and possibly decreasing the absolute nLockTime) for You've misunderstood it, I think-- Functionally nlocktime but relative to each txin's height. But the construction gives the sequence numbers a rational meaning, they count down the earliest position a transaction can be included. (e.g. the highest possible sequence number can be included any time the inputs are included) the next lower sequence number can only be included one block later than the input its assigned to is included, the next lower one block beyond that. All consensus enforced. A miner could opt to not include the higher sequence number (which is the only one of the set which it _can_ include) it the hopes of collecting more fees later on the next block, similar to how someone could ignore an eligible locked transaction in the hopes that a future double spend will be more profitable (and that it'll enjoy that profit) but in both cases it must take nothing at all this block, and risk being cut off by someone else (and, of course, nothing requires users use sequence numbers only one apart...). I understand that part. I'm just saying it's not clear to me what's the functional difference in practice between it and having both parties sign a decreasing absolute nLockTime. For instance, you and I could setup a payment channel using the following transaction t0: 1.0 BTC: PT - 1.0 BTC: PT (GM || expiry CLTV) 1.0 BTC: GM - 1.0 BTC: GM (PT || expiry CLTV) After expiry both of us are guaranteed to get our funds back regardless. I can then give you funds by signing my part of t1a: t0.vout[0] PT sig blank - 0.5 BTC: PT t0.vout[1] blank PT sig - 1.5 BTC: GM nLockTime = expiry - 1 You can then give me funds with t1b: t0.vout[0] blank GM sig - 1.5 BTC: PT t0.vout[1] GM sig blank - 0.5 BTC: GM nLockTime = expiry - 2 etc. etc. We can close the channel by signing a non-nLockTime'd tx at any time. If you don't co-operate, I have to wait, and hope I get my tx mined before you get yours. What I'm not seeing is how the relative nLockTime that nSequence provides fundamentally changes any of this. -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 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] Version bits proposal
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote: I think it would be better to have the deadlines set as block counts. That eliminates the need to use the median time mechanism. The median time mechanism is basically a way for hashing power to show what time they think it is. Equally, the nVersion soft-fork mechanism is a way for hashing power to show what features they want to support. Block counts are inconvenient for planning, as there's no guarantee they'll actually happen in any particular time frame, forward and back. There's no particular incentive problems here - the median time clearly shows support by a majority of hashing power - so I don't see any reason to make planning more difficult. The deadline could be matched to a start-line. The definition would then be something like BIP 105 Start block: 325000 End block: 35 Activation: 750 of 1000 Implication: 950 of 1000 Bit: 9 This would allow creation of a simple table of known BIPs. It also keeps multiple users of the bit as strictly separate. If you assume no large reorganizations, your table of known BIPs can just as easily be a list of block heights even if the median time mechanism is used. If you do assume there may be large reorganizations you can't have a simple table -- 'peter'[:-1]@petertodd.org 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 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] First-Seen-Safe Replace-by-Fee
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote: Case 1: Increasing the fee on a single tx - We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size with the minimal relay fee, 2.26uBTC. Increasing the fee while respecting FSS-RBF rules requires the addition of one more txin, with the change output value increased appropriately, resulting in transaction t2, size 374 bytes. If the change txout is sufficient for the fee increase, increasing the fee via CPFP requires a second 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total of 566 bytes. Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in cases where the original transaction didn't have a change output. To clarify a point raised(1) on the pull-req itself: The replacement transaction is allowed to not only add new txin's, but also replace txins. Suppose t1 is a 2-in-2-out P2PKH using transaction, 374 bytes in size. With CPFP accomplished by a 1-in-1-out tx, 192 bytes, you have 566 bytes total. With FSS RBF if you have an unspent output greater in value than one of the outputs spent by t1, you can replace that output in t1's vin txin set and rebroadcast the transaction, still 374 bytes in size. This gives you a 34% cost savings vs. CPFP. Case 2: Paying multiple recipients in succession We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice. We now need to pay Bob. With plain RBF we'd just add a new outptu and reduce the value of the change address, a 90% savings. However with FSS RBF, decreasing the value is not allowed, so we have to add an input. If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can be created, 2*226=452 bytes in total. With FSS RBF we can replace t1 with a 2-in-3-out tx paying both, increasing the value of the change output appropriately, resulting in 408 bytes transaction saving 10% Similar to the above example in the case where the change address of t1 is insufficient to pay Bob the end result is one less transaction output in the wallet, defragmenting it. Spending these outputs later on would require two 148 byte inputs compared to one with RBF, resulting in an overall savings of 25% Similarly in the multiple recipients case, if sufficiently large outputs are available the additional funds can be obtained by swapping one input for another. For instance if Alice has three outputs, 1.0, 0.5, and 0.2 BTC, and needs to pay Bob 1.1 BTC, she can create t1: 1.0 - Bob 1.1 0.2 - Alice 0.1 If she then needs to pay Charlie 0.2 BTC she can doublespend that with: 1.0 - Bob 1.1 0.5 - Charlie 0.2 - Alice 0.2 Note that care does need to be taken to ensure that multiple rounds of this always leave at least one input unchanged. 1) https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-105630255 -- 'peter'[:-1]@petertodd.org 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 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] Consensus-enforced transaction replacement via sequence numbers
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote: Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. The idea is that a participant can sign successive versions of a transaction, each time incrementing the sequence field by some amount. Relay nodes perform transaction replacement according to some policy rule making use of the sequence numbers, e.g. requiring sequence numbers in a replacement to be monotonically increasing. Can you provide a worked example of this in use? I think I see a major flaw, but I'd like to see a worked example first. Keep in mind that there's absolutely no reason to have pending transactions in mempools until we actually expect them to be mined. Equally this proposal is no more consensus enforcement than simply increasing the fee (and possibly decreasing the absolute nLockTime) for each replacement would be; increasing the fee for each mempool replacement is a hard requirement as an anti-DoS anyway. (this was all discussed on the mailing list two years ago when RBF was first proposed) -- 'peter'[:-1]@petertodd.org 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 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] Cost savings by using replace-by-fee, 30-90%
On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote: What is wrong with the man testing some ideas on his custom branch? This is how improvements come to life. I saw in the BIPs some really interesting ideas and nice brainstorming which came from Peter Todd. Now, my question, if replace by fee doesn't allow me to change the inputs or the outputs, I can only add outputs... what can I do with this feature? If I sent a tx and want to replace it with a higher fee one, the higher fee one can only have maybe additional change addresses or another payment, if the inputs suffice? Do we have any real use cases? You're a bit mistaken there: standard RBF lets you change anything, and FSS RBF lets you modify inputs and add outputs and/or make the value of outputs higher. P.S. is it planned to include this by default in bitcoin core 10.0.3 or it will remain just on Peter's branch? Any significant change to mempool policy like RBF is very unlikely to be incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be too large a change for a minor, mostly bugfix, release. Having said that, I already maintain a standard RBF branch for v0.10.x, and have been asked by a major minor to backport FSS RBF for v0.10.x as well. -- 'peter'[:-1]@petertodd.org 0b9e6c1ce35e6e06c01b1f381840bcd9297f307cb1e6aae8 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] A suggestion for reducing the size of the UTXO database
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote: I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30. The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment and wait for it to confirm. Then send a payment and, before it confirms, try to send another one. The wallet won't let you send the second payment. It'll say something like, You need x.xx more bitcoins to make this payment. But if you wait for your first payment to confirm, then you'll be able to make the second payment. If it matters, I configure the app to connect only to my own trusted Bitcoin node, so I only ever have one active connection at most. I notice that outgoing payments never show as Sent until they appear in a block, presumably because the app never sees the transaction come in over any connection. Yes, that's the issue. Because you're connecting only to one node, you don't get any instant confirmations -- due to a Bitcoin protocol limitation you can only get them from nodes you don't post the tx to. Odd, I just tried the above as well - with multiple peers connected - and had the exact same problem. -- 'peter'[:-1]@petertodd.org 0e83c311f4244e4eefb54aa845abb181e46f16d126ab21e1 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 that's 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1's change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF costs you more than you save -- 'peter'[:-1]@petertodd.org 134ce6577d4122094479f548b997baf84367eaf0c190bc9f signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote: Wallets are incentivised to do a better job with defragmentation already, as if you have lots of tiny UTXOs then your fees end up being huge when trying to make a payment. The reason they largely don't is just one of manpower. Nobody is working on it. As a wallet developer myself, one way I'd like to see this issue be fixed by making free transactions more reliable. Then wallets can submit free transactions to the network to consolidate UTXOs together, e.g. at night when the user is sleeping. They would then fit into whatever space is available in the block during periods of low demand, like on Sunday. This can cause problems as until those transactions confirm, even more of the user's outputs are unavailable for spending, causing confusion as to why they can't send their full balance. It's also inefficient, as in the case where the user does try to send a small payment that could be satisfied by one or more of these small UTXO's, the wallet has to use a larger UTXO. With replace-by-fee however this problem goes away, as you can simply double-spend the pending defragmentation transactions instead if they are still unconfirmed when you need to use them. -- 'peter'[:-1]@petertodd.org 0aa9033c06c10d6131eafa3754c3157d74c2267c1dd2ca35 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] First-Seen-Safe Replace-by-Fee
Summary --- First-seen-safe replace-by-fee (FSS RBF) does the following: 1) Give users effective ways of getting stuck transactions unstuck. 2) Use blockchain space efficiently. without: 3) Changing the status quo with regard to zeroconf. The current Bitcoin Core implementation has first-seen mempool behavior. Once transaction t1 has been accepted, the transaction is never removed from the mempool until mined, or double-spent by a transaction in a block. The author's previously proposed replace-by-fee replaced this behavior with simply accepting the transaction paying the highest fee. FSS RBF is a compromise between these two behaviors. Transactions may be replaced by higher-fee paying transactions, provided that all outputs in the previous transaction are still paid by the replacement. While not as general as standard RBF, and with higher costs than standard RBF, this still allows fees on transaction to be increased after the fact with less cost and higher efficiency than child-pays-for-parent in many common situations; in some situations CPFP is unusable, leaving RBF as the only option. Semantics - For reference, standard replace-by-fee has the following criteria for determining whether to replace a transaction. 1) t2 pays fees than t1 2) The delta fees pay by t2, t2.fee - t1.fee, are = the minimum fee required to relay t2. (t2.size * min_fee_per_kb) 3) t2 pays more fees/kb than t1 FSS RBF adds the following additional criteria to replace-by-fee before allowing a transaction t1 to be replaced with t2: 1) All outputs of t1 exist in t2 and pay = the value in t1. 2) All outputs of t1 are unspent. 3) The order of outputs in t2 is the same as in t1 with additional new outputs at the end of the output list. 4) t2 only conflicts with a single transaction, t1 5) t2 does not spend any outputs of t1 (which would make it an invalid transaction, impossible to mine) These additional criteria respect the existing first-seen behavior of the Bitcoin Core mempool implementation, such that once an address is payed some amount of BTC, all subsequent replacement transactions will pay an equal or greater amount. In short, FSS-RBF is zeroconf safe and has no affect on the ability of attackers to doublespend. (beyond of course the fact that any changes what-so-ever to mempool behavior are potential zeroconf doublespend vulnerabilities) Implementation -- Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176 A backport to v0.10.2 is pending. An implementation of fee bumping respecting FSS rules is available at: https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py Usage Scenarios --- Case 1: Increasing the fee on a single tx - We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size with the minimal relay fee, 2.26uBTC. Increasing the fee while respecting FSS-RBF rules requires the addition of one more txin, with the change output value increased appropriately, resulting in transaction t2, size 374 bytes. If the change txout is sufficient for the fee increase, increasing the fee via CPFP requires a second 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total of 566 bytes. Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in cases where the original transaction didn't have a change output. Case 2: Paying multiple recipients in succession We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice. We now need to pay Bob. With plain RBF we'd just add a new outptu and reduce the value of the change address, a 90% savings. However with FSS RBF, decreasing the value is not allowed, so we have to add an input. If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can be created, 2*226=452 bytes in total. With FSS RBF we can replace t1 with a 2-in-3-out tx paying both, increasing the value of the change output appropriately, resulting in 408 bytes transaction saving 10% Similar to the above example in the case where the change address of t1 is insufficient to pay Bob the end result is one less transaction output in the wallet, defragmenting it. Spending these outputs later on would require two 148 byte inputs compared to one with RBF, resulting in an overall savings of 25% Case 3: Paying the same recipient multiple times For example, consider the situation of an exchange, Acme Bitcoin Sales, that keeps the majority of coins in cold storage. Acme wants to move funds to cold storage at the lowest possible cost, taking advantage of periods of higher capacity. (inevitable due to the poisson nature of block creation) At the same time they would like to defragment their incoming outputs to keep redemption costs low,
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote: On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote: Do any wallets actually do this yet? Not that I know of, but they do seed their address database via DNS, which you can poison if you control the LAN's DNS resolver. I did this for a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well over a hundred lightweight wallets, all trying to connect to the Bitcoin P2P network over a very bandwidth-constrained Internet link, so I poisoned the DNS and rejected all outbound connection attempts on port 8333, to force all the wallets to connect to a single local full node, which had connectivity to a single remote node over the Internet. Thus, all the lightweight wallets at the festival had Bitcoin network connectivity, but we only needed to backhaul the Bitcoin network's transaction traffic once. Interesting! What festival was this? -- 'peter'[:-1]@petertodd.org 03ce9f2f90736ab7bd24d29f40346057f9e217b3753896bb signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet
My replace-by-fee patch is now available for the Bitcoin Core v0.10.2 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2 This release fixes a serious DoS attack present in previous releases. Upgrading is strongly recommended for relay nodes, and mandatory for miners. Users of Luke-Jr's gentoo distribution should either disable RBF until a patch is released, or run their node behind a patched node. Previously replacements that spent outputs the transactions they conflicted with would be accepted. This would lead to orphaned transactions in the mempool, a potential bandwidth DoS attack for relay nodes, and even worse, on mining nodes would cause Bitcoin to crash when CreateNewBlock() was called. Thanks goes to to Suhas Daftuar for finding this issue. Additionally, while investigating this issue I found that Andresen/Harding's relay doublespends patch¹, included in Bitcoin XT², also fails to verify that doublespends don't spend outputs of the transactions they conflict with. As the transactions aren't accepted to the mempool the issue is simply a variant of the bandwidth DoS attack that's a well-known issue of Bitcoin XT. However, interestingly in testing I found that Schildbach's Android Bitcoin Wallet³ fails to detect this case, and displays the transaction as a valid unconfirmed transaction, potentially leading to the user being defrauded with a doublespend. While a well-known issue in general - Schildbach's implementation trusts peers to only send it valid transactions and doesn't even detect doublespends it receives from peers - it's interesting how in this case the attacker doesn't need to also do a sybil attack. 1) https://github.com/bitcoin/bitcoin/pull/3883 2) https://github.com/bitcoinxt/bitcoinxt 3) https://play.google.com/store/apps/details?id=de.schildbach.wallet -- 'peter'[:-1]@petertodd.org 026ca21b4a83e1a818be96db4b532b7e9be2f60d47efff0a signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ChainDB Whitepaper
---
ChainDB has a lot of similarities with my Zookeyv(5) proposal, as well
as some key differences. To recap the idea was to come to consensus on a
key:value mapping, such that there was a well-defined cost to change any
particular k:v pair, and such that 'uncontroversial' key:value pairs
would become more expensive to change over time as latter k:v pairs
would add to the cost to change of previous ones.
My original proposal was create a DAG of sacrifices, each committing a
key:value pair, and one or more previous nodes. (the case where n=1
being a linear chain) Nodes that set a key:value already assigned would
be considered invalid. For any tip you'd be able to determine a sum
sacrifice, and equally, a sum sacrificed on top of any key:value pair.
In hindsight, the rule set could be extended to all kinds of situations
akin to a blockchain. (as you propose)
A key question I came up with was whether or not the minimal data
required to prove the shape of the graph be published directly in the
blockchain. e.g. if a node consists of {H(key), H(value),
prev_node_hash[]} do you require those values to be themselves published
in the blockchain, or are they hidden behind a hash? The latter is more
efficient and censorship resistant, while the former makes it possible
to detect possible 51% attacks and outspend them. (Note how this notion
of reactive security can be efficiently used to fend off attackers by
outspending them after the fact, while keeping sacrifices low in the
general case; the sacrifice could even be crowdfunded with
SIGHASH_ANYONECANPAY transactions)
1) [Bitcoin-development] Disentangling Crypto-Coin Mining: Timestamping,
Proof-of-Publication, and Validation
Peter Todd, Nov 19th, 2013,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
2) https://github.com/bitcoin/bitcoin/pull/5863
3) https://en.bitcoin.it/wiki/Fidelity_bonds
4) Factom - Business Processes Secured by Immutable Audit Trails on the
Blockchain
Paul Snow et. al, Nov 17th 2014,
https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper.pdf
5) #bitcoin-wizards discussion, May 31st 2013
--
'peter'[:-1]@petertodd.org
0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
signature.asc
Description: Digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed additional options for pruned nodes
On Tue, May 12, 2015 at 09:05:44AM -0700, Jeff Garzik wrote: A general assumption is that you will have a few archive nodes with the full blockchain, and a majority of nodes are pruned, able to serve only the tail of the chains. Hmm? Lots of people are tossing around ideas for partial archival nodes that would store a subset of blocks, such that collectively the whole blockchain would be available even if no one node had the entire chain. -- 'peter'[:-1]@petertodd.org 156d2069eeebb3309455f526cfe50efbf8a85ec630df7f7c signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote: It should actually be straightforward to softfork RCLTV in as a negative CLTV. All nLockTime are = any negative number, so a negative number makes CLTV a no-op always. Therefore, it is clean to define negative numbers as relative later. It's also somewhat obvious to developers, since negative numbers often imply an offset (eg, negative list indices in Python). Doing this makes handling the year 2038 problem a good deal more complex. The CLTV codebase specifically fails on negative arguments to avoid any ambiguity or implementation differences here. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
On Mon, May 11, 2015 at 04:03:29AM -0300, Sergio Lerner wrote: Arguments against reducing the block interval 1. It will encourage centralization, because participants of mining pools will loose more money because of excessive initial block template latency, which leads to higher stale shares When a new block is solved, that information needs to propagate throughout the Bitcoin network up to the mining pool operator nodes, then a new block header candidate is created, and this header must be propagated to all the mining pool users, ether by a push or a pull model. Generally the mining server pushes new work units to the individual miners. If done other way around, the server would need to handle a high load of continuous work requests that would be difficult to distinguish from a DDoS attack. So if the server pushes new block header candidates to clients, then the problem boils down to increasing bandwidth of the servers to achieve a tenfold increase in work distribution. Or distributing the servers geographically to achieve a lower latency. Propagating blocks does not require additional CPU resources, so mining pools administrators would need to increase moderately their investment in the server infrastructure to achieve lower latency and higher bandwidth, but I guess the investment would be low. It's *way* easier to buy more bandwidth that it is to get lower latency. After all, getting to the other side of the planet via fiber takes at *minimum* 100ms simply due to the speed of light; routing overheads approximately double or triple that for all but highly specialized and very, very expensive, networking services. Bandwidth simply can't fix the speed of light. It's also not at all realistic or desirable to assume connectivity in a single hop, so you can again multiply that base latency by 2-5 times. And on top of *that* you have to take into account latency from hasher to mining pool - time that the hashing power isn't working on the new block because they're work unit hasn't been updated matters just as much as the time to get that block to the pool in the first place. Being forced to reduce that latency is very damaging to the ecosystem as you're making it more profitable to keep hashing power centralized. In any case, even with 10 minute blocks pools already pay a lot of attention to latency... Why make that problem 10x worse? 2. It will increase the probability of a block-chain split The convergence of the network relies on the diminishing probability of two honest miners creating simultaneous competing blocks chains. To increase the competition chain, competing blocks must be generated in almost simultaneously (in the same time window approximately bounded by the network average block propagation delay). The probability of a block competition decreases exponentially with the number of blocks. In fact, the probability of a sustained competition on ten 1-minute blocks is one million times lower than the probability of a competition of one 10-minute block. So even if the competition probability of six 1-minute blocks is higher than of six ten-minute blocks, this does not imply reducing the block rate increases this chance, but on the contrary, reduces it. Can you explain your reasoning here in detail? 4. Reducing the block propagation time on the average case is good, but what happen in the worse case? Most methods proposed to reduce the block propagation delay do it only on the average case. Any kind of block compression relies on both parties sharing some previous information. In the worse case it's true that a miner can create and try to broadcast a block that takes too much time to verify or bandwidth to transmit. This is currently true on the Bitcoin network. Nevertheless there is no such incentive for miners, since they will be shooting on their own foots. Peter Todd has argued that the best strategy for miners is actually to reach 51% of the network, but not more. In other words, to exclude the slowest 49% Actually the correct figure is less than ~30%: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html percent. But this strategy of creating bloated blocks is too risky in practice, and surely doomed to fail, as network conditions dynamically change. They dynamically change? Source? Remember that the strategy still gives you a benefit if you simply target, say, 75% rather than the minimum threshold. Also it would be perceived as an attack to the network, and the miner (if it is a public mining pool) would be probably blacklisted. How do you see that blacklisting actually being done? Equally, it's easy to portray such mining as being for the good of Bitcoin - we're just making transaction cheap! tough luck if your shitty pool can't keep up This is quite unlike selfish mining. 7. There has been insufficient testing and/or insufficient research into technical/economic implications or reducing
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Done! https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 -- 'peter'[:-1]@petertodd.org 12c438a597ad15df697888be579f4f818a30517cd60fbdc8 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote: On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: where w represents the weight of the total number of semantical constraints that an idivdual has expressed throught emotivoe packets that I am working on (implementation os difficutlt). I think this is the appropriate route to implemeting a greating block size that will be used in preventing interception of bundled informations and replace value. Client side implmentation will cut down transaction fees for the additional 264 bit implementation and greatly reduce need for ewallet providers to do so. In these posts I am reminded of and sense some qualitative similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk with respect to multigenerational token architectures. In particula,r your AES ModuleK Hashcodes (especially in light of Winternitz compression) may constitute an L_2 norm attractor similar to the motherbase birthpoint metric presented in that prior work. Rethaw and I provided a number of points for consideration which may be equally applicable to your work: https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056 Mr Gomez may find my thesis paper on the creation of imitations of reality with the mathematical technique of Bolshevik Statistics (BS) to be of aid: https://s3.amazonaws.com/peter.todd/congestion.pdf -- 'peter'[:-1]@petertodd.org 00b0388c459b9aff8a93d02bbb87aac6d74b65e9faf7e4c9 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Sat, May 09, 2015 at 01:36:56AM +0300, Joel Joonatan Kaartinen wrote: such a contract is a possibility, but why would big owners give an exclusive right to such pools? It seems to me it'd make sense to offer those for any miner as long as the get paid a little for it. Especially when it's as simple as offering an incomplete transaction with the appropriate SIGHASH flags. Like many things, the fact that they need to negotiate the right at all is a *huge* barrier to smaller mining operations, as well as being an attractive point of control for regulators. a part of the reason I like this idea is because it will allow stakeholders a degree of influence on how large the fees are. At least from the surface, it looks like incentives are pretty well matched. They have an incentive to not let the fees drop too low so the network continues to be usable and they also have an incentive to not raise them too high because it'll push users into using other systems. Also, there'll be competition between stakeholders, which should keep the fees reasonable. If you want to allow stakeholders influence you should look into John Dillon's proof-of-stake blocksize voting scheme: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. As we're talking about ways that other miners can use 20MB blocks to harm the competition, talking about the soft-limit is irrelevant. Similarly, as security engineers we must plan for the worst case; as we've seen before by your campaigns to raise the soft-limit(1) even at a time when the vast majority of transaction volume was from one user (SatoshiDice) soft-limits are an extremely weak form of control. For the proposes of discussing blocksize increase requirements we can stop talking about the soft-limit. 1) https://bitcointalk.org/index.php?topic=149668.0 -- 'peter'[:-1]@petertodd.org 09344ba165781ee352f93d657c8b098c8e518e6011753e59 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY
On Fri, May 08, 2015 at 06:00:37AM -0400, Jeff Garzik wrote: That reminds me - I need to integrate the patch that automatically sweeps anyone-can-pay transactions for a miner. You mean anyone-can-spend? I've got code that does this actually: https://github.com/petertodd/replace-by-fee-tools/blob/master/spend-brainwallets-to-fees.py Needs to have a feature where it replaces the txout set with simply OP_RETURN-to-fees if the inputs don't sign the outputs though. (SIGHASH_NONE for instance) -- 'peter'[:-1]@petertodd.org 0ee99382ac6bc043120085973b7b0378811c1acd8e3cdd9c signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote: Matt, It seems you missed my suggestion about basing the maximum block size on the bitcoin days destroyed in transactions that are included in the block. I think it has potential for both scaling as well as keeping up a constant fee pressure. If tuned properly, it should both stop spamming and increase block size maximum when there are a lot of real transactions waiting for inclusion. The problem with gating block creation on Bitcoin days destroyed is there's a strong potential of giving big mining pools an huge advantage, because they can contract with large Bitcoin owners and buy dummy transactions with large numbers of Bitcoin days destroyed on demand whenever they need more days-destroyed to create larger blocks. Similarly, with appropriate SIGHASH flags such contracting can be done by modifying *existing* transactions on demand. Ultimately bitcoin days destroyed just becomes a very complex version of transaction fees, and it's already well known that gating blocksize on total transaction fees doesn't work. -- 'peter'[:-1]@petertodd.org 0f53e2d214685abf15b6d62d32453a03b0d472e374e10e94 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote: On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder if having a miner flag would be good for the network. Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. Right now pools already get DoSed all the time through their work submission systems; getting DoS attacked via their nodes as well would be a disaster. When in miner mode, the client would reject 4MB blocks and wouldn't build on them. The reference client might even track the miner and the non-miner chain tip. Miners would refuse to build on 5MB blocks, but merchants and general users would accept them. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. -- 'peter'[:-1]@petertodd.org 04bd67400df7577a30e6f509b6bd82633efeabe6395eb65a signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote: Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with graphs, which can't be done in a mailing list post): http://gavinandresen.ninja/the-myth-of-not-full-blocks We don’t need 100% full one megabyte blocks to start to learn about what is likely to happen as transaction volume rises and/or the one megabyte block size limit is raised. Sounds like you're saying we are bumping up against a 1MB limit. However other than the occasional user who has sent a transaction with an extremely low/no fee, what evidence do we have that this is or is not actually impacting meaningful usage form the user's point of view? Do we have evidence as to how users are coping? e.g. do they send time sensitive transactiosn with higher fees? Are people conciously moving low value transactions off the blockchain? Equally, what about the story with companies? You of course are an advisor to Coinbase, and could give us some insight into the type of planning payment processors/wallets are doing. For instance, does Coinbase have any plans to work with other wallet providers/payment processors to aggregate fund transfers between wallet providers - an obvious payment channel application. -- 'peter'[:-1]@petertodd.org 0232164c96eaa6bf7cbc3dc61ea055840715b5a81ee8f6be signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. It's really important that we remember that we're building security software: it *must* hold up well even in the face of attack. That means we need to figure out how it can be attacked, what the cost/profits of such attacks are, and if the holes can be patched. Just testing the software with simulated loads is insufficient. Also, re: breaking, don't forget that this may not be a malicious act. For instance, someone can send contradictory transactions to different parts of the network simultaneously to prevent mempool consistency - there's no easy way to fix this. There are also cases where miners have different policy than others, e.g. version disagreements, commercial contracts for tx mining, etc. Finally, remember that it's not in miners' incentives in many situations for their blocks to propagate to more than ~30% of the hashing power.(1) Personally, I'm really skeptical that we'll ever find a block propagation latency reduction technique that sucesfully meets all the above criteria without changing the consensus algorithm itself. * How do we ensure miners don't cheat and stop validating blocks fully before building on them? This is a significant moral hazard with larger blocks if fees don't become significant, and can lead to dangerous forks. Also, think of the incentives: Why would a miner ever switch from the longest chain, even if they don't actually have the blocks to back it up? * We need a clear understanding of how we expect new full nodes, pruned or not, to sync up to the blockchain. Obviously 20MB blocks significantly increases the time and data required to sync. Are we planning on simply giving up on full validation and trusting others for copies of UTXO sets? Are we going to rely on UTXO commitments? What happens if the UTXO set size itself increases greatly? * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). A good start would be for those players to commit to the general principles of these systems; if they can't commit explain why. For instance I'd be very interested in knowing if services like Coinbase see legal issues with adopting technologies such as payment channels between hosted wallet providers, payment processors, etc. I certainly wouldn't be surprised if they see doing anythign not on-blockchain as a source of legal uncertainty - based on discussions I've had with regulatory types in this space it sounds like there's a reasonable chance protocol details such as requiring that transactions happen on a public blockchain will be baked into regulatory requirements. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Agreed. Not just full blocks with some fees because wallets are including far greater fees
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote: Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. I'm afraid I have come to disagree. I no longer believe this community can reach consensus on anything protocol related. Some of these arguments have dragged on for years. Consensus isn't even well defined - consensus of who? Anyone who shows up? And what happens when, inevitably, no consensus is reached? Stasis forever? Care to be specific? We've made lots of protocol related changes, as well as non-consensus policy changes, often in quite short timeframes, and with little drama. For instance BIP66 adopting is progressing smoothly, and itself was very quickly developed as part of a broader response to a serious OpenSSL flaw. My own BIP65 is getting wide consensus with little drama and good peer review, and that's happening even without as much attention paid to it from myself as I should have been giving it. The BIP62 malleability softfork is going more slowly, but that's because peer review is finding issues and fixing them - something to be expected in an environment where we simply must be cautious. As for the v0.11 release, it will have pruning, perhaps the biggest change to the way Bitcoin Core works that we've ever made. Equally it's notable how many people collaborated on the implementation of pruning, again with little drama. Sure, some stuff has been hard to get consensus on. But those things carry high risks, and involve code and practices known to be dangerous. In most cases we've found out the lack of consensus was spot on, and controversial changes turn out later to have severe security vulnerabilities. I read that as a sign that the peer review and consensus building process works just fine. -- 'peter'[:-1]@petertodd.org 0af0c4ba9d91c00d48c4493899d7235fd819ac76f16d148d signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote: We get asked all the time by corporate clients about scalability. A limit of 7 tps makes them uncomfortable that they are going to invest all this time into a system that has no chance of handling the economic activity that they expect it handle. We always assure them that 7 tps is not the final answer. Your corporate clients, *why* do they want to use Bitcoin and what for exactly? -- 'peter'[:-1]@petertodd.org 054c9d9ae1099ef8bc0bc9b76fef5e03f7edaff66fd817d8 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: Peter: your hypocrisy really is bottomless, isn't it? You constantly claim to be a Righteous Defender of Privacy, but don't even hesitate before publishing hacked private emails when it suits you. Satoshi's hacker had no illusions about your horrible personality, which is why he forwarded that email to you specifically. He knew you'd use it. You should reflect on that fact. It says nothing good about you at all. As you know I was forwarded that email first, and because I *do* respect your privacy I consulting with you via private IRC chat first, and as you wished I didn't publish it. The hacker presumably gave up waiting for me to do so and published it themselves seven months ago; to make that clear I linked the source(1) of the email in my message. Those emails simply are no longer private. Frankly personal attacks like this - your hypocrisy really is bottomless, isn't it?, Satoshi's hacker had no illusions about your horrible personality - simply don't belong on this mailing list and I think we would all appreciate an apology. 1) https://www.reddit.com/r/Bitcoin/comments/2g9c0j/satoshi_email_leak/ -- 'peter'[:-1]@petertodd.org 12a3e40d5ee5c7fc2fb8367b720a9d499468ceb25366c1f3 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote: On 05/07/2015 04:49 PM, Peter Todd wrote: I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do with accusations like NSA ties. I'm not. I'm saying dealing with someone with proven NSA ties is one of the few times when I think the assumption of honest intent should be ignored in this forum. Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything other than honest intent isn't productive in this forum. -- 'peter'[:-1]@petertodd.org 0622ff7c71c105480baf123fe74df549b5a42596fd8bfbcb signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote: I have a lot more written down, a WIP; here are the highlights. - The 1MB limit is an ancient anti-spam limit, and needs to go. - The 1MB limit is economically entrenched at this point, and cannot be removed at a whim. - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. - The core dev team is not and should not be an FOMC. - The bar for major economic change to a $3.2B system should necessarily be high. In the more boring world of investments, this would accompanied by Due Diligence including but not limited to projections for success, failure scenarios, upside risks and downside risks. Projections and fact-based simulations. - There are significant disruption risks on the pro (change it) and con (keep 1MB) sides of the debate. - People are privately lobbying Gavin for this. That is the wrong way to go. I have pushed for a more public debate, and public endorsements (or condemnations) from major miners, merchants, payment processors, stackholders, ... It is unfair to criticize Gavin to doing this. The hard part here will be including the players who aren't individually major, but are collectively important; who is the community? How do you give the small merchants a voice in this discussion? The small time traders? The small time miners? The people in repressive countries who are trying to transact on thier own terms? Legality? Should people involved in 3rd world remittances be included? Even if what they're doing is technically illegal? What about dark markets? If DPR voiced his opinion, should we ignore it? Personally, I'm dubious about trying to make ecosystem-wide decisions like this without cryptographic consensus; fuzzy human social consensus is easy to manipulate. -- 'peter'[:-1]@petertodd.org 13e67b343b1f6d75cc87dfb54430bdb3bcf66d8d4b3ef6b8 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: One thing is the Bitcoin core project where you could argue that the 5 committers decide (I don't know why Wladimir would have any more authority than the others). Because he is formally the maintainer. I quite liked Wladimir's description of what someone with the ability to merge pull requests into Bitcoin Core is: @orionwl github.com/bitcoin/bitcoin repository admin, or maybe just janitor -https://twitter.com/orionwl/status/563688293737697281 In any case, we can't force people to run Bitcoin Core - an unpopular patch that fails to reach consensus is a strong sign that it may not get user acceptance either - so we might as well accept that centralized authority over the development process isn't going to fly and deal with the sometimes messy consequences. Like I said, you're welcome to fork the project and try to get user acceptance for the fork. -- 'peter'[:-1]@petertodd.org 13e67b343b1f6d75cc87dfb54430bdb3bcf66d8d4b3ef6b8 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote: On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of projects which aren't Bitcoin that benefit from filling in the gap left by Bitcoin's restricted transaction rate capability. If Bitcoin fills that gap, Bitcoin wins and those other projects lose. Should decisions about Bitcoin development take into account the desires of competing projects? Well, basically you're asking if we shouldn't assume the people in this discussion have honest intentions. If you want to go down that path, keep in mind where it leads. I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) -- 'peter'[:-1]@petertodd.org 0d49f26380f264abc7cc930fc9cbc7ba80ac068d9648 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote: I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then encouraging merchants and exchanges and web wallets and individuals who think it strikes a reasonable balance to run it. And then, assuming it became a super-majority of nodes on the network, encourage miners to roll out a soft-fork to start producing bigger blocks and eventually trigger the hard fork. Would you please explain what you mean by a soft-fork to start producing bigger blocks -- 'peter'[:-1]@petertodd.org 0d49f26380f264abc7cc930fc9cbc7ba80ac068d9648 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote: What if Gavin popped up right now and said he disagreed with every current proposal, he disagreed with side chains too, and there would be no consensus on any of them until the block size limit was raised. Would you say, oh, OK, guess that's it then. There's no consensus so might as well scrap all those proposals, as they'll never happen anyway. Bye bye side chains whitepaper. If Gavin had good points to make, he'd probably eventually change everyone's mind. But if he fails to do that at some point he'll just get ignored and for all practical purposes won't be considered part of the consensus. Not unlike how if someone suggested we power the blockchain via perpetual motion machines they'd be ignored. Bitcoin is after all a decentralized system so all power over the development process is held only by social consent and respect. At that point I'd suggest Gavin fork the project and go to the next level of consensus gathering, the community at large; I'm noticing this is exactly what you and Gavin are doing. Speaking of, are you and Gavin still thinking about forking Bitcoin Core? If so I wish you the best of luck. Sent: Wednesday, July 23, 2014 at 2:42 PM From: Mike Hearn m...@plan99.net To: Satoshi Nakamoto satos...@gmx.com Subject: Thinking about a fork I don't expect a reply, just getting some thoughts off my chest. Writing them down helps. Forking Bitcoin-Qt/Core has been coming up more and more often lately in conversation (up from zero not that long ago). Gavin even suggested me and him fork it ... I pointed out that maintainers don't normally fork their own software :) The problem is that the current community of developers has largely lost interest in supporting SPV wallets. Indeed any protocol change that might mean any risk at all, for anyone, is now being bogged down in endless circular arguments that never end. The Bitcoin developers have effectively become the new financial regulators: restricting options within their jurisdiction with someone might do something risky being used as the justification. If alternative low-risk protocols were always easily available this would be no problem, but often they require enormous coding and deployment effort or just don't exist at all. Yet, wallets must move forward. If we carry on as now there simply won't be any usable decentralised wallets left and Bitcoin will have become an energy-wasting backbone for a bunch of banks and payment processors. That's so far from your original vision, it's sad. I know you won't return and that's wise, but sometimes I wish you'd left a clearer design manifesto before handing the reigns over to Gavin, who is increasingly burned out due to all the arguments (as am I). Source: https://www.reddit.com/r/Bitcoin/comments/2g9c0j/satoshi_email_leak/ -- 'peter'[:-1]@petertodd.org 066f25b3196b51d30df5c1678fc206fdf55b65dd6e593b05 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote: Peter Todd p...@petertodd.org writes: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV Mildly prefer to put that the other way around. ie. the OP_NOP1 becomes OP_EXTENSION_PREFIX, the next op defines which extended opcode it is (must be a push). There's no good way to implement that option - when the OP_NOPx is executed all that's available to it without a lot of complex work is what's already been pushed to the stack, not what will be pushed to the stack in the future. -- 'peter'[:-1]@petertodd.org 02761482983864328320badf24d137101fab9a5861a59d30 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote: On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote: I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is how much transaction volume the main Bitcoin blockchain will be able to support over the next eleven years. Mhmm, I hadn't thought about this. This makes sense and actually explains the urgency on taking a decision better than anything else I've heard. I've spent a lot of time talking to companies about this, and the problem is telling them that isn't actually very useful; knowing the supply side of the equation isn't all that useful if you don't know the demand side. Problem is we don't really have a good handle on what Bitcoin will be used for in the future, or even for that matter, what it's actually being used for right now. As we saw with Satoshidice before and quite possibly will see with smart contracts (escrows, futures, etc) it's easy for a relatively small number of use cases to drive a significant amount of transaction volume. Yet, as Wladimir and others point out, the fundemental underlying architecture of the blockchain has inherently poor O(n^2) scaling, so there's always some level of demand where it breaks, and/or incentivizes actors in the space to push up against safety stops like soft blocksize limits and get them removed. Note how the response previously to bumping up against soft policy limits was highly public calls(1) at the first hint of touble: Mike Hearn: Soft block size limit reached, action required by YOU 1) https://bitcointalk.org/index.php?topic=149668.0 -- 'peter'[:-1]@petertodd.org 02761482983864328320badf24d137101fab9a5861a59d30 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote: Yes, but this does NOT make an actual policy. Note that the vast majority of miners already apply their own patches to Bitcoin Core, so applying one more is not all that hard. When blocks start to become limited (ie there is any fee left on the table by transactions not included in a block) there becomes incentive for miners to change that behavior pretty quick. Not just that, the vast majority of the hashpower is behind very large miners, who have little to no decentralization pressure. This results in very incompatible incentives, mainly that the incentive would be for the large miners to interconnect in a private network and generate only maximum-size blocks, creating a strong centralization pressure in the network. I'll also point out that miners with the goal of finding more blocks than their competition - a viable long-term strategy to increase market share and/or a short-term strategy to get more transaction fees - actually have a perverse incentive(1) to ensure their blocks do *not* get to more than ~30% of the hashing power. The main thing holding them back from doing that is that the inflation subsidy is still quite high - better to get the reward now than try to push your competition out of business. It's plausible that with a limited blocksize there won't be an opportunity to delay propagation by broadcasting larger blocks - if blocks propagate in a matter of seconds worst case there's no opportunity for gaming the system. But it does strongly show that we must build systems where that worst case propagation time in all circumstances is very short relative to the block interval. 1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html -- 'peter'[:-1]@petertodd.org 04dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). Agreed. I'm not sure if you've seen this, but a good paper on this topic was published recently: The Economics of Bitcoin Transaction Fees Abstract We study the economics of Bitcoin transaction fees in a simple static partial equilibrium model with the specificity that the system security is directly linked to the total computational power of miners. We show that any situation with a fixed fee is equivalent to another situation with a limited block size. In both cases, we give the optimal value of the transaction fee or of the block size. We also show that making the block size a non binding constraint and, in the same time, letting the fee be fixed as the outcome of a decentralized competitive market cannot guarantee the very existence of Bitcoin in the long-term. -http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners kickbacks - leaving us with a fixed blocksize. This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies I think this lack of understanding of the limitations of blockchain tech is very dangerous, never mind, downright misleading. I keep running into startups at conferences with completely unrealistic ideas about how large they'll be able to grow their on-blockchain businesses. For example, a few weeks ago at the Stanford blockchain conference I spoke to a company planning on using multisig escrow contracts to settle financial instruments, and expected to be doing about as many transactions/day on the blockchain for their business within a year or so as all other Bitcoin users currently do combined. These guys quite frankly had no understanding of the issues, and had apparently based their plans on the highly optimistic Bitcoin wiki page on scalability.(1) (I'd fix this now, but the wiki seems to not be allowing logins) We'd do a lot of startups a lot of good to give them accurate, and honest, advice about the scalability of the system. The wiki definitely isn't that. Neither is the bitcoin.org developer documentation(2), which doesn't mention scalability at all. which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way? The only proposal that I've seen that attempts to do this is John Dillon's proof-of-stake blocksize vote(4), and that is far from getting consensus. 1) https://en.bitcoin.it/wiki/Scalability 2) https://bitcoin.org/en/developer-guide 3) http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea 4) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 04dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1
My replace-by-fee patch is now available for the v0.10.1 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1 No new features in this version; this is simply a rebase for the Bitcoin Core v0.10.1 release. (there weren't even any merge conflicts) As with the Bitcoin Core v0.10.1, it's recommended to upgrade. The following text is the copied verbatim from the previous release: What's replace-by-fee? -- Currently most Bitcoin nodes accept the first transaction they see spending an output to the mempool; all later transactions are rejected. Replace-by-fee changes this behavior to accept the transaction paying the highest fee, both absolutely, and in terms of fee-per-KB. Replaced children are also considered - a chain of transactions is only replaced if the replacement has a higher fee than the sum of all replaced transactions. Doing this aligns standard node behavior with miner incentives: earn the most amount of money per block. It also makes for a more efficient transaction fee marketplace, as transactions that are stuck due to bad fee estimates can be unstuck by double-spending them with higher paying versions of themselves. With scorched-earth techniques⁵ it gives a path to making zeroconf transactions economically secure by relying on economic incentives, rather than honesty and alturism, in the same way Bitcoin mining itself relies on incentives rather than honesty and alturism. Finally for miners adopting replace-by-fee avoids the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior, as seen in Harding's proposal⁶ that miners collectively 51% attack miners who include doublespends in their blocks - an unavoidable consequence of imperfect p2p networking in a decentralized system - or even Hearn's proposal⁷ that a majority of miners be able to vote to confiscate the earnings of the minority and redistribute them at will. Installation Once you've compiled the replace-by-fee-v0.10.1 branch just run your node normally. With -debug logging enabled, you'll see messages like the following in your ~/.bitcoin/debug.log indicating your node is replacing transactions with higher-fee paying double-spends: 2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes Additionally you can tell if you are connected to other replace-by-fee nodes, or Bitcoin XT nodes, by examining the service bits advertised by your peers: $ bitcoin-cli getpeerinfo | grep services | egrep '((0003)|(0401))' services : 0003, services : 0401, services : 0401, services : 0003, services : 0401, services : 0401, services : 0003, services : 0003, Replace-by-fee nodes advertise service bit 26 from the experimental use range; Bitcoin XT nodes advertise service bit 1 for their getutxos support. The code sets aside a certain number of outgoing and incoming slots just for double-spend relaying nodes, so as long as everything is working you're node should be connected to like-minded nodes a within 30 minutes or so of starting up. If you *don't* want to advertise the fact that you are running a replace-by-fee node, just checkout a slightly earlier commit in git; the actual mempool changes are separate from the preferential peering commits. You can then connect directly to a replace-by-fee node using the -addnode command line flag. 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/bitcoin/bitcoin/pull/3883 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html -- 'peter'[:-1]@petertodd.org 059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] CLTV opcode allocation; long-term plans?
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. I have two lines of thought on this: 1) We're going to end up with a Script v2.0 reasonably soon, probably based on Russel O'Connor and Pieter Wuille's Merkelized Abstract Syntax Tree³ idea. This needs at most a single OP_NOPx to implement and mostly removes the scarcity of upgradable NOP's. 2) Similarly in script v1.0 even if we do use up all ten OP_NOPx's, the logical thing to do is implement an actual opcode # OP_EXTENDED. 3) It's not clear what form a relative CLTV will actually take; the BIP itself proposes a OP_PREVOUT_HEIGHT_VERIFY/OP_PREVOUT_DATA along with OP_ADD, with any opcode accessing non-reorg-safe prevout info being made unavailable until the coinbase maturity period has passed for soft-fork safeness. That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Interested in your thoughts. 1) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-98568239 2) https://github.com/bitcoin/bitcoin/pull/5496 3) http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-nityas.pdf -- 'peter'[:-1]@petertodd.org 0908b2eb1cb0660069547abdddad7fa6ad4e743cebe549de signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille wrote: As softforks almost certainly require backports to older releases and other software anyway, I don't think they should necessarily be bound to Bitcoin Core major releases. If they don't require large code changes, we can easily do them in minor releases too. The code changes for absolute CLTV are quite small, and easily ported to any Bitcoin Core version. What's the oldest version you think we need backports for? -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin core 0.11 planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY implemented on Bitcoin will be something like summer 2016, a year and a half after it got adopted on Viacoin. (and a few other alts whose names I forget) Right now the shortest path to adoption would be to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. While there's been proposal to change the way the upgrade mechanism triggers to a multiple parallel fork scheme, that is quite complex, stateful, and will need lots of review, probably a few months worth; faster would be to continue with the existing mechanism. IMO the main reason to accelerate CLTV is scalability. The only viable scalability improvements possible in the short/medium term that don't entirely rely on trusting third parties are payment channel based. While we have a working payment channel scheme - Jeremy Spilman's refund tx based system - it is fairly complex, needs good and immediate backups, and is susceptible to tx malleability. CLTV fixes those issues robustly. Of course, payment channel schemes can start off with Spilman's scheme first and go to CLTV later, but that is a lot of extra code to be written and later depreciated - I'm sure many authors are dubious about going down that path. Thoughts? On 28 April 2015 03:44:16 GMT-04:00, Wladimir J. van der Laan laa...@gmail.com wrote: Hello all, The release window for 0.11 is nearing, I'd propose the following schedule: 2015-05-01 Soft translation string freeze Open Transifex translations for 0.11 Finalize and close translation for 0.9 2015-05-15 Feature freeze, string freeze 2015-06-01 Split off 0.11 branch Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 2015-07-01 Release 0.11.0 final (aim) In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. Wladimir -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVP2Wy AAoJEMCF8hzn9LncqOcH/3rDFbgWprqTfk8dKWAItRcY6ZyiQ+dNrqNgymaNP5Ig MNKaTmWYyZRH6PW13JOv72ArXia+D82Mp5reTaLIb3TV5uef2biruOCaH9eI8Uv5 i2PCBLw3uqZIZZ5Qr/7nlp2CaBQIGDK3fg3jx10UyWpg4BxkKP2mLJibMG8l3JcK Moi/kh6lvwySpT8NYtZfXax+5AQ2oLXiSzbFF8P0ioI9fJYaoVCAyS5VEE4KsZnV thOaoPAWoK+spEYKFrjvyXnQXFe6m+KPfRPU3WKYSFhI7m8MW6bKxEnD0Lffo6qU YS6jsE3A0LoKs4kD73ivHcMeXDhO6LXyPAu8zQtgGr8= =Z/GT -END PGP SIGNATURE- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: And a new softfork rule could enforce that all new CTxIn set nHeight to the correct height in which its corresponding prevout got into the chain. That would remove the need for the TxOutputGetter param in bitcoinconsensus_verify_script, but unfortunately it is not reorg safe (apart from other ugly implementation details). Wait, wait, this can be made reorg-safe and more backards compatible. The new validation rule at the tx validation level (currently in main::CheckInputs()) would be snip So, seems to me that RCLTV opens up a whole rats nest of design decisions and compromises that CLTV doesn't. Yet CLTV itself is a big step forward, it's been implemented on Viacoin for the past few months with no issues found, and has an extremely simple and easy to audit implementation. I think I'm going to argue we implement it as-is in a soft-fork. Pieter Wuille's been working on a new way to handle soft-fork upgrades in the block nVersion field, so this would be a good opportunity to add something simple and well tested, and also make sure the new nVersion soft-fork mechanism works. Equally, doing both at the same time ensures we don't burn yet another version bit. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote: Hi William, I personally prefer this solution, since it nails the problem completely with one simple and obvious change. The BIP 62 approach is more like a game of wac-a-mole. The two are complementary, not competing. BIP62 prevents *non-signers* from mutating the transactions, which is very important. I strongly disagree. There are exactly two cases where mutation matters to normal wallets: 1) Spending unconfirmed change. This can be more efficiently done by double-spending the first tx with a second that pays both recipients. 2) Large reorganizations. Making mutation impossible makes it more likely that after a large reorg all previously confirmed transactions will make it back to the blockchain succesfully. Meanwhile, the whack-a-mole aspect of BIP62 is worrying - it's very likely we'll miss a case. Even right now there are edge cases without good solutions, like how in a multisig environment any of the key holders can mutate transactions. Building wallets that make strong assumptions about malleability and fail if those assumptions turn out to be wrong is poor engineering. The 'Build your own nHashType' proposal enables chained transactions even in the face of *signers* mutating the transaction. I believe that integrating both will lead to the best defense against transaction malleability, and will enable more complicated uses of chained transactions (such as micropayment channels). While I think there are better ways to do 'Build your own nHashType' than what was recently proposed, I strongly agree that for protocols that really, truly, need malleability resistance it's far better to use a purpose-built signature hashing algorithm. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote: In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the height of the output being spent and then has identical semantics to CLTV. Depending on what you mean by identical this isn't actually reorg safe. For instance consider this implementation: nLockTime = stack[-1] + prevout.nHeight if (nLockTime txTo.nLockTime): return False Used with this scriptPubKey: 10 RCLTV DROP pubkey CHECKSIG If I create that output in tx1 which is mined at height 42 I can spend it in a tx2 at height 42+10 by setting tx2's nLockTime to 42+10, for instance 53. However if a reorg happens and tx1 ends up at height 43 after the reorg I'm stuck - tx2's nLockTime is set at 42. Thus RCTLV is only reorg safe if the height is compared against the actual block height of the block containing the spending transaction, not the spending transaction's nLockTime. A slightly different API (and different name) was described by maaku at http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154 which does a better job of saving softfork-available opcode space. There are two major drawbacks to adding such an operation, however. 1) More transaction information is exposed inside the script (prior to CLTV we only had the sigchecking operation exposed, with a CLTV and RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions). 2) Bitcoin Core's mempool invariant of all transactions in the mempool could be thrown into one overside block and aside from block size, it would be valid becomes harder to enforce. Currently, during reorgs, coinbase spends need checked (specifically, anything spending THE coinbase 100 blocks ago needs checked) and locktime transactions need checked. With such a new operation, any script which used this new opcode during its execution would need to be re-evaluated during reorgs. Yup, definitely kinda ugly. If the above style of RCTLV was used, one possibility might be to make the relative locktime difference be required to be at least 100 blocks, same as the coinbase maturity, and just accept that it's probably not going to cause any problems, but could in an extremely big reorg. But re-orgs that big might be big enough that we're screwed anyway... With the 100 block rule, during a sufficiently large reorg that coinbases become unavailble, simply disconnect entire blocks - all txouts created by them. I think both of these requirements are reasonable and not particularly cumbersome, and the value of such an operation is quite nice for some protocols (including settings setting up a contest interval in a sidechain data validation operation). So to be clear, right now the minimal interface to script execution is simply: int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, unsigned int scriptPubKeyLen, const unsigned char *txTo, unsigned int txToLen, unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err); Where scriptPubKey is derived from the unspent coin in the UTXO set and txTo is the transaction containing the script that is being executed. The UTXO set itself currently contains CCoins entries, one for each transaction with unspent outputs, which basically contain: nVersion - tx nVersion nHeight - Height of the block the transaction is contained in. vout - Unspent CTxOut's of the transaction. The block nTime isn't directly available through the UTXO set, although it can be found in the block headers. This does require nodes to have the block headers, but at 4MB/year growth it's reasonable to assume the UTXO set will grow faster. Script execution does not have direct access to the current block height/block time, however it does have indirect access via nLockTime. Thus we have a few possibilities: 1) RCLTV against nLockTime Needs a minimum age COINBASE_MATURITY to be safe. 2) RCLTV against current block height/time Completely reorg safe. 3) GET_TXOUT_HEIGHT/TIME diff ADD CLTV To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age COINBASE_MATURITY. This can be implemented by comparing against nLockTime. All three possibilities require us to make information about the prevout's height/time available to VerifyScript(). The only question is if we want VerifyScript() to also take the current block height/time - I see no reason why it can't. As for the mempool, keeping track of what transactions made use of these opcodes so they can be reevaluated if their prevouts are re-organised seems fine to me. Absolute CLTV = If we are going to make the block
Re: [Bitcoin-development] Double spending and replace by fee
On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote: Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants. Some questions: 1) Are you contractually obliged to accept zeroconf transactions with existing customers? I keep hearing rumors of this, but would like some confirmation. In particular, it would be good to know if you have the option of turning zeroconf off at all, contractually speaking. 2) What are your double-spend losses to date? 3) Are you actively marketing zeroconf guarantees to new customers? You're API is a bit unclear as to what exactly those guarantees are; looks like they only apply if a merchant has convert to fiat turned on. 4) What are your short, medium, and long term plans to move away from dependency on first-seen mempool policy? e.g. hub-and-spoke payment channels, Lightning network, off-chain, etc. 5) What is your plan for new Bitcoin Core releases that break zeroconf via changed tx acceptance rules? Basically every release we've ever made has added a zeroconf exploit due to different tx acceptance rules. (e.g. my 95% success rate last summer) 6) What are your plans for Bitcoin Core releases that fundementally break zeroconf? For instance changes like limiting the mempool size create zeroconf vulnerabilities that can't be avoided in many situations. Yet they may also be unavoidably needed for, for instance, DoS protection. Will you oppose these improvements? 7) If a mining pool adopts adopted policy that broke zeroconf, e.g. replace-by-fee, would you take any action? 8) Would you take legal action against a mining pool for adopting replace-by-fee publicly? 9) Would you take action against a mining pool who is mining double-spends without explanation? e.g. one that claims not to be running non-Bitcoin Core policy, but keeps on mining double-spends. -- 'peter'[:-1]@petertodd.org 089abd68efc18c03d2a294295f3706a13966613a3ff3b390 signature.asc Description: Digital signature -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
On Thu, Apr 09, 2015 at 10:56:20PM -0400, Stephen Morse wrote: On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd p...@petertodd.org wrote: For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature can say valid if you run these additional opcodes and they return true where those additional opcodes take the transaction, hash it in the defined way, and verify that the ECC signature correctly signs that hash and the hash of the additional opcodes. For instance in this case making a signature that's only valid if the tx fee is less than the defined amount would be a matter of GET_FEE max fee + 1 LESSTHAN VERIFY I've never been able to really see a good use case for OP_CODESEPARATOR, and I'm not sure I completely have my head wrapped around what you're proposing. From this http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparator-used-for and this https://bitcointalk.org/index.php?topic=52949.msg631255#msg631255, though, it seems like OP_CODESEPARATOR cannot really be made useful unless you already have a way to sign without hashing the TXIDs referenced by your input, in which case you need to modify the nHashType. I wrote up how to do this on #bitcoin-wizards, Dec 9th 2014: 17:13 petertodd hearn: even now you can use OP_CODESEPARATOR to implement efficient payword schemes 17:14 petertodd hearn: early on you could have used it to do some really useful after-the-fact signing delegation by wrapping a IF ENDIF around the CODESEPARATOR introduced into the middle of the scriptSig/scriptPubKey pair - shame we got rid of that without thinking the design through 17:15 petertodd hearn: e.g. create a signature that delegates signing authority to another pubkey 17:15 petertodd probably all 100% accidental... but a nice accident 17:16 hearn it's probably for the best. i can imagine such things being a surprise for implementations not expecting them. a script 2.0 effort that incorporates lots of neat features but still lets script 1.0 work would be nice to have, one day 17:17 petertodd satoshi belived in 1 implementation, and by putting CODESEPARATOR into the scriptSig/scriptPubKey concatenation you had to opt-in to making that feature possible to use in any particular scriptPubKey 17:17 petertodd w/o the mis-matched ENDIF you can't pull off that trick because you can't turn CODESEPARATOR off 17:19 petertodd to be explicit: scriptPubKey: ENDIF pubkey CHECKSIG, then the normal case is scriptSig: signature 1 IF 17:19 petertodd they concatenate to signature 1 IF ENDIF pubkey CHECKSIG, CODESEPARATOR is evaluated, and the signature is evaluated on the script ENDIF pubkey CHECKSIG 17:20 petertodd to delegate signing authority after the fact sign a signature on the script pubkey2 0 IF ENDIF pubkey CHECKSIG 17:21 petertodd (remember that CODESEPARATORS are removed by SignatureHash()) 17:22 petertodd oops, I mean: pubkey2 CHECKSIGVERIFY 0 IF ENDIF pubkey CHECKSIG 17:22 petertodd anyway, to finally spend it, create another signature with pubkey2 signing the script pubkey2 CHECKSIGVERIFY 0 IF ENDIF pubkey CHECKSIG again, and finally spend it with the scriptSig: pubkey-sig pubkey2-sig CODESEPARATOR pubkey2 0 IF 17:24 petertodd after concatenation the script: pubkey-sig pubkey2-sig CODESEPARATOR pubkey2 0 IF CODESEPARATOR ENDIF pubkey CHECKSIG is evaluated, the inner signature satisfies, and the outer signature is satisfied only if the scriptPubKey was essentially changed after the fact to also require the inner, second, pubkey2 to be satisfied 17:26 petertodd a nice use-case would, forinstance, have been to have a signing robot be able to create signatures offline for a given txout with SIGHASH_SINGLE such that you had a spending limit enforced, and exactly who was then allowed to spend the funds - say a department of a company - could be picked after the fact without re-spending the txout 17:33 petertodd gmaxwell: re: script validation state, a good model would be to have the tx input to EvalScript() essentially be a CMerkleTx, and the prevout scriptPubKey be the prevout CTxOut (*maybe* the prevout tx itself... bit dubious there...) -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote: On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse stephencalebmo...@gmail.com wrote: Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Think about what slow transaction verification speed means. Slower propagation across the network. More work per node. Greater opportunity for algorithmic attacks, races and other shenanigans by attackers. Keep in mind though we can always make part of the soft-fork be to make the hash operations in the new CHECKSIG mechanism consume sigops. For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature can say valid if you run these additional opcodes and they return true where those additional opcodes take the transaction, hash it in the defined way, and verify that the ECC signature correctly signs that hash and the hash of the additional opcodes. For instance in this case making a signature that's only valid if the tx fee is less than the defined amount would be a matter of GET_FEE max fee + 1 LESSTHAN VERIFY This can be a much more general mechanism with easy to test modular opcodes; for the consensus-critical codebase this can result in a much easier and simpler to test CHECKSIG facility than a dozen new flags. -- 'peter'[:-1]@petertodd.org 06975f442f50caa4fcc18e165746b3c77b641b75635afecb signature.asc Description: Digital signature -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] My thoughts on the viability of the Factom token
On Fri, Mar 20, 2015 at 12:46:18AM -0500, Brian Deery wrote: Greetings mailing list. Not sure that this content is 100% appropriate here, but Peter Todd invited me to post this for archival purposes. The original thread has been removed from the search results, but is still up here: http://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/ I have added more thoughts too. Thanks. You know, looking though your writeup, I think we're talking past each other. I've found with a lot of other projects a good way to start is to explicitly list what you think Factom *prevents* from happening. It is after all security software - the most important thing it does is what it prevents the attacker from doing. Be specific - you really need to nail down exactly what kind of guarantees you're trying to get out of the Factom system. -- 'peter'[:-1]@petertodd.org 064a6b620c22d89697757f4d81c3b839e50b03e2d3f8e168 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Double spending and replace by fee
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Would you so us all a favor and make a list of companies *actually* relying on first-seen mempool behaviour. Because I've been having a hard time actually finding anyone who does who hasn't given up on it. Not very useful to talk about attacks against hypothetical defences. On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn m...@plan99.net wrote: I've written a couple of blog posts on replace by fee and double spending mitigations. They sum up the last few years (!) worth of discussions on this list and elsewhere, from my own perspective. I make no claim to be comprehensive or unbiased but I keep being asked about these topics so figured I'd just write up my thoughts once so I can send links instead of answers :) And then so can anyone who happens to agree. (1) Replace by fee scorched earth, a counter argument: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d This article lays out the case against RBF-SE and argues it is harmful to Bitcoin. (2) Double spending and how to make it harder: https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 This article summarises a couple of double spending incidents against merchants and then discusses the following techniques: 1. Risk analysis of transactions 2. Payment channels 3. Countersigning by a trusted third party 4. Remote attestation 5. ID verification 6. Waiting for confirmations 7. Punishment of double spending blocks I hope the material is useful / interesting. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVFrj2 AAoJEMCF8hzn9LncxH8IAIFVwBvpNQfDJTJGEHT8LHQEIB0hLmEMSWwYRovHdwob u3mUigF7dpYoQfL9eU7NqSaNsAkL2WEhBYS9C/OF81AFApxuugnH/VOGz9X4PvJ/ zy5wP12onOrL//8/H9PoGH2dP3fmEe/rdhLelWUABuzyPQaoIaMLTZGREipbbBPK mJ6lBbNhtGGSxV3RgKvkkFYYBCAci/S/ntzpTOuYsgvZIjiXVsxD1uZZ/SiGfS3M R+RIrDX6W/xRdct0gm07KrHMNWo2kPE6uT6egZDxPNP308ddLwGWcvQWTe73bmEL FXsb6gUnfoXwBZfhDav41H4gRdZhLC+gOwVIcx0qLOY= =t0aZ -END PGP SIGNATURE- -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] My thoughts on the viability of the Factom token
Repost of https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo for archival/disclosure purposes: I'm very skeptical about the long-term viability of Factom and the value of the Factom token. The idea behind Factom is to create a proof-of-publication medium where facts for some purpose can be published; the token incentivises people to maintain the infrastructure required for that medium. You can think of Factom as a two layer system, with Factom servers provide a layer that in turn is used by secondary proof-of-publication ledgers. By publishing records in the Factom layer you prove that the secondary layer of actual facts is being maintained honestly. For instance one such secondary layer might be the property records of a city using a digital Torrens title system¹ to maintain land titles. Let's look at how this works step by step: * You would know your digitally represented land title was valid because it was in the city's ledger and the digital signatures verify. * You in turn know the *copy* of that ledger that you posess is the official version because you can inspect the ledger maintained by the Factom servers. * You know that ledger is the official Factom layer - not a fork of that ledger - because you can run the Factom consensus protocol against the Bitcoin blockchain. * You know you have the only Bitcoin blockchain and not a fork because of the Bitcoin Proof-of-Work consensus algorithm. That's four steps in total. The problem is step #3 - the Factom consensus layer - requires you to trust the Factom servers. The issue is if the Factom servers ever publish a Factom ledger anchor in the Bitcoin blockchain but don't make the data available you have no way of proving that your Factom-secured ledger - e.g. the city's property title records - is the only copy out there and you're not trying to defraud someone. Those servers are voted in by a (quite complex) consensus algorithm, but ultimately they are trusted third parties that can break your ability to prove your Factom-secured records are honest. Of course in practice if this happens people will just accept it and patch their software to ignore the failure... but then why use Factom at all? You can do the exact same thing with *far* less complexity by just securing your ledger directly in the Bitcoin blockchain, skipping step #3 and the dependency on trusted third parties. (I don't mean putting the ledger itself in the chain, just hashes of it) The only disadvantage to securing your records directly in the Bitcoin blockchain is you have to pay transaction fees to do it. However currently those fees are very small - they'll always be about the cost to make a transaction - and if they do increase it's easy to create meta-ledgers based on explicit trust relationships. For instance a bunch of cities can get together to establish a meta-ledger for all their per-city property title systems, perhaps using efficient threshold-signature² multisig to ensure that a majority of those cities have to sign off on any updates to the meta-ledger. Of course all these Factom alternatives can be argued to bloat the blockchain - but how are we going to force people to use less secure alternatives to just using the blockchain? It's impossible to stop people from securing ledgers in the blockchain technically; our only way to do it is via social pressure like writing angry posts on reddit and lawsuits. tl;dr: For the Facom token to rise in value we need Bitcoin transaction fees to rise greatly, and/or people to choose to use much more complex and less secure systems in preference to much more simple systems. Disclaimer: I've been hired by Factom to review the Factom protocol. I also am working on a competing library called Proofchains that among other things can be used to secure ledgers using Bitcoin directly. That funding model for that effort is to convince individual clients that they need the technology and should pay me to develop it. 1) http://en.wikipedia.org/wiki/Torrens_title 2) https://bitcoinmagazine.com/19528/threshold-signatures-new-standard-wallet-security/ -- 'peter'[:-1]@petertodd.org 0de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a signature.asc Description: Digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 08:02:03AM +, Adam Back wrote: FWIW I've been advocating this kind of thing in various forms for literally years, including to hold fidelity bonded banks honest - what you now call 'federated sidechains' - and most recently Feb 12th on #bitcoin-dev: 19:56 petertodd leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees 19:57 petertodd leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend 19:58 leakypat Yeah, proof of double spend would ideally be done at the protocol level 19:59 petertodd leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas... Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later. Equally, that *is* what replace-by-fee scorched-earth does without the need for a soft-fork, minus the cryptographic proof and with a bit less flexibility. I agree with Mike Jeff. Blowing up 0-confirm transactions is vandalism. Is releasing a version of Bitcoin Core with different IsStandard() rules than the previous version vandalism? Is mining with a different policy than other people vandalism? Is mining at a pool that gets sybil attacked vandalism? Are my replace-by-fee tools an act of vandalism? Because every one of those things causes people to get double-spent in the real world, even losing tens of thousands of dollars until they get some sense and stop treating unconfirmed transactions as confirmed. Is it vandalism if you decide to host a wedding right next to a hairpin corner at a rally race and complain to me that mud is getting on the pretty white dresses? Is it vandalism if I tell that wedding party to fuck off before someone gets hurt? Is it vandalism if some racers take the mudguards off for a few laps to see if we can encourage them to leave before someone gets *actually* hurt? Or someone decides that the solution is to pave the track over and hold a bicycle race instead... -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com wrote: In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to tell whether the motivation was fee replacement, output replacement, or both. My proposal is to always treat these instances as output replacement and punish the sender. The sender needs to make it unambiguously clear it's only a fee replacement by creating a new transaction that produces an output with the desired extra fee and then adding an input that spends it to the original transaction. That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed) Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= =1vbN -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote: My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions. If I understand this is also your own motivation. Indeed, which is why I wrote some easy-to-use and highly effective tools to pull off double-spends and made sure to publicise them and their effectiveness widely. They've had their desired effect and very few people are relying on unconfirmed transactions anymore. As for the remaining, next week alone I'll be volunteering one or two hours of my consulting time to discuss solutions with a team doing person-to-person trading for instance. Like I've said repeatedly, the current weaker 0-conf transactions gets people new to Bitcoin - both individuals and companies - burnt over and over again because inevitably someone eventually gets motivated and breaks them, and suddenly they lose stacks of money. Keeping *that* kind of security around rather than depreciating it ASAP and being honest about what Bitcoin can do does no-one any good. Anyway, there is no one magic solution to this stuff - the best solutions vary greatly on the situation. -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock b...@mattwhitlock.name wrote: On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote: In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction. This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. Great example! Systems that appear more secure than they really are to uninformed users are dangerous. Same reason why brain wallets are such scary technology, and equally, why I like to give a few dollars away every so often to the guys brute forcing weak ones. I keep telling people not to accept transactions with zero confirmations, but no one listens. In my experience there's a pattern of accept unconfirmed; get burned badly/see someone else get burned; stop relying on them Although of course, there's some bias in that people contact me asking what to do after they get burned. :) -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6eKG AAoJEMCF8hzn9LncGz0H/ivA9J4MqsVnkPm9JVAIXgZiT7rAVO0Rp1lO/8PGPS6K dXBFXESicszeBx5yeyQrLUFh58DVgp21sFHSMNTKmujDJJgxNf/ygffN9dTLriwt PJcDWvxPzqyLy2e/CloRonxwlO3+Umv1OiPs1yy7a7auDVAEm1xvh/pc3A48u1bO ++cyxZs8j5yv3Ms2n/FmGekhL9jZHJAgmiVnSks0cMqq9+cYipEjy+FEq3KFGlFI 4iZ58f57g6W7bVqM+9Z6dbLczWobnQ+nfo7lFZWgGdbhKf4Jv7tHOcfSw4nbmJz4 OgWmKtM724h7abOIrqJnTF0u10dmapVv+lRtjiGXo8c= =7W03 -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote: On 2/11/2015 10:47 PM, Peter Todd wrote: My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 This patch immediately simplifies successful double-spends of unconfirmed transactions. But the idea that it gives a path to making zeroconf transactions economically secure is quite dubious. * You don't provide sufficient means to detect and relay double-spends, which is necessary to trigger a scorched-earth reaction. Not all double-spends will conform to your replacement rules. No, OTOH if they don't then the situation is no difference from what we have now, and replace-by-fee does no harm. Meanwhile, relaying of bare double-spend signatures can be implemented in the future, as I suggested last year for your/Andresen's double-spend relaying patch. Did you notice the even more obvious way to defeat ANYONECANPAY scorched earth with that patch? * Maybe XT nodes would help to overcome this. But meanwhile, in the ANYONECANPAY design, Bob's replacement is a triple-spend. Even XT nodes won't relay it. So? RBF nodes will. * It's unclear when, if ever, any senders/receivers will actually try to use scorched-earth as a double-spend deterrent. I suspect many won't, because few people need to rely on unconfirmed transactions anyway. Also, this patch significantly weakens DoS protections: * It removes the early conflict check, making all conflict processing more expensive If you're going to consider replacement, conflict processing will definitely be more expensive. :) An actual DoS attacker would do their DoS attack in a way where conflict processing has nothing to do with it, so this change does no actual harm. * There is no attempt to protect against the same transaction being continually replaced with the fee bumped by a minimal amount. What exact git commit were you looking at? I did have an early one that did have a bug along those lines, now fixed. The current version ensures every replacement pays at least as much additional fees as would normally cost to broadcast that much data on the network, and additionally requires the fees/KB to always increase; under all circumstances it should be no more of a DoS threat than low-fee transactions are otherwise. I'd like to know if there is a flaw in that code however! -- 'peter'[:-1]@petertodd.org 17c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik jgar...@bitpay.com wrote: scorched earth refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. I think you guys are reading too much into the name... Replace-by-fee is called replace-by-fee because it considers whether to replace or not based on fee; the idea came about in an discussion about replacement based on nSequence. I forget whether it was myself or John Dillon who came up with the name scorched earth, but it just refers to the game theory behind the *specific* idea of the receiver combating a zeroconf double-spend by sending all the funds to fees. Scorched earth as in You're trying to defraud me, so I'm not going yo play this game or negotiate, I'm just going to immediately do what is most likely to make you lose the maximum amount of money to punish you for your vandalism. All payment processors AFAIK process transactions through some scoring system, then accept 0-conf transactions for payments. This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth I'm not so convinced, precisely because we've seen zeroconf fail in pretty bad ways; the people most vulnerable to losses have generally changed the way they operate. (e.g. ATM's that no longer rely on zeroconf security, instead waiting for confirmations, installing cameras, etc.) My #1 concern right now is person-to-person trading, and people doing that tend to wait for confirmations or otherwise protect themselves. (e.g. reputation systems) Without adequate decentralized solutions for instant payments, deploying replace-by-fee widely would simply push instant transactions even more into the realm of centralized, walled-garden services. Agreed. Deploying it has been something I've made into a long, drawn out, protracted process for precisely that reason. OTOH I sometimes wonder if I've gone too far with that - the services that themselves try to guarantee zeroconf right now through metrics are themselves highly centralised, and there's a big risk of them driving mining centralisation itself when they fail. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6S2N AAoJEMCF8hzn9LncrFUH/1xhuPhYJnjTCxhpv2h5ZJOT3wLsrU1oEDmD5fWy/4wG 7ppr3EiHNX7nB42fgeSGZF8fW1VuBjivJa9ra3IvFysFfaD40Kyre2FTnN03+vTC Upa5ykPzOMqZIHkSf8N1xMbz4SXHHPWu8wPMzj/QGvUpllNiOWn/6Vooqrcp7f6Y NJFykSq+vDNMOUWCiJG8hhoKiOcZhTH0Aj9qPcGs9WhgsF7wDAX7pg6iO6Y5qmt5 LdFcut2caL6mIxpExm0F9V+lyeam/3gvAU3eecHY77KOxRxFTO1xfQXEJFTWN92h +M9BXQZ1UifjTZWMzK0kp3SRJuVSXg4KOAapQFBLTzU= =3Mmw -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 11:04:49AM -0800, Adam Back wrote: Strongly with Peter on this. That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments; it tells you that the risk is exponentially worse and people should use and rally around libconsensus. It's worth remembering that one of the goals in writing - or to be more precise, separating - libconsensus from the Bitcoin Core codebase is to make it easier to maintain strict consensus between Bitcoin Core versions. I would advise any bitcoin ecosystem part, wallet, user to not use software with consensus protocol rw-writes nor variants, you WILL lose money. You could view bitcoin as a digital signature algorithm speculatively tinkering with the algo is highly prone to binary failure mode and unbounded funds loss. Want to be clear this is not a political nor emotive issue. It is a critical technical requirement for security if users of software people write. The necessity of it isn't a political or emotive issue, but the consequences are definitely political. Just not in the way that most of the ecosystem appears to think. -- 'peter'[:-1]@petertodd.org 16b6444e463c7d92da1579360c5f71d4fbd3dab45d13990a signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote: Yes you are dicking around. I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface. Ah, sorry, that wasn't clear to me. The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging and now comes handy to create a side chain. Indeed, which is why I've done a lot of work on a reimplementation of the Bitcoin scripting system as well: https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/scripteval.py Which has this cheery warning at the top: Script evaluation Be warned that there are highly likely to be consensus bugs in this code; it is unlikely to match Satoshi Bitcoin exactly. Think carefully before using this module. I'll be adding a FFI interface to libconsensus in the future... and I probably should make that warning scarier... -- 'peter'[:-1]@petertodd.org 00ffb7a576b7aa5236c53f51ec07ccf174067beed3398056 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote: Peter, You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server. Wallet and RPC server are definitely not consensus critical code. P2P service rules are weakly consensus critical, in that a failure to relay valid blocks can in practice cause a loss of consensus. But relaying valid blocks is very easy, and you only need sone relay mechanism out of many to work for consensus to be maintained. OpenSSL is getting replaced by libsecp256k1, a library designed for consensus-critical applications. As for databases, look at the good #bitcoin-wizards discussion yesterday for strategies to make databases less relevant to consensus. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity that the ecosystem takes for granted and free. Are you referring to feature extensions to consensus critical code - like my own CHECKLOCKTIMEVERIFY? - or extensions to code that isn't consensus critical? I honestly admire the core team that works and progresses within these limits and perception. I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not. It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way. Yes you are dicking around. The effort you're going to spend recreating the core consensus code and getting it right is orders of magnitude more work than figuring out how to use the foreign function interface in your chosen language, or at worse, just running Bitcoin Core to do validation and using RPC or the p2p protocol locally to track that state. Don't assume your prior experience with other commercial projects has any bearing on Bitcoin: consensus-critical crypto is a brand new field within software engineering with very unique requirements, pioneered by Bitcoin itself. -- 'peter'[:-1]@petertodd.org 0a37c901cf2ae6c281f47b237e9bf1d7268fb561b4332345 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
I haven't bothered reading the thread, but I'll put this out there: The consensus critical Satoshi-derived sourcecode is a protocol *specification* that happens to also be machine readable and executable. Rewriting it is just as silly as as taking RFC 791 and rewriting it because you wanted to decentralize control over the internet My replace-by-fee fork of Bitcoin Core is a perfect case in point: it implements different non-consensus-critical policy than Bitcoin Core does, while adhering to the same Bitcoin protocol by virtue of being the same sourcecode - the same protocol specification. When I went to miners asking them to implement it, the biggest concern for them is Will it stay in consensus with other miners? If I had rewritten the whole thing from scratch the fact is the honest answer to them would be no way in hell - reimplementing Bitcoin and getting it right is software engineering's Apollo Project and none of us have the resources to pull that off. But I didn't, which means we might soon have a significant chunk of hashing power implementing a completely different mining policy than what is promoted by the Bitcoin Core maintainers. By reimplementing consensus code - rewriting the protocol spec - you drop out of the political process that is Bitcoin development. You're not decentralizing Bitcoin at all - you're contributing to its centralization by not participating, leaving behind a smaller and more centralized development process. Fact is, what you've implemented in libbitcoin just isn't the Bitcoin protocol and isn't going to get adopted by miners nor used by serious merchants and exchanges - the sources of real political power. Right now we could live in a world where a dozen different groups maintain Bitcoin implementations that are actually used by miners. We could have genuine innovation on the p2p networking layer, encryption, better privacy for SPV clients, better resistance to DoS attacks. We could have diverse tx acceptance policies rather than wasting hundreds of man hours bitching about how many bytes OP_RETURN should allow. We could have voices from multiple groups at the table when the community discusses how to scale Bitcoin up. Instead we have a world with a half dozen teams wasting hundreds if not thousands of of man hours dicking around trying to rewrite consensus critical *specifications* because they happen to be perfectly good executable code, and the first thing a programmer thinks when they see perfectly good battle-hardened code is Hey! Let's rewrite that from scratch! You know you does have significant political power over the development of the Bitcoin protocol *other* than the Bitcoin Foundation? Luke Dashjr. Because he maintains the Eligius fork of Bitcoin Core that something like %30 of the hashing power run. It Actually Works because it uses the Actual Protocol Specification, and miners know if they run it they aren't going to lose tens of thousands of dollars. It's why it's easy to get transactiosn mined that don't meet the Bitcoin Core's IsStandard() rules: they aren't part of the protocol spec, and Luke-Jr has different views on what transactions should and should not be allowed into the blockchain. And when Gavin Andresen starts negotiating with alt-implementations to get his bloat coin proposals implemented, you know who's going to be at the table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi, etc. will get invited, but no-one's going to really care what they say. Because at best only a tiny - and foolish - sliver of hashing power will be using their implementations of Something Almost But Not Quite Bitcoin™, and any sane merchant or exchange will be running at least one or two Bitcoin Foundation Genuine Bitcoin Core™ nodes in front of any from-scratch alt-implementation. So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, wrap it in the mempool policy, p2p networking code, and whatever else you feel like, and convince some hashing power to adopt it. Then enjoy the fruits of your efforts when the next time we decide to soft-fork Bitcoin the process isn't some secretive IRC discussion by a half-dozen core developers - and one guy who finds the term hilarious - but a full on DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW, complete with twinkle fingers. A pow-wow that you'll be an equal part of, and your opinions will matter. Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. The choice is yours. On Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote: On 02/14/2015 01:51 AM, Jorge Timón wrote: I agree that this conversation is not being productive anymore. I'm doing my best to understand you but I just happen to disagree with many of your arguments. I doubt it makes you feel better but it's being tedious and frustrating for me as
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 08:15:01PM +0100, Alan Reiner wrote: The Bitcoin network achieves something that we didnt' think was possible 10 years ago: a totally trustless, decentralized ledger. The cost? It takes time for the decentralized network to reach consensus that transactions happened. That is quite literally the trade-off that we make: you can centralize things by putting a bank in the middle and getting instant confirmation, or you decentralize and let the network reach consensus over time without the central authority. If you want instant confirmations, you're going to need to add centralization because Bitcoin never offered it. I support efforts to dispel any such myths as soon as possible and encourage building robust solutions (payment channels, insured zero-conf services, etc.). Speaking of, a relatively simple thing that would help dispel these notions would be if some wallets supported replace-by-fee-using fee-bumping and an attempt undo button. Armory is an (unfortunately!) special case because it uses a full node and has good privacy guarantees, but most wallets could implement this by just sending the doublespend transactions to any node advertising either the replace-by-fee or GETUTXO's service bits. 1) https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html -- 'peter'[:-1]@petertodd.org 0a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 07:49:29PM +, Gregory Maxwell wrote: One challenge is that without rather smart child-pays-for-parent logic the positive argument for replace by fee doesn't really work. That's actually incorrect now, as a mechanism for implementing scorched-earth without child-pays-for-parent using SIGHASH_ANYONECANPAY is available: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html I greatly prefer this mechanism as it's an opt-in mechanism - many wallets double-spend on occasion by accident - and can have the incentives be adjusted to suit the % of hashing power that actual supports replace-by-fee. (and the % probability you'll see the doublespend) My patch implements 90% of the logic required for the above to work, however I've intentionally limited the total depth of recursion when the replacement is being evaluated as an interm anti-DoS measure in the spirit of belt-and-suspenders engineering. This can certainly be improved on, e.g. by limiting total mempool size. -- 'peter'[:-1]@petertodd.org 0a16bcc766361414571a5f961698acc46c27bd79c26ac15c signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 07:34:22PM +, Justus Ranvier wrote: In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? None of those solutions are compatible with decentralized networks for a lot of reasons. Given the inability to prevent sybil attacks your suggestions lead to people being unfairly punished for poor connectivity that may be entirely out of their control. They also make maintaining a Bitcoin node and mining the blockchain require a significant amount of hands on maintenance, again incompatible with a decentralized system. -- 'peter'[:-1]@petertodd.org 0a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . Wait, what the heck do you mean by only if it is actually replacing an earlier? How does my replace-by-fee patch *not* do that? -- 'peter'[:-1]@petertodd.org 12613986506ef6592952234a6a04946ef946ff0836405ad4 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote: Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? It might be enough to rewrite this BIP to basically say all pubkeys executed by all CHECKMULTISIG opcodes will be in the following canonical order, followed by some explanatory examples of how to apply this simple rule. OTOH we don't yet have a standard way of even talking about arbitrary scripts, so it may very well turn out to be the case that the above rule is too restrictive in many cases - I certainly would not want to do a soft-fork to enforce this, or even make it an IsStandard() rule. -- 'peter'[:-1]@petertodd.org 13cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] replace-by-fee v0.10.0rc4
My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 Along with demo scripts of the functionality: https://github.com/petertodd/replace-by-fee-tools New to this version is a comprehensive set of unittests under qa/replace-by-fee Additionally the preferential peering support now preferentially peers with Bitcoin XT¹ nodes that support Andresen/Harding's double-spend relaying² patch. While Bitcoin XT nodes don't accept double-spends into their mempool, they do relay them perfectly well and thus are an asset to those doing replace-by-fee mining.³ I've had a number of requests from miners for a version of replace-by-fee against Luke-Jr's Eligius patches⁴; I'll be also releasing that shortly once this release has undergone some more testing. What's replace-by-fee? -- Currently most Bitcoin nodes accept the first transaction they see spending an output to the mempool; all later transactions are rejected. Replace-by-fee changes this behavior to accept the transaction paying the highest fee, both absolutely, and in terms of fee-per-KB. Replaced children are also considered - a chain of transactions is only replaced if the replacement has a higher fee than the sum of all replaced transactions. Doing this aligns standard node behavior with miner incentives: earn the most amount of money per block. It also makes for a more efficient transaction fee marketplace, as transactions that are stuck due to bad fee estimates can be unstuck by double-spending them with higher paying versions of themselves. With scorched-earth techniques⁵ it gives a path to making zeroconf transactions economically secure by relying on economic incentives, rather than honesty and alturism, in the same way Bitcoin mining itself relies on incentives rather than honesty and alturism. Finally for miners adopting replace-by-fee avoids the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior, as seen in Harding's proposal⁶ that miners collectively 51% attack miners who include doublespends in their blocks - an unavoidable consequence of imperfect p2p networking in a decentralized system - or even Hearn's proposal⁷ that a majority of miners be able to vote to confiscate the earnings of the minority and redistribute them at will. Installation Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run your node normally. With -debug logging enabled, you'll see messages like the following in your ~/.bitcoin/debug.log indicating your node is replacing transactions with higher-fee paying double-spends: 2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes Additionally you can tell if you are connected to other replace-by-fee nodes, or Bitcoin XT nodes, by examining the service bits advertised by your peers: $ bitcoin-cli getpeerinfo | grep services | egrep '((0003)|(0401))' services : 0003, services : 0401, services : 0401, services : 0003, services : 0401, services : 0401, services : 0003, services : 0003, Replace-by-fee nodes advertise service bit 26 from the experimental use range; Bitcoin XT nodes advertise service bit 1 for their getutxos support. The code sets aside a certain number of outgoing and incoming slots just for double-spend relaying nodes, so as long as everything is working you're node should be connected to like-minded nodes a within 30 minutes or so of starting up. If you *don't* want to advertise the fact that you are running a replace-by-fee node, just checkout a slightly earlier commit in git; the actual mempool changes are separate from the preferential peering commits. You can then connect directly to a replace-by-fee node using the -addnode command line flag. 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/bitcoin/bitcoin/pull/3883 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html -- 'peter'[:-1]@petertodd.org 13c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote: Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Absolutely nothing in the replace-by-fee patch is consensus critical; your objection is entirely an artifact of the poor modularity of the Bitcoin Core codebase, something that is being actively improved on as we speak. Anyway, the logic of dealing with double-spends and keeping mempools synced is pretty trivial: for i in range(len(tx.vout)): for double_spent_tx in mempool.mapNextTx[COutPoint(tx.GetHash(), i)]: mempool.remove(double_spent_tx, recursive=True) mempool.add(tx) IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. All the complexity of replace-by-fee is in deciding when one transaction should replace another(s). Other than that the code is simple and very similar to block handling logic. -- 'peter'[:-1]@petertodd.org 0948f5c1f1a8c8073cc7d5161b98474e33904f8a1d6b0330 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update to Double-Spend Deprecation Window Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is an incredibly dangerous and foolish proposal that opens up the Bitcoin network to serious vulnerabilities, both from attackers outside the network, as well as miners trying to gain an advantage over their competition. Ultimately it's flawed for the same root problem that proof-of-stake proposals suffer from: the p2p network just isn't a reliable broadcast medium. Seeing a transaction is not a guarantee that any other node has seen it; not seeing a transaction is not a guarantee other nodes have not seen a spend. You can measure propagation times and other metrics all you want, but you're measuring a network that isn't under attack; Bitcoin must be robust against attacks, and it must not create incentives to launch them. Institutionalising the punishment of miners being they did not have perfect connectivity - an unattainable goal in a trust less, decentralised system - is athema to the goals of having a decentralised systmem and will only lead to smaller mining operations being punished for being the victim of attacks on their network connectivity that are only made profitable by this proposal. Equally your proposal actually makes it *easier* to pull off apparently single-confirm double-spend attacks - any miner who ignores a block containing the apparent double-spend is just as likely to be aiding an attacker trying to get a 1-conf transaction double-spent. This forces *everyone* to waiting *longer* before accepting a transaction because now even a single-confirmation is no longer good evidence of an accepted transaction. In an ecosystem where hardly anyone relies on zeroconf anyway your putting a much larger group of people at risk who weren't at risk before. Frankly if this idea gets traction it should serve as a warning to all miners that it's time they adopt replace-by-fee to set a clear precedent that they have no obligations other than the same economic self-interest- not vague notions of honesty - that makes Bitcoin work in the first place. BTW you quote Hal Finney and Satoshi in your proposal to try to lend support to it. Don't do that - appealing to authority is a surefire way to get people to ignore you. Its particularly bad when the authorities being appealed too haven't participated in consensus research for years; you're referencing stuff from a time when Bitcoin was barely understood. On 8 February 2015 21:38:55 GMT-06:00, Tom Harding t...@thinlink.com wrote: This update strengthens the incentive not to confirm double-spends after time T (30 seconds). To grow and stabilize adoption, it is necessary to influence the miner of the block after a deprecated block, who in turn is concerned with the block after that. Accordingly, the disincentive is changed from a simple delay to a temporary chain work penalty, which can be negative. Hal Finney first suggested this in 2011. The penalty is graduated in two steps based on the respend gap, for reasons explained within. I believe it is the minimum required to achieve the intended result. Double-Spend Deprecation Window https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJU2FR4MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTd/B/9CG8fiJIZWnyxTsvnK InGRfFMef8yvbALEt4/Io75Iv6Y6xYw0TbkLdk8r38/iFD5RlE6edYQe90QKA903 D6nxKQU0b1vW53cTptetzpvR6utkFogw3nqPRAy5SrDAdjJrg2Z78QrUQv+pSeYs U9Mlw/22Z34vRI4VHpY9jeEtyj2lKNZvlBj/BtOeSHYsXB3R4tVmtp4DRiXc5FVr i9NcOSBqKSzvG5bgx1S6QmMakSD/9LaoBrBWFiU2FZV/jX9x+dR31OdrVWr06OJU zlR2Xyn3P+KwG8IeJR0K3sk72/vvEN+pntG+SMhtfrwjCgDKYGvULbcELR41EcmA /X0i =hGv0 -END PGP SIGNATURE- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] determining change addresses using the least significant digits
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Any thoughts? Have you looked at Armory? IIRC they do this kind of stuff. -- 'peter'[:-1]@petertodd.org 165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote: Hi there, comments in-line: I later wrote up the idea in the context of adding Zerocoin to Bitcoin: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html For the sake of maximum clarity with respect to modelling the value of a Bitcoin, I don't think that approaches which change the number of coins that can possibly be circulated should be encouraged. So, I like the idea of having the sacrificed coins appearing in the mining fees in a future block. But what is meant with OP_DEPTH in this context? From what I read, this operation just manipulates the stack size when evaluating the script, so I don't see how it would affect miner incentives. Oh, where I was saying OP_DEPTH, I was referring to a *hypothetical* opcode; I'd forgotten when I wrote that post that OP_DEPTH is an real opcode. These days I'd suggest you use the (upcoming on BTC/live on Viacoin) OP_CHECKLOCKTIMEVERIFY opcode instead. Pretty simple really: current blockheight + 1 year worth of blocks CHECKLOCKTIMEVERIFY -- 'peter'[:-1]@petertodd.org 165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 January 2015 08:35:23 GMT-08:00, slush sl...@centrum.cz wrote: Oh, now I got the 'soft-fork' alternative. If that means that *senders* to Trezor need to be nice guys and use some special outputs, then it's, obviously, no-go solution. That's what P2SH is for; the senders will just be sending to a P2SH address. I understand political aspect around hard-fork. Anyway, are there any other pending projects waiting for hard-fork? Hard-forks aren't hard for directly political issues, they're politically hard because they're risky by requiring everyone yo upgrade at once. In the case of signature validation, that touches a *lot* of third party code that people rely on to avoid being defrauded. FWIW I've actually got a half-finished writeup for how to use OP_CODESEPARATOR and a CHECKSIG2 soft-fork to have signatures sign fees and so forth. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUwonGMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhbwkCADP7AcJ6a6V/y7MHt2x ZiCXYsfHq5j03kbSWXGi1Q/9RqWGVha1fhWPp62yhDxbWOfh5QKauCbrt2g1AqT3 xbnh+2XE1rApBQIiJ6u0wZmpCi+4EhH2M9R8UYu9oIMzBe4K2jhzUbzcOR9Qplyq 9j6yevNrvtNHZb2OTiaKelxnuZUEiAsONHPOvR8Fkflwbd/w279OeilRjHYt3A/J U22KOwjNrpa7/QE/HeC0QINqr3S132Yg4iYFwPviBwGq/WXQuLHIzGtgKOzrIC1T h6kpWO9CjSxVbjMrf68IrSHRv92K8y1LiHFRZvzp3ulzcGBo2btazmrp/fUDLCr0 6uFg =uDeM -END PGP SIGNATURE- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships
On Tue, Jan 20, 2015 at 08:43:57AM -0800, Daniel Stadulis wrote: Hey Peter, What would you say to the argument: given developers have auto update capabilities they only have the ability to *give themselves* *the ability* to have custodial rights? Heh, well, courts tend not to have the narrow-minded pedantic logic that programmers do; quite likely that they'd see having the ability to give themselves the ability as equivalent to simply having the ability. What matters more is intent: the authors of an operating system had no intent to have a custodial relationship over anyones' BTC, so they'd be off the hook. The authors of a Bitcoin wallet on the other hand, depends on how you go about it. For instance Lighthouse has something called UpdateFX, which allows for multi-signature updates. It also supports deterministic builds, and allows users to chose whether or not they'll follow new updates automatically, or only update on demand. In a court that could be all brought up as examples of intent *not* to have a custodial relationship, which may be enough to sway judge/jury, and certainly will help avoid ending up in court in the first place by virtue of the fact that all those protections help avoid theft, and increase the # of people that an authority need to involve to seize funds via an update. -- 'peter'[:-1]@petertodd.org 1a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c signature.asc Description: Digital signature -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
