Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn m...@plan99.net wrote: Meanwhile, what I said *is* correct. New version numbers result in only a log print. Being hard forked off results in both log prints *and* the -alertnotify being run: That is easy to change; I'll submit a pull request. It is a good idea to get an -alertnotify sooner rather than later for EITHER a hard fork or a soft-fork. Better to be told you have to upgrade while the block.version is on its way to being a super-majority than after you are either hard-forked off the main chain (or soft-forked). I don't have any opinion on the hard- versus soft- fork debate. I think either can work. -- -- Gavin Andresen -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. If there's going to be an intermediate release (6 months?) which lays the groundwork for future rule changes, it helps more. It would be good if getblocktemplate was updated at the same time to serve errors if the fork warning is active. I'd hope miners have some way to automatically handle IBD/getting forked off the chain, but I guess some (newer) pools might not, and refusing to serve work should be the safest option that shuts them down. I don't have any opinion on the hard- versus soft- fork debate. I think either can work. P2SH was a soft fork and the sky did not fall, but miners did lose money and waste electricity mining blocks on the wrong side of the chain: https://bitcointalk.org/index.php?topic=75294.0 Presumably they didn't notice for longer because it looked like a run of unusually bad orphaning luck. It seems safer to have a clean fork, with alerts telling people during the lockin period before new rule enforcement starts (and possibly automated termination if there's no upgrade by the flag day?). Miners who ignore it would still risk losing money, but merchants who wait for a block at least would not be at risk. One open question is how can you actually trigger a hard fork? Coinbase scriptSigs are not executed, so putting some ignored but failing opcode sequence there wouldn't work. One possibility would be to have a special invalid tx in the block that marks the start of new rule enforcement. New nodes would know to ignore it. But this risks corrupting block explorers. Alternatively the coinbase outpoint structure could have its hash set to 1 instead of 0. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Partial wallet rescan
Hi all, Before starting to implement a patch for a specific need, I would like to be sure that it was not written already and available somewhere. This list is probably my best chance. I would like to add an optional parameter block_heigh to -rescan, from which the rescan would then start. When performing the wallet rescan, everything before the block number block_heigh would be ignored. Thus, it would do pretty much the same thing as the wallet birthday mechanism (which relies on nTimeFirstKey), the difference being that the point in time where to start would be *explicitly* given by the user, at launch time, on the command line. Another possiblity is to provide as parameter a time stamp instead of a block height; the interesting part for me is that anyway that information is explicitly provided by the user. Regards, Jeremie -- Jeremie Dubois-Lacoste, PhD. Belgian Bitcoin Association, Director. Université Libre de Bruxelles, Post-Doctoral Researcher. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
On 06/10/2014 08:43 p.m., Tom Harding wrote: On 10/5/2014 4:00 PM, Sergio Lerner wrote: If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect the fee for themselves. Sergio -- Just some thoughts on your interesting problem. Since everybody but M10 is on equal footing, I would expect M10 to have some fixed advantage depending on assumptions, and the bigger the advantage, the shorter the freeze time. Yes, that's how simulation works. The problem is that the existence of high-fee delays the decision to switch to M10. Since the network is moving slower (because of fragmentation) the effect of the high-fee is twofold: it delays the convergence because it promotes selfishness and it delays convergence because it promotes fragmentation. During that time window where the network is frozen, any other high-fee transaction only makes things worse. This is a very rare example where a well distributed network (100 miners having 1% each) is much much worse than 3 miners having 33% each. Using the my previous terminology, automatic fee-sharing (ORBS) is a solution to the freeze problem (FRONT) but opens the windows to CHAKIDO double-spending. and CHAKIDO double-spending is a much worse problem than FRONT. But as Tamas pointed out, sooner or later someone will implement something like ORBS, get over the critical mass of miner adoption, and then the CHAKIDO problem will be inevitable. The only clean solution to this problem is the DECOR+ protocol, which shares block-rewards by including uncles (as GHOST does) and splitting the reward between all miners at the same height until coinbase maturity is over. This way the best choice is always cooperative. PS: Using so many acronyms makes arguments much more concise, but suggest we should have all the attack terminology described in a single Bitcoin Security Wiki... -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote: Using the my previous terminology, automatic fee-sharing (ORBS) is a solution to the freeze problem (FRONT) but opens the windows to CHAKIDO double-spending. and CHAKIDO double-spending is a much worse problem than FRONT. I'm not following this. Perhaps I'm getting lost in terminology here. It's already to provide double spending bounties to greedy-rational miners, via a simple approach that has been known since at least early in 2011.I pay someone then create a later fraudulent doublespend which is nlocked at the height the original payment occurred, paying large fees. Then I spend the output of the fraudulent spend nlocked one block higher, and spend the output of that one again, nlocked one block higher, and so on... each step paying fees. A hypothetical purely greedy miner which considers all sequences of acceptable forks and transactions would see that they have higher expected returns assisting the theft (assuming the honest party doesn't fight back by also adopting a similar strategy), at least if the population of greedy miners is large relative to altruistic ones. I don't see how miners being able to roll forward fees makes anything worse, since the transactions themselves can also roll forward fees. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote: Then I spend the output of the fraudulent spend nlocked one block higher, and spend the output of that one again, nlocked one block higher, and so on... each step paying fees. Yes, you're right. I didn't consider that case. But the problem is that this is not automatic. Currently there is a clear division between miners how will not take the kickback (irrrational) and miners who will (rational). If somebody modifies the bitcoind to make this choice automatic, then DECOR+ is the only solution I know about to avoid people doing anonymous double-spends (with chained kickbacks, as you mention). The locktime on normal transactions you proposed does not solve the problem, just diminishes it in a constant value (which currently is very low) -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On 10/7/2014 8:50 AM, Gavin Andresen wrote: I don't have any opinion on the hard- versus soft- fork debate. I think either can work. Opinion: if a soft work works, it should be preferred, if for no other reason than once a hard-fork is planned, the discussion begins about what else to throw in. To minimize the frequency of hard-forks, the time for that is when the change being considered actually requires one. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development