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 ANYONECA
Real-world experience with stealth address implementations used by
Cryptonote/Monero/etc. have shown that being able to attach a number of
some kind to each stealth-sent txout is valuable. For instance an
exchange with many customers can use such #'s to disambiguate payments
and credit the correct
Hey,
We (a group of researchers in Germany) propose a decentralized protocol for
CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is
called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin
in the original spirit of Bitcoin, i.e., decentralized a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:21:56 GMT-07:00, Mark Friedenbach 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, lock the
>w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:30:11 GMT-07:00, Mark Friedenbach 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 the case? T
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 ex
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
complete
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 wrote:
>
> Today we have first-eligible-height (nLockTime), and mempool expiration
> measured from this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach 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 transaction
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, lo
On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> 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 format where field
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 wrot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
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 format
where fields
+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 wrote:
> ...b
...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 wrote:
>
> How is eventual expiration of a tx th
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.
We could however introduce a new field in a new tx version. We know we need
to rev the format at some point anyway.
On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik wrote:
> ...and existing users and uses of nLockTime suddenly become worthless,
> breaking payment channel refunds and other active us
...and existing users and uses of nLockTime suddenly become worthless,
breaking payment channel refunds and other active uses of nLockTime.
You cannot assume the user is around to rewrite their nLockTime, if it
fails to be confirmed before some arbitrary deadline being set.
On Wed, Aug 6, 2014
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 Hea
19 matches
Mail list logo
