[Bitcoin-development] SIGHASH_ANYONECANPAY extra inputs DoS attack

[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 ANYONECANPAY.


Background: What uses ANYONECANPAY?
---

1) Crowdfunds/assurance contracts: e.g. Hearn's upcoming Lighthouse, as
well as Armory's implementation.

2) Fee bumping: receiver or sender can add inputs w/ ANYONECANPAY to get
a tx confirmed without the (expensive) overhead of a second CPFP tx.

3) Privacy: inputs are more deniable in some cases, e.g. dust used for
fees, which anyone could have added.

4) Replace-by-fee scorched earth: best implementations(1) depend on fee
bumping.


Partial defense: replace-by-fee
---

The attacker's modified transaction will usually, but not always, be
replaced by the intended one as the latter will have higher fees.
However replace-by-fee implementations must charge adequately for
network bandwidth consumed, so there will be edge-cases where the
replacement does not happen.


Transaction fee/byte optimization
-

Each input that does not use SIGHASH_ALL can be evaluated in terms of
whether or not it increases the fees/byte paid by the transaction. Thus
we can optimize a transaction to pay the highest fees/byte by doing the
following:

def optimize_tx(tx):
tx2 = CTransaction(vin=[], vout=tx.vout, nLockTime=tx.nLockTime)

for txin in :
if :
continue

if :
prev_fee_per_byte = tx2.fees / len(tx2.serialized())
tx2.vin.append(txin)
if tx2.fees / len(tx2.serialized()) < prev_fee_per_byte:
# adding txin decreased fees/byte
tx2.vin.pop()
return tx2

else:
tx2.vin.append(txin)

return tx

Essentially txin's that reduce the profitability of the transaction are
dropped, including the attacker's added txins. Meanwhile txins that
increase the profitability can be added by anyone.


1) "[Bitcoin-development] Replace-by-fee scorched-earth without 
child-pays-for-parent",
   Apr 28th 2014, Peter Todd,
   
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05211.html



signature.asc
Description: Digital signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Payment ID #'s for Stealth Addresses

[Peter Todd]

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 customer's account. Similarly an informal
person-to-person transaction can attach a number short enough to be
communicated verbally or on paper. Finally multiple payments with the
same ID # can be merged together in wallet UI's, allowing
merge-avoidance to be conveniently used with stealth addresses.

To avoid accidental collision such payment #'s should be at least
64-bits; to avoid privacy loss the encoded size should be the same for
all users. Thus we pick 64-bits or 8-bytes. In addition for the purposes
of CoinJoin and multiple outputs it would be desirable for all
stealth-using outputs the option of sharing a single 33-byte ephemeral
pubkey. Thus our OP_RETURN output becomes:

OP_RETURN   { ... }

Of course, this can't be accomodated within the existing 40-byte, one
OP_RETURN per tx, IsStandard() rules, something which is already causing
issues w/ Dark Wallet when users try to send to multiple stealth
addresses at once, and when multiple stealth sends are CoinJoin'd
together.

1) "Merge avoidance", Dec 11th 2013, Mike Hearn,
https://medium.com/@octskyward/merge-avoidance-7f95a386692f



signature.asc
Description: Digital signature
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

