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] 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: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 08:20:52AM -0700, Adrian Macneil wrote: > > > > Unless you're sybil attacking the network and miners, consuming valuable > > resources and creating systemic risks of failure like we saw with > > Chainalysis, I don't see how you're getting "very small" double-spend > > probabilities. > > > > So connecting to many nodes just because we can and it's not technically > prevented is bad for the network and creating systemic risks of failure, 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. 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? > but relaying harmful double spend transactions just because you can and > it's not technically prevented, is good for everyone? You realise that Hearn/Andresen/Harding's double-spend-relaying patch, included in Bitcoin XT, relays double-spend transactions right? Do you consider that harmful? > > You know, you're creating an interesting bit of game theory here: if I'm > > a miner who doesn't already have a mining contract, why not implement > > full-RBF to force Coinbase to offer me one? One reason might be because > > other miners with such a contract - a majority - are going to be asked > > by Coinbase to reorg you out of the blockchain, but then we have a > > situation where a single entity has control of the blockchain. > > > > If someone did enter into contracts with miners to mine certain > transactions, and had a guarantee that the miners would not build on > previous blocks which included double spends, then they would only need > contracts with 51% of the network anyway. So it wouldn't really matter if > you were a small time miner and wanted to run full-RBF. But of course, you'd never 51% the network right? After all it's not possible to guarantee that your miner won't mine double-spends, as there is no single consensus definition of which transaction came first, nor can there be. Or do you see things differently? If I'm a small miner should I be worried my blocks might be rejected by the majority with hashing power contracts because I'm unable to predict which transactions Coinbase believes should go in the blockchain? > > For the good of Bitcoin, and your own company, you'd do well to firmly > > state that under no condition will Coinbase ever enter into mining > > contracts. > > > > I don't personally see what good this does for bitcoin. Now you are > suggesting that we should prevent a 51% attack by using policy and > promises, rather than a technical solution. How is this any better than us > relying on existing double spend rules which are based on policy and > promises? Well, I think I've shown how dangerous mining contracts can be to the overall health of the Bitcoin ecosystem; I'm simply asking you to promise not to make use of this dangerous option regardless of what happens. Like I said, if for whatever reason the first-seen mempool behavior proves to be insufficient at preventing double-spends from your perspective, you did suggest you might use mining contracts to ensure txs you want mined get mined, over others. 1) "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/ -- 'peter'[:-1]@petertodd.org 0e806870e7e9cf4d507af6b78fc709e6839a8d34b52ea334 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 07:00:56AM -0700, Adrian Macneil wrote: > > > > For instance, if Coinbase had > > contracts with 80% of the Bitcoin hashing power to guarantee their > > transactions would get mined, but 20% of the hashing power didn't sign > > up, then the only way to guarantee their transactions could be for the > > 80% to not build on blocks containing doublespends by the 20%. > > > > This seems to be more of a problem with centralized mining than zeroconf > transactions. You're mistaking cause and effect: the contracts will drive centralization of mining, as only the larger, non-anonymous, players have the ability to enter into such contracts. > Speaking of, could we get a confirmation that Coinbase is, or is not, > > one of the merchant service providers trying to get hashing power > > contracts with mining pools for guaranteed transaction acceptance? IIRC > > you are still an advisor to them. This is a serious concern for the > > reasons I outlined in my post. > > > > We have no contracts in place or plans to do this that I am aware of. > > However, we do rely pretty heavily on zeroconf transactions for merchant > processing, so if any significant portion of the mining pools started > running your unsafe RBF patch, then we would probably need to look into > this as a way to prevent fraud. What happens if the mining pools who are mining double-spends aren't doing it delibrately? Sybil attacking pools appears to have been done before to get double-spends though, equally there are many other changes the reduce the reliability of transaction confirmations. For instance the higher demands on bandwidth of a higher blocksize will inevitably reduce the syncronicity of mempools, resulting in double-spend opportunities. Similarly many proposals to limit mempool size allow zeroconf double-spends. In that case would you enter into such contracts? -- 'peter'[:-1]@petertodd.org 05a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
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: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: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 decentr
[Bitcoin-development] F2Pool has enabled full replace-by-fee
-fee-tools You can watch double-spends on the network here: http://respends.thinlink.com/ References -- 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT 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] questions about bitcoin-XT code fork & non-consensus hard-fork
On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote: > > 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. > > > > Thank you very much Peter for pointing this out! That is very kind of you. > > It would be great to work with Constance Choi, Primavera De Filippi, your > goodself and others to make this happen. Great! They're excited to see this happen. I'm in London right now actually for the conference they were holding this week; the blocksize issue was being discussed a fair bit there among attendees. (notably, with rather different views than seen on reddit!) > As you may know, the Hong Kong Monetary Authority considers bitcoin a > virtual 'commodity' and not a currency per se. Yup, though keep in mind the regulatory question is more than just how your local jurisdiction views Bitcoin, but rather how your customers' jurisdictions view Bitcoin. Of course, when I say "customers" above, I mean the entire Bitcoin community that is ultimately buying the new coins produced by miners and paying fees to them! -- '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] questions about bitcoin-XT code fork & non-consensus hard-fork
On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote: > Thanks Alex, the work you've pointed out is helpful. Limiting mempool size > should at least prevent nodes from crashing. When I looked a few days ago I > only found a few old PRs that seemed to have fallen by the wayside, so this > new one is encouraging. BTW it's worth working out how many $ in fees you need for a given amount of MB worth of mempool. At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5 worth of fees - kinda ridiculous when a block earns a miner $6250 in revenue. Pretty much all txs pay significantly higher rates - more like 100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to fill to pay the fees, and in practice will probably quickly get higher. https://github.com/bitcoin/bitcoin/pull/6281 > I can respond in the PR comments if it's more appropriate there, but I > believe ejecting tx from mempools rather than preemptively refusing them > according to standard network wide propagation rules will result in spotty, > inconsistent tx propagation, and possibly a large increase in tx > re-broadcasts, so if those haven't been addressed they will need to be. It > would also be prudent to run some simulations to see what other issues are > going to pop-up. See above - filling the mempool like that will be both a slow process, and require lots of funds. Equally, once full, the sensible thing to do is raise the minimum relay fee appropriately, so those transactions that pay too low a fee will simply be rejected. It'd be reasonable to tell peers that, and what the minimum fee needed for acceptance would be for that particular node. > We're currently using CPFP already in breadwallet when spending unconfirmed > non-change inputs. A small percentage of hashing power is using it, but > enough to get a transaction unstuck assuming breadwallet's fee calculation > is better than the sender's. > The problem with RBF is that there's currently no way to tell if your tx > has been picked up by miners or not in order to know if you need to replace > it. Miners broadcasting partial block solutions would be helpful in this > regard, but only for tx in the currently-being-worked-on block, not for tx > that won't be picked up until the block after. If miners were to eject tx > that were previously being worked on in favor of higher fee tx, then that > causes another set of problems for wallets that thought their tx was going > to get in but then it doesn't. The other problem with RBF is that users > don't know up front what fee they're actually going to pay which is a big > blow to real world usability. Also mobile wallets will have to sign lots of > tx up front and rely on a service to replace as necessary. And this is all > just on the send side. For an interactive, mobile wallet, the best thing to do is estimate the fee correctly the first time, using RBF as a follow up mechanism only if needed. For other users - e.g. exchanges handling customer withdrawals - using RBF more agressively to get the minimum possible fee may make sense. > On the receive side it's much worse since you can't > rely on the sender to do the replacing. The real problem seems to be the > fact that RBF is an interactive iterative process rather than a > send-and-forget one. In any case, the *existance* of RBF makes no difference to any of these problems; RBF does make solving the easier. You can always choose to not use it after all, resulting in the same "send-and-forget" process. Having it available allows mistakes to be fixed after the fact, always an improved user experience over not being able to re-bid for block space. Incidentally, if my FSS-RBF bug bounty isn't collected in the next week or two, we'll likely have a major double-digits % of hashing power mining FSS-RBF soon after. http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html > What you really need is some way to tell up-front, is a transaction going > to get mined with a high probability? That problem seems really difficult > to solve with fixed-size blocks that are full. Have you looked at the fee estimation code in Bitcoin Core? I have no reason to think it doesn't basically speaking work. Of course, SPV wallets will need a semi-trusted third party to securely get that data, but this seems to be a fundemental problem in a decentralized network - the purpose of the blockchain itself is to prove that some data was published to some audience, an analogous problem to proving to the SPV wallet that their transaction actually reached miners and they actually are considering it for inclusion. Guaranteed reliable transaction processing is only possible in centralized environments that can make service guarantees. > If the goal is simply to > reduce or limit the growth of the blockchain, then there are much simpler > solutions, which is why I've advocated for
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 > 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] 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] 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 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] comments on BIP 100
On Mon, Jun 15, 2015 at 12:23:44AM +0200, Mike Hearn wrote: > > > > One thing that is concerning is that few in industry seem inclined to > > take any development initiatives or even integrate a library. > > > Um, you mean except all the people who have built more scalable wallets > over the past few years, which is the only reason anyone can even use > Bitcoin from their phone? > > Or maybe you mean initiatives like Lightning > except StrawPay already developed something similar to the Lightning > network (complete with a working GUI wallet) and were ignored by > Blockstream as you prefer to write your own from scratch? > > Sure, people in the industry take development initiatives. That doesn't > mean their work will be recognised on this mailing list. StrawPay hasn't published any details of their work publicly; if they wanted credit on the mailing list they should have done that. I couldn't even find any screenshots of that GUI wallet when I learned what they were doing; I went to the trouble of reaching out to them recently because I have multiple clients with a need for their technology. I'm sure we all would have appreciated and welcomed them taking the time to let us know what they were doing; it would have saved me personally a lot of time; their lack of recognition on this mailing list is both unfortunate, and a product of their actions alone. In any case, StrawPay and Lightning are complementary projects: StrawPay has limited functionality in exchange for faster deployment; Lightning has significantly more functionality in exchange for a longer deployment schedule. Both projects can and should be developed in parallel. Equally, note efforts like my own CHECKLOCKTIMEVERIFY, which will be part of StrawPay in due time. > > But it will be helpful if we expose companies to the back-pressure > > actually implied by an O(n^2) scaling protocol and don't just immediately > > increase the block-size to levels that are dangerous for decentralisation > > security > > > Bitcoin does not have n-squared scaling. I really don't get where this idea > comes from. Computational complexity for the entire network is O(nm) where > n=transactions and m=fully validating nodes. There is no fixed > relationships between those two variables. Note for instance how we're discussing what standards we need in the CryptoCurrency Security Standard for requirements for compliant companies to run full nodes for transaction verification; failure to run a full node will be considered non-compliant in much the same way that failure to secure your private keys is non-compliance. Pedantically, if you assume a diverse, decentralized ecosystem, these security standards by themselves do create fixed linear relationships between those variables, giving O(n^2) scaling. https://github.com/CryptoConsortium/CCSS/issues/15 > "Exposing the companies to back-pressure" sounds quite nice and gentle. Let > me rephrase it to be equivalent but perhaps more direct: you mean "breaking > the current software ecosystem to force people into a new, fictional system > that bears little resemblance to the Bitcoin we use today, whether they > want that or not". Equally, not running full nodes bears little resemblance to the Bitcoin we use today. Either way, something must change for the number of Bitcoin users to grow. > As nothing that has been proposed so far (Lightning, merge mined chains, > extension blocks etc) has much chance of actual deployment any time soon, > that leaves raising the block size limit as the only possible path left. > Which is why there will soon be a fork that does it. I'm genuinely looking forward to a concrete fork proposal. Any ETA on when the blocksize increase code will go in Bitcoin XT? -- '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] comments on BIP 100
On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote: > I think the whole complexity talk is missing the bigger issue. > > Sure, per block validation scales linearly (or quasilinearly…there’s an O(log > n) term in there somewhere but it’s probably dominated by linear factors at > current levels…asymptotic limits don’t always apply very well to finite > systems). And there’s an O(n^2) bandwidth issue. > > The real issue, though, is validation cost. The n in O(n) here does not > represent block size - it represents the size of the entire block chain for > every new validator that must be synchronized! It means we have no way to > construct short proofs (or at least arguments that are computationally *hard* > to forge) without requiring the validator to maintain the complete system > state. And currently, there is no mechanism for directly compensating > validators. ...and can there be? The goal of validation after all is finding if a mistake has been made, and current production cryptography doesn't have any way to prove you have done that honestly. You need "moon math" like recursive SNARKS to do that, and it's unknown when they'll be available for production usage. When we say "compensating validators", if we're being honest with outselves what we really mean is the much more boring task of compensating servers who are giving us blockchain data. That has nothing to do with validation. A useful task would be to make an SPV archival node implementation that did no validation at all, while distributing the blockchain data linked to the longest chain. Such an implementation can and should serve SPV clients, as this is what their actual security model usually is given the lack of authentication of the identity of the server they're connecting too. Actually implementing this would be a simple matter of patching Bitcoin Core to turn off block validation. > A full validator that goes offline even for a short period of time takes a > while to fully catch up to the rest of the network - and starting up a new > validator from scratch will continue to be painful…even for those of us > who’ve turned this into routine by now, let alone new nontechnical users. Concretely, 20MB blocks lead to 20GB/week of blocks. On my 1MB/second down internet, turning on my node after a week away would take five hours; starting up a new node after two years of 20MB blocks would take 23 days - likely longer in practice. There's serious unsolved and undiscussed devops and development issues with this. For instance, after changes to the validation code, it's routine to resync/reindex Bitcoin Core to ensure starting up a new node actually works. Even now we haven't really come to grips with what consistent 1MB blocks looks like from this point of view after a few years of usage, let another order of magnitude longer sync times. > Satoshi’s SPV is not a real solution - it’s a mere suggestion that wasn’t > fully thought out at the time of the Bitcoin white paper. Besides lacking a > good validation security model, practical implementations of it weaken > privacy and complicate client implementations substantially…and the worst > part, it still doesn’t scale all that well. The validator still has to query > every single block (even if filtered) back to the first transaction (which > cannot be determined without doing a blockchain scan anyway). Note how with 20MB blocks it would take up to 1TB of IO per year-synced for a bloom-filter-using wallet to sync the blockchain. We already have a bloom IO DoS attack issue - what are the consequences of making that issue 20x worse? Nobody has analysed it yet. -- '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] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
On Sun, Jun 14, 2015 at 11:15:18AM -0400, Jeff Garzik wrote: > * ACK on moving away from SourceForge mailing lists - though only once a > community-welcomed replacement is up and running > > * ACK on using LF as a mailing infrastructure provider > > * Research secure mailing list models, for bitcoin-security. The list is > not ultra high security - we all use PGP for that - but it would perhaps be > nice to find some spiffy cryptosystem where mailing list participants > individually hold keys & therefore access. ACK to the above as well. -- '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 08:39:21PM +0200, Benjamin wrote: > This is a misguided idea, to say the least. If such a mechanism of of > user input would be possible, one would use it for transaction > verification in the first place. In proof-of-stake outcomes are > determined by vote by stake (that vote has very different > characteristics than vote by compute power). There is no such thing as > making it possible to determine what "users want". That's what the > proof-of-work mechanism does in the first place, only that it is now > unfortunately skewed/corrupted/(whatever you want to call it). Before > centralization the concept of "miners" didn't exist in Bitcoin and > miners were roughly identical to users. Peer-to-Peer implies only one > class of users. > > A big problem with such a vote (in PoW and PoS): miners get paid for > their work and have incentives to raise fees. Those who pay fees would > have no say in whether those fees are fair or not. Transaction > verification has to be roughly profitable, but there is no fixed > formula for determining profitability. Read John Dillon's proposal then, which via proof-of-stake explicitly approportions control of increases via % of Bitcoin owned. Anyway, representing everyone is never going to be easy, but at least this nVersion thing is very easy to implement. -- '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:36:31PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > 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.
>
> I hope you mean the *plurality* of the three options after throwing away the
> "don't cares," not the *median*.
Median ensures that voting "no change" is meaningful. If "double" + "no
change" = 66%-1, you'd expect the result to be "no change", not "halve""
With a plurality vote you'd end up with a halving that was supported by
a minority.
--
'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] 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] 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] User vote in blocksize through fees
Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a "soft" limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a "don't care" vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.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
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
[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
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote: > The other complication is that this will tend to be a lagging indicator > based on network congestion from the last time you connected. If we assume > that transactions are being dropped in an unpredictable way when blocks are > full, knowing the network congestion *right now* is critical, and even then > you just have to hope that someone who wants that space more than you do > doesn't show up after you disconnect. Hence the need for ways to increase fees on transactions after initial broadcast like replace-by-fee and child-pays-for-parent. Re: "dropped in an unpredictable way" - transactions would be dropped lowest fee/KB first, a completely predictable way. -- 'peter'[:-1]@petertodd.org 124bae79afdcee9267b4e6f8137758b8b4135455cd8e3bfd 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 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] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 03:36:42PM -0400, Andy Schroder wrote: > It's possible that the enigmail extension is not working right, but > I was under the impression that it is just feeding data to gpg and > then receiving the response back. It's possible that your e-mail you > just checked was not sent through mailman since I also replied > directly to you explicitly (in which case the message has not been > modified) and you probably have the setting in the mailing list set > to not send duplicate messages if you are an explicit TO. I just > deleted all explicit TOs for this message, so everyone should be > receiving it through the mailing list and not directly. Is the > signature still valid for you now? I think enigmail can handle It has perfectly valid signatures, as do your earlier messages to the list. > messages with some signed and unsigned content, and maybe PGP/MIME > inherently does not support this and a mailing list re-writing parts > of messages is an expected action? If this message re-writing is an > expected action and I'm correct that PGP/MIME does not support > partially signed content, then maybe it is just a recommendation for > this mailing list to not use PGP/MIME for messages sent to the list? PGP/MIME definitely does support partially signed content. -- 'peter'[:-1]@petertodd.org 09e865d07f75341a5f3dc15f0e149055a241eedd552c3b88 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] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote: > > Andy Schroder > > On 06/10/2015 03:03 PM, Peter Todd wrote: > > > >>4. Seems like digital signatures are always broken on messages because > >>the list server slightly modifies them (?), so my e-mail client > >>doesn't verify them all. > >What type of digital signatures specifically? What email client? > > I think they are usually PGP/MIME signatures that are not working > right. If you'll notice from my e-mail headers: > > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 > Thunderbird/24.2.0 > X-Enigmail-Version: 1.6 It might be that Thunderbird doesn't properly handle messages with both signed and unsigned content. I use mutt myself, which handles it just fine. (the sigs on your emails verify just fine for instance) -- 'peter'[:-1]@petertodd.org 134f9a433a4bece258b5035ecda33384f820a60493ca2887 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] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 02:59:48PM -0400, Andy Schroder wrote: > Hello, > > A couple of motivations for a mailing list switch: > > 1. Sometimes the mailing list delays delivery for 10 minutes to several >days. > 2. There are usually lots of ads at the footer of the messages. Really >confuses new readers (for me at least), and seems like it really >pollutes such a historical dialog that may be referenced long into >the future. How would it be if the 10 Commandments, Magna Carta, >Bill of Rights, The Sermon on the Mount, or The Gettysburg Address >had ads intertwined within them? > 3. Don't think HTML messages are allowed. Please keep it that way; HTML messages have no place on a technical mailing list. > 4. Seems like digital signatures are always broken on messages because >the list server slightly modifies them (?), so my e-mail client >doesn't verify them all. What type of digital signatures specifically? What email client? -- 'peter'[:-1]@petertodd.org 04e3d7b1cff56c5264b16dd79d10a26683c2fabb11669b5d 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] 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 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 info
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 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] 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 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] [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 block size limit
On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote: > > there is no memory pool cap currently > > Real hardware does not have an infinite amount of RAM. Memory pool sizes > cannot grow unbounded. Some transactions with insufficient fees do get > dropped today after many hours. Actually they don't, which is an unfortunate problem with the existing mempool implementation; the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram consumed, and furthermore, actually getting that many transactions to propagate over the network is non-trivial. (no, I'm not going to tell you how) The obvious solution is to cap the size of the mempool and evict transactions lowest fee/KB first, but if you do that they you (further) break zeroconf security. On the other hand, if you don't break zeroconf security an attacker can prevent reasonable fee transactions from propagating. I probably should get around to fixing this... -- '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] Lexicographical Indexing of Transaction Inputs and Outputs
On Sat, Jun 06, 2015 at 08:06:56PM -0400, Kristov Atlas wrote: In general I think this is a good idea, and should be implemented; we've had a depressing number of wallets fail to implement randomization properly, if at all. > I've updated the draft BIP in two ways: > -Making it clear that sorting is algorithmically agnostic, but should > conform to the output of the example algorithms written in python > -The BIP now handles schemes that create an input/output dependency, such > as SIGHASH_SINGLE: > > Handling Input/Output Dependencies > > Some uncommon forms of transactions create an ordering dependency between > inputs and outputs of a transaction. Wallets forming these transactions > should first sort inputs according to the methodology outlined in section > “Transaction Inputs” of this BIP. Then, they should fix the output indices > that depend on the input order, and sort the remaining outputs around them. > If there are no outputs that do not depend on input order, then all outputs > will simply be ordered based on the expected scheme. The following are the > known cases of input/output dependency that must be handled specially: > > * SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI01 compliance > for a transaction must inspect the last byte of the scriptSig of each input > to determine the signature hash type. In the case of SIGHASH_SINGLE (0x03) > for input “n”, the verifier should expect that output “n” will be fixed > when considering output ordering. 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. As for IsStandard() rules - let alone soft forks - better to leave discussion of them out for now. In particular, for the soft-fork case mandating certain transaction orders will very likely cause problems in the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it might be appropriate for nodes to enforce a certain ordering, but that can be a separate BIP. (actually implementing that in Bitcoin Core would be annoying and ugly right now; without replace-by-fee ANYONECANPAY has a silly DoS attack (adding low-fee inputs) so I can't recommend wallets use it in the general case yet) "and a sequence number currently set to 0x." <- Actually, this will be changed in Bitcoin Core as of v0.11.0, which implements anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP describing it) Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? 1) https://github.com/bitcoin/bitcoin/pull/2340 -- 'peter'[:-1]@petertodd.org 079693d8d175b476081a04af9c1d00ea2dbe0efb011bd79e 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] BIP for Proof of Payment
On Sat, Jun 06, 2015 at 05:23:48PM +0200, Pieter Wuille wrote: > On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr wrote: > > > I also agree with Pieter, that this should *not* be so cleanly compatible > > with Bitcoin transactions. If you wish to share code, perhaps using an > > invalid opcode rather than OP_RETURN would be appropriate. > > > Using an invalid opcode would merely send funds into the void. It wouldn't > invalidate the transaction. Just set nLockTime to 5-1 and nSequence appropriately to make the transaction impossible to mine for the next 9500 years. Though I agree that this whole idea seems a bit dubious to me. -- 'peter'[:-1]@petertodd.org dd919214b66444dcebb4aa0214c1ab7c8b3b633be71f 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] Fwd: Block Size Increase Requirements
On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote: > On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote: > > > Whilst it would be nice if miners in China can carry on forever regardless > > of their internet situation, nobody has any inherent "right" to mine if > > they can't do the job - if miners in China can't get the trivial amounts of > > bandwidth required through their firewall and end up being outcompeted then > > OK, too bad, we'll have to carry on without them. > > > > I'd rather think of mining as a responsibility than a right per se, but > you're right in so far as it's competitive and self-correcting. It's important to remember that the service Bitcoin miners are providing us is *not* transaction validation, but rather decentralization. Validation is something every full node does already; there's no shortage of it. What's tricky is designing a Bitcoin protocol that creates the appropriate incentives for mining to remain decentralized, so we get good value for the large amount of money being sent to miners. I've often likened this task to building a robot to go to the grocery store to buy milk for you. If that robot doesn't have a nose, before long store owners are going to realise it can't tell the difference between unspoilt and spoilt milk, and you're going to get ripped off paying for a bunch of spoiled milk. Designing a Bitcoin protocol where we expect "competition" to result in smaller miners in more geographically decentralized places to get outcompeted by larger miners who are more geographically centralized gets us bad value for our money. Sure it's "self-correcting", but not in a way that we want. > > But I'm not sure why it should be a big deal. They can always run a node > > on a server in Taiwan and connect the hardware to it via a VPN or so. > > > > > Let's agree to disagree on this point. Note how that VPN, and likely VPS it's connected too, immediately adds another one or two points of failure to the whole system. Not only does this decrease reliability, it also decreases security by making attacks significantly easier - VPS security is orders of magnitude worse than the security of physical hardware. -- 'peter'[:-1]@petertodd.org 0e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9 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] Block Size Increase Requirements
On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote: > Hello. I am from F2Pool. We are currently mining the biggest blocks on > the network. So far top 100 biggest bitcoin blocks are all from us. We > do support bigger blocks and sooner rather than later. But we cannot > handle 20 MB blocks right now. I know most blocks would not be 20 MB > over night. But only if a small fraction of blocks more than 10 MB, it > could dramatically increase of our orphan rate, result of higher fee > to miners. Bad miners could attack us and the network with artificial > big blocks. As yhou know, other Chinese pools, AntPool, BW, they > produces ASIC chips and mining mostly with their own machines. They do > not care about a few percent of orphan increase as much as we do. They > would continue their zero fee policy. We would be the biggest loser. > As the exchanges had taught us, zero fee is not health to the network. > Also we have to redevelop our block broadcast logic. Server bandwidth > is a lot more expensive in China. And the Internet is slow. Currently > China has more than 50% of mining power, if block size increases, I > bet European and American pools could suffer more than us. We think > the max block size should be increased, but must be increased > smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, > and so on. Thanks. Great to hear from you! Yeah, I'm pretty surprised myself that Gavin never accepted the compromises offered by others in this space for a slow growth solution, rather than starting with over an order of magnitude blocksize increase. This is particularly surprising when his own calculations - after correcting an artithmetic error - came up with 8MB blocks rather than 20MB. Something important to note in Gavin Andresen's analysises of this issue is that he's using quite optimistic scenarios for how nodes are connected to each other. For instance, assuming that connections between miners are direct is a very optimistic assumption that depends on a permissive, unregulated, environment where miners co-operate with each other - obviously that's easily subject to change! Better block broadcasting logic helps this in the "co-operation" case, but there's not much it can do in the worst-case. Unrelated: feel free to contact me directly if you have any questions re: the BIP66 upgrade; I hear you guys were planning on upgrading your mining nodes soon. -- 'peter'[:-1]@petertodd.org 0db932d1cbd04a29d8e55989eda3f096d3ab8e8d95eb28e9 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 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 || CLTV) 1.0 BTC: GM -> 1.0 BTC: GM && (PT || CLTV) After 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] -> 0.5 BTC: PT t0.vout[1] -> 1.5 BTC: GM nLockTime = You can then give me funds with t1b: t0.vout[0] -> 1.5 BTC: PT t0.vout[1] -> 0.5 BTC: GM nLockTime = 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] 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] 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] 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] 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] 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 lo
[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
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] 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
ch earlier OpenTimestamps project did
among many others) Rather Factom acts as a proof-of-publication layer
that allows the proving of the negative.(4)
Zookeyv
---
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] 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] 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] 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
Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013)
On Sun, May 10, 2015 at 05:45:32PM -0300, Sergio Lerner wrote: > Two years ago I presented a new way to create a fee market that does not > depend on the block chain limit. > Solution: Require that the set of fees collected in a block has a > dispersion below a threshold. Use, for example, the Coefficient of > Variation (http://en.wikipedia.org/wiki/Coefficient_of_variation). If > the CoVar is higher than a fixed threshold, the block is considered invalid. It's not possible to create consensus rules enforcing anything about fees because it's trivial to pay miners out of band. For instance, you can pay transaction fees by including anyone-can-spend outputs in your transactions. The miner creating the block then simply adds a transaction at the end of their block collecting all the anyone-can-spend outputs. Equally, if you try to prohibit that - e.g. by preventing respending of funds in the same block - they can simply publish fee addresses and have people put individual outputs for those addresses in their transactions. (IIRC Eligius gave people the option to pay fees that way for awhile) -- 'peter'[:-1]@petertodd.org 0fa57b40dc86a61d35aaf9241c86f047ef6f4bab8f13dfb7 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 Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote: > The vast majority of users are running one of a handful of different wallet > apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; > Blockchain.info; and maybe a few others. The developers of all these > wallets have a vested interest in the continued usefulness of Bitcoin, and > so should not be opposed to changing their UTXO selection algorithms to one > that reduces the UTXO database instead of growing it. You can't assume that UTXO growth will be driven by walles at all; the UTXO set's global consensus functionality is incredibly useful and will certainly be used by all manner of applications, many having nothing to do with Bitcoin. As one of many examples, here's a proposal - with working code - to use the UTXO set to get consensus over TLC certificate revocations. The author, Christopher Allen, was one of the co-authors of the SSL standard: https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack There's nothing we can do to stop these kinds of usages other than forcing users to identify themselves to get permission to use the Bitcoin blockchain. Using the Bitcoin blockchain gives their users significantly better security in many cases than any alternatives, so there's strong incentives to do so. Finally, the cost many of these alternative uses are willing to pay pre UTXO/transaction is significantly higher than the fees many existing Bitcoin users can pay to make transactions. -- '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 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] 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 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] 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: > > > > 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: > > > > 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] 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 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] 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] 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] 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] 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 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
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
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 > 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] CLTV opcode allocation; long-term plans?
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote: > Peter Todd writes: > > That said, if people have strong feelings about this, I would be willing > > to make OP_CLTV work as follows: > > > > 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: > > > > 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 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: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 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 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 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: > 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 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" To: "Satoshi Nakamoto" 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] 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 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] 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 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: 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: 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
[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/
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" 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 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 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] 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_15&utm_medium=email&utm_campaign=VA_SF___ 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 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 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 goi
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 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 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 CHECKSIG, then the normal case is scriptSig: 1 IF 17:19 < petertodd> they concatenate to 1 IF ENDIF CHECKSIG, CODESEPARATOR is evaluated, and the signature is evaluated on the script ENDIF CHECKSIG 17:20 < petertodd> to delegate signing authority after the fact sign a signature on the script 0 IF ENDIF CHECKSIG 17:21 < petertodd> (remember that CODESEPARATORS are removed by SignatureHash()) 17:22 < petertodd> oops, I mean: CHECKSIGVERIFY 0 IF ENDIF CHECKSIG 17:22 < petertodd> anyway, to finally spend it, create another signature with pubkey2 signing the script CHECKSIGVERIFY 0 IF ENDIF CHECKSIG again, and finally spend it with the scriptSig: CODESEPARATOR 0 IF 17:24 < petertodd> after concatenation the script: CODESEPARATOR 0 IF CODESEPARATOR ENDIF 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_15&utm_medium=email&utm_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 > 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 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_15&utm_medium=email&utm_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 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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Thu, Mar 26, 2015 at 02:26:59PM -0700, Tom Harding wrote: > On 3/26/2015 1:42 PM, Gregory Maxwell wrote: > > Which is why a simpler, safer, client enforced behavior is probably > > preferable. Someone who wants to go hack their client to make a > > payment that isn't according to the payee will have to live with the > > results, esp. as we can't prevent that in a strong sense. > > I should have been clearer that the motivation for address expiration is > to reduce the rate of increase of the massive pile of bitcoin addresses > out there which have to be monitored forever for future payments. It > could make a significant dent if something like this worked, and were > used by default someday. Again, along the lines of what Gregory Maxwell is saying, if the payment instructions you have given to the sender say "don't make funds spendable with scriptPubKey after this date" why are you scanning those "old" bitcoin addresses for future payments? That makes no more sense than taking your p2pkh addresses and scanning for the same scriptPubKey embedded within a p2sh address - you haven't told anyone to pay you via that method so why expect anyone to do so? > Address expiration is not an enhancement to the payment experience and > it doesn't stop sender from doing something weird. Hacking a new > address for the recipient would be just as weird as hacking their client > IMHO. The sender is free to bury their Bitcoins in a safe in your neighbors front yard; you have no reason to accept such silly behavior as payment and every reason to ignore it. -- 'peter'[:-1]@petertodd.org 0b48023e9c98038c50b9a2044975bbdf9f43313400a156b6 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] 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] replace-by-fee v0.10.0rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not that issue - that's both easily avoidable, and has nothing to do with the replace-by-fee patch. I'm talking about something in the specific patch - good test to see if you've fully reviewed it. On 22 February 2015 14:25:24 GMT-05:00, Tom Harding wrote: >On 2/22/2015 9:12 AM, Peter Todd wrote: >> Did you notice the even more obvious way to defeat ANYONECANPAY >> scorched earth with that patch? > >Let's see. I could pay 10 people 1 BTC each with one tx, then >double-spend it with fees of 2BTC. Now at least three of the 10 have >to >work together if they want to scorched-earth me, since an individual or > >two-party claw-back wouldn't have high enough fees. Oops! -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6k8q AAoJEMCF8hzn9LncssUH/0acS1lhG8igRWBusnpDD+on+ryXNlTDKZGExzUKy7Wq 7SzYfMX8LAf/0Wbzs6wtyGzVjQOGmcM0XTAFN+Rp2rP3ZuSzAqO41Re+aUkiB67y 4PD8R05DmDgbc257HwIQM1aa+NPzzW5p8C+HnyZKpUqMNUAZOUVks22oRGywUXQY WrNKiSFQMxW0l1thjX63/x3iXjV92gxyd9qWK8uPAokwNEdULPU5S1mlZbji+MaJ cfR6WB02JR/GHPDK1rwmM8vAwQY82CMOJK3HB+1Dx88NvN5Ucn+ppVFtNETHA5g8 e7UcFeXXeMRF2AMwc9lFEmYsXmSAMJrTFeO981KoOHs= =fESj -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=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
