Re: [Bitcoin-development] How to create a pull tester JAR

2014-08-06 Thread Jorge Timón
Once you ave the jar, you can also build with ./configure --disable-silent-rules --disable-ccache --with-comparison-tool=/path/to/your/BitcoindComparisonTool.jar Instead of the regular ./configure And after that make check will run most of the tests the pull tester does. On 8/5/14, Mike

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Tom Harding
How is eventual expiration of a tx that started life with an nLockTime in the future breaking, any more than any other tx expiring? On 8/6/2014 6:54 AM, Mike Hearn wrote: We could however introduce a new field in a new tx version. We know we need to rev the format at some point anyway.

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
...because nLockTime is the exact opposite of expiration. A locked TX begins life invalid, and becomes valid (not-expired) after nLockTime passes. A new field containing expiration time would work. On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding t...@thinlink.com wrote: How is eventual

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Christian Decker
+1 for the new field, overloading fields with new meaning is definitely not a good idea. Something like nExpireAt with a block height sounds reasonable to me, but we need to document that the usual caveats with blockchain reorgs apply. On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker decker.christ...@gmail.com wrote: +1 for the new field, overloading fields with new meaning is definitely not a good idea. To add a new field the best way to do it is create a new, parallel,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
A fork is not necessarily required, if you are talking about information that deals primarily with pre-consensus mempool behavior. You can make a network TX with some information that is digitally signed, yet discarded before it reaches miners. On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 11:42 AM, Peter Todd wrote: On 6 August 2014 08:17:02 GMT-07:00, Christian Decker decker.christ...@gmail.com wrote: +1 for the new field, overloading fields with new meaning is definitely not a good idea. To add a new field the best way to do it is create a new, parallel, tx

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Tom Harding
Today we have first-eligible-height (nLockTime), and mempool expiration measured from this height would work for the goals being discussed, no fork or protocol rev. With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach m...@monetize.io wrote: I highly doubt that is the best approach. If this nExpiry field is a consensus rule, then the Merkle tree or the appropriate paths through needs to be included with the

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Jeff Garzik
That won't necessarily work through large reorgs. You don't want to create a situation where a miner cannot mine a previously mined transactions. On Wed, Aug 6, 2014 at 1:02 PM, Tom Harding t...@thinlink.com wrote: Today we have first-eligible-height (nLockTime), and mempool expiration

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 01:02 PM, Tom Harding wrote: With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition, lock the whole thing until some point in the future. Note that this would be a massive, *massive* change that would completely

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 01:20 PM, Peter Todd wrote: The general case doesn't require transmission of any merkle data; it is derived from the tx data. How can that possibly be the case? The information is hidden behind the Merkle root in the transaction. The validator needs to know whether there is an

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 10:21:56 GMT-07:00, Mark Friedenbach m...@monetize.io wrote: On 08/06/2014 01:02 PM, Tom Harding wrote: With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 10:30:11 GMT-07:00, Mark Friedenbach m...@monetize.io wrote: On 08/06/2014 01:20 PM, Peter Todd wrote: The general case doesn't require transmission of any merkle data; it is derived from the tx data. How can that possibly be

[Bitcoin-development] SIGHASH_ANYONECANPAY extra inputs DoS attack

2014-08-06 Thread Peter Todd
tl;dr: Transactions with SIGHASH_ANYONECANPAY-using inputs can be DoS attacked by attackers adding extra inputs to them that make the fee/byte paid unfavorable to miners, while still being high enough to be relayed. While just a nuisance DoS attack, this is a serious obstacle towards using