[Tim Ruffing]

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 and without trusted 
third parties. (If you are not familiar with CoinJoin, the idea is explained 
here: https://bitcointalk.org/index.php?topic=279249.0 )

The protocol is essentially a clever way to create a CoinJoin transaction. 
Recall that the idea of CoinJoin is mixing with one SINGLE transaction that 
has multiple input addresses and multiple fresh output addresses (i.e., one 
pair of addresses per user). The advantage of CoinJoin over mixing with a 
server or trusted party is that nobody can steal coins. Each user can check if 
the single transaction sends enough coins to his fresh output address. If this 
is not the case, the user can just refuse to sign the transaction and nothing 
(bad) happens.

The difficulty in CoinJoin is to let the participants announce their fresh 
output addresses without breaking anonymity: Of course, if a participant of 
the protocol just announces "I have 1 BTC at address X now" and "I would like 
to have it back at address Y", then everybody can link X and Y and mixing is 
useless. A naive approach is to send these two messages via a secure channel 
to a server that organizes the whole mixing. While the server cannot steal 
coins, the server still has to be trusted for anonymity, because it knows 
which input addresses belong to which output addresses.

We present the list of CoinShuffle's features at the end of this e-mail. An 
overview over the technical details can be found on the project page:
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/

Moreover, for the full details, have a look at the research paper on 
CoinShuffle that can be found here:
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf

The paper has been accepted at a major European academic conference on 
security (ESORICS). We will present the idea there. 

Our Proof-of-concept Implementation
---
There is a proof-of-concept implementation (written in Python) available on 
our project page. It is really only a proof-of-concept and it implements only 
the announcement of the addresses, not the creation of the transaction. 
Moreover, the code is CERTAINLY INSECURE and not well-written; our only goal 
was to demonstrate feasibility and estimate the performance of our approach.


Our Future Plans

Now we are planning a full, open-source implementation of the protocol. Of 
course, we would like to build on top of an existing wide-spread client. Since 
we do not have much experience in the design of existing Bitcoin clients, we 
would appreciate any help in the process. In particular, we did not decide 
which of the existing clients we would like to extend. Any hints towards this 
decisions would very helpful. Help in design and coding would be great but we 
also would like to hear your comments, criticism, and improvements for the 
protocol itself.

CoinShuffle Features

CoinShuffle has the following features:

 - Decentralization / no third party:
There is no (trusted or untrusted) third party in a run of the protocol. 
(Still, as in all mixing solutions, users need some way to gather together 
before they can run the protocol. This can be done via a P2P protocol if a 
decentralized solution is desired also for this step.)

   
 - Unlinkability of input and output addresses:
Nobody, in particular no server (there is none!), can link input and output 
addresses of a mixing transaction, as long as there are at least two honest 
participants in run of the protocol.
   
(This is not a weakness: If there is only one honest participant, meaningful 
mixing is just impossible, no matter how it is organized. If all the other 
participants collude, they know all their input and output addresses and can 
immediately determine the output address of the honest participant.)

 - Security against thefts:
As explained above, nobody can steal coins during the mixing because of the 
CoinJoin principle.  
Every participant can verify that his money will not be stolen. Otherwise, he 
refuses to sign the transaction and nothing will happen.

 - Robustness against denial-of-service:
In CoinJoin, a single malicious (or malfunctioning) client suffices to stop 
the whole protocol (e.g., by just refusing to sing the transaction without a 
proper reason.) This can easily lead to DoS attacks but these can be countered 
in CoinShuffle.
   
While in case of disruption, the current run of the protocol has to stop, 
CoinShuffle addresses this problem as follows:  In case of active disruption, 
i.e., some participant sends wrong messages, the protocol provides a proof of 
this misbehavior. Then the honest protocol parties can start a new run of the

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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
>whole
>> thing until some point in the future.
>
>Note that this would be a massive, *massive* change that would
>completely break bitcoin output frangibility. Merchants would have to
>start demanding input history back to a certain depth in order to
>ensure
>they are not exposing themselves to undue reorg-expiry risk.

Bitcoin is already "broken" in that regard due to malleability, and more 
fundamentally, the existence of anyone-can-spend outputs, known private keys, 
SIGHASH_ANYONECANPAY, etc.

In any case, reorg-doublespend risk is no different than reorg-expiry risk.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mcdMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhSdiB/9no/fXR50Zej4l6Hyt
gDvM9GWosGxZydQfplrUYzS9nLWTJgkjNYkrJk1OXPlkiNoHhlpCK6TuEL3DXBo8
txDBhp/xls7aFHELpPhP5iKrEj0J6fyMp9wKRVtUu0J+RhHY22v+iEQf//dGUX4v
hQPwATubmnyeVd71TAKyW6zCPjoEh0IG19tRVvw/v7/qNTXHdSZTkSVzQa4GP2gr
2xVqXTeOycPKqIU+GaNI4aRAL2DUm1kW3jG/+h3BwnJNd5q+0ELpC6xDmkA6hkNz
N6BFCtoghhKNH+FNsZKAzE9w8dYngZQbaA9vVdaR6SXzz9KuG526EymOF7e55IBJ
FMu+
=ii2+
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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? The information is hidden behind the
>Merkle root in the transaction. The validator needs to know whether
>there is an expiry and what it is. What's it supposed to do, guess?

The general case is all committed information is included in the transaction; 
the merkle tree is a compatibility path, as well as an optimisation for lite 
clients and applications.

You should read more about soft-forks; see the BIP. Remember that Bitcoin 
protocol development and deployment is not a centrally controlled activity.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mgPMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhSYlCAC1ncAGQt53HKS+8/rq
OG0RGrqE2l2/qCM/ybd9M8TkwxaI3NB5bqfIus8dB5MnyiTBFS3ooN54kNNOHtSX
2rEzPJphtOj46tk3nqe1QO3cbFJPjBCtxZff51DWZckhCiO2Iy1Br3fK3v55iscp
1jxyZnpfgUG/Ivfx+h6vkisucBXgXJ82d5vzvMIMxixh4v2+4/SAcSY6HCLIpxmV
Z3l0NcGllnmWe5B6eftpWYUAREuoCNk/671jHmwu0cqk2u/Egrp776zxkEO1xivH
d0EWjJmlDLmQ2hEhkpBq46ji/2m4EWPLqTW/EXf3RzwU8uCEldbxEe2tyZ0d6oBt
NnTE
=AhV7
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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 expiry and what it is. What's it supposed to do, guess?

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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 break bitcoin output frangibility. Merchants would have to
start demanding input history back to a certain depth in order to ensure
they are not exposing themselves to undue reorg-expiry risk.

There are useful applications of a consensus-enforced expiry,
particularly within a private (signed block) side chain, and for that
reason it is useful to have a discussion about the merits of an nExpiry
field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving
either. However I don't see this ever becoming part of the public
bitcoin network.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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  wrote:

>
> 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, lock the whole thing
> until some point in the future.
>
>
>
> On 8/6/2014 9:15 AM, Jeff Garzik wrote:
>
> 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  wrote:
>
>> -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, tx
>> format where fields are committed by merkle radix tree in an extensible and
>> provable way. You'd then commit to that tree with a mandatory OP_RETURN
>> output in the last txout, or with a new merkle root.
>>
>> Changing the tx format itself in a hard-fork is needlessly disruptive,
>> and in this case, wastes opportunities for improvement.
>> -BEGIN PGP SIGNATURE-
>> Version: APG v1.1.1
>>
>> iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
>> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
>> Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
>> //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
>> 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
>> 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
>> RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
>> sJKN
>> =oPSo
>> -END PGP SIGNATURE-
>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
>
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the 
> future.http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
>
>
> ___
> Bitcoin-development mailing 
> listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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 as
>part of the network and on-disk data structures, so that proper
>validation can be done. This would be both more disruptive and less
>efficient than simply adding an nExpiry field to the transaction
>format,
>as we do in Freimarkets.

The general case doesn't require transmission of any merkle data; it is derived 
from the tx data. Equally changing a data format is certainly: note how 
Freimarkets has no third-party library support because you've made it 
incompatible with the standard Bitcoin data structures. Merkle radix tree 
formatting OTOH is just a cryptographically committed extension of the 
tag-value concept seen in protobuf, among others.

re: efficiency, we need fundamental improvements in efficiency, not little 
micro-optimisations everywhere done at high cost to maintainability.

re: validation, note how the merkle radix tree meets that need by allowing the 
absence of data to be proven.

>If the field is pre-consensus (a mempool gentleman's agreement), then
>it
>has no business in the transaction structure at all and should be
>packaged in some sort of envelope container.

It's also rather useless without consensus. Expiry is only useful if it is a 
guarantee, if not you might as well just implement tx replacement directly.

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4mPZMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcbKCACz/Qh3wm7ud9iwbvm3
Hzib36/fixk2++z6xlxh8G8afUaAe7ADCoz/TLK7RNIhUnr2hlsPO+Id2XvVBSm1
gXavj4iDxq8TpWsC8zPs5vyyY/dVwQ0RbidQFSpncmdW6EYVpIQp9nP3sSnBv1M8
c7BVidg708tc44uYiM9jeTzh6amP5yD0+G9FYYmy36BAQj8+4iD1ZCkiye1y5WUL
9MSN8LOxRFEwWQJmySXmJ1I9V81l1NSRQcQtfLVCzEIWLJXrZ0xwOq0SryEObg73
72NZKc2u8la3CPDoCG773ENbGHl+mGJW9M5ypV0s2RdkdZMgaFNnl/SBrWAcPd43
FkLr
=OMOy
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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, lock the whole 
thing until some point in the future.



On 8/6/2014 9:15 AM, Jeff Garzik wrote:
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 > wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
mailto: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 format where fields are committed by merkle radix
tree in an extensible and provable way. You'd then commit to that
tree with a mandatory OP_RETURN output in the last txout, or with
a new merkle root.

Changing the tx format itself in a hard-fork is needlessly
disruptive, and in this case, wastes opportunities for improvement.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
//qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
sJKN
=oPSo
-END PGP SIGNATURE-




--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Mark Friedenbach]

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 fields are committed by merkle radix tree in an
> extensible and provable way. You'd then commit to that tree with a
> mandatory OP_RETURN output in the last txout, or with a new merkle
> root.
> 
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.

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 as
part of the network and on-disk data structures, so that proper
validation can be done. This would be both more disruptive and less
efficient than simply adding an nExpiry field to the transaction format,
as we do in Freimarkets.

If the field is pre-consensus (a mempool gentleman's agreement), then it
has no business in the transaction structure at all and should be
packaged in some sort of envelope container.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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  wrote:

> -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, tx
> format where fields are committed by merkle radix tree in an extensible and
> provable way. You'd then commit to that tree with a mandatory OP_RETURN
> output in the last txout, or with a new merkle root.
>
> Changing the tx format itself in a hard-fork is needlessly disruptive, and
> in this case, wastes opportunities for improvement.
> -BEGIN PGP SIGNATURE-
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
> Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
> //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
> 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
> 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
> RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
> sJKN
> =oPSo
> -END PGP SIGNATURE-
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Peter Todd]

-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 are committed by merkle radix tree in an extensible and provable 
way. You'd then commit to that tree with a mandatory OP_RETURN output in the 
last txout, or with a new merkle root.

Changing the tx format itself in a hard-fork is needlessly disruptive, and in 
this case, wastes opportunities for improvement.
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
//qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
sJKN
=oPSo
-END PGP SIGNATURE-


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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  wrote:

>  ...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 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.
>>
>>
>> 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 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 at 12:01 AM, Tom Harding  wrote:
>>>
 ...

>>>
>>  If nLockTime is used for expiration, transaction creator can't lie
 to
 help tx live longer without pushing initial confirmation eligibility
 into the future.  Very pretty.  It would also enable "fill or kill"
 transactions with a backdated nLockTime, which must be confirmed in a
 few blocks, or start vanishing from mempools.

>>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
>
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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  wrote:

>
> 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.
>
>
> 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 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 at 12:01 AM, Tom Harding  wrote:
>>
>>> ...
>>>
>>
>  If nLockTime is used for expiration, transaction creator can't lie to
>>> help tx live longer without pushing initial confirmation eligibility
>>> into the future.  Very pretty.  It would also enable "fill or kill"
>>> transactions with a backdated nLockTime, which must be confirmed in a
>>> few blocks, or start vanishing from mempools.
>>>
>>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[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.



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 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 at 12:01 AM, Tom Harding mailto:t...@thinlink.com>> wrote:

...




If nLockTime is used for expiration, transaction creator can't
lie to
help tx live longer without pushing initial confirmation
eligibility
into the future.  Very pretty.  It would also enable "fill or
kill"
transactions with a backdated nLockTime, which must be
confirmed in a
few blocks, or start vanishing from mempools.



--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Mike Hearn]

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 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 at 12:01 AM, Tom Harding  wrote:
>
>> On 8/5/2014 12:10 PM, Kaz Wesley wrote:
>> > Any approach based on beginning a transaction expiry countdown when a
>> > transaction is received (as in mempool janitor) seems unviable to me:
>> > once a node has forgotten a transaction, it must be susceptible to
>> > reaccepting it;
>>
>> It's hard to argue with that logic.
>>
>> If nLockTime is used for expiration, transaction creator can't lie to
>> help tx live longer without pushing initial confirmation eligibility
>> into the future.  Very pretty.  It would also enable "fill or kill"
>> transactions with a backdated nLockTime, which must be confirmed in a
>> few blocks, or start vanishing from mempools.
>>
>>
>>
>> --
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
>
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Jeff Garzik]

 ...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 at 12:01 AM, Tom Harding  wrote:

> On 8/5/2014 12:10 PM, Kaz Wesley wrote:
> > Any approach based on beginning a transaction expiry countdown when a
> > transaction is received (as in mempool janitor) seems unviable to me:
> > once a node has forgotten a transaction, it must be susceptible to
> > reaccepting it;
>
> It's hard to argue with that logic.
>
> If nLockTime is used for expiration, transaction creator can't lie to
> help tx live longer without pushing initial confirmation eligibility
> into the future.  Very pretty.  It would also enable "fill or kill"
> transactions with a backdated nLockTime, which must be confirmed in a
> few blocks, or start vanishing from mempools.
>
>
>
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[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 Hearn  wrote:
> No problem.
>
> The pull tester entry point can be found here:
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java
>
> (nb: in the near future I will be re-namespacing the library from
> com.google.bitcoin to org.bitcoinj to reflect that it no longer has
> anything to do with Google and then this link will break).
>
> The code itself is a rather bad example of copy/paste coding and I can say
> that, because Matt knows it and already plans to refactor things ;) So if
> anyone is thinking of adding tests to the framework coordinate with him
> first to ensure you don't end up conflicting with a big refactor/rewrite.
>


-- 
Jorge Timón

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development