From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UTMuY-0007VR-2d for bitcoin-development@lists.sourceforge.net; Sat, 20 Apr 2013 01:48:18 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.178 as permitted sender) client-ip=209.85.220.178; envelope-from=jeremy.spilman@gmail.com; helo=mail-vc0-f178.google.com; Received: from mail-vc0-f178.google.com ([209.85.220.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UTMuX-0005tt-1x for bitcoin-development@lists.sourceforge.net; Sat, 20 Apr 2013 01:48:18 +0000 Received: by mail-vc0-f178.google.com with SMTP id ib11so1363776vcb.9 for ; Fri, 19 Apr 2013 18:48:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.188.8 with SMTP id cy8mr13306156vcb.11.1366422491556; Fri, 19 Apr 2013 18:48:11 -0700 (PDT) Received: by 10.58.137.197 with HTTP; Fri, 19 Apr 2013 18:48:11 -0700 (PDT) Date: Fri, 19 Apr 2013 18:48:11 -0700 Message-ID: From: Jeremy Spilman To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=047d7bfeb10a38f7d904dac10723 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (jeremy.spilman[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UTMuX-0005tt-1x Subject: Re: [Bitcoin-development] Anti DoS for tx replacement X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 01:48:18 -0000 --047d7bfeb10a38f7d904dac10723 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I=92m not sure I followed John=92s proposal fully, why would a user sign T= X1 committing funds to the MULTISIG they may never get back? I also don=92t se= e the problem with getting a signed TX2 back from the AP before releasing TX1... see the sequence below. But more importantly, we only need exactly one replacement, so for starters we could anti-DoS by allowing only nSequence of 0 or MAX. If this was enabled on test-net, I would be including a link to transactions that implement the following proposal. At the moment, the best I can do is unit test and generate the rawtransaction output at each step = =96 you can find source code and test output here: https://gist.github.com/jspilman/5424310 The initial funding transaction and time-locked refund is pretty annoying to setup, if you want to support the general case of coins from arbitrarily sized inputs. You will have: - 1 or more inputs from the user, 0 or 1 change outputs - 0 or more inputs from the AP, 0 or 1 change outputs - 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92 This precludes using SIGHASH_SINGLE except for the special cases where inputs are perfectly sized (i.e. they are created in a prior step). 0. User and AP negotiate how much to escrow, who pays the fees, and how far in the future nLockTime will be set (how long user=92s funds will be ti= ed if AP doesn=92t close the channel) 1. User creates an unsigned TX1 with 1 or more inputs from user=92s =91listunspent=92, change going back to user (if any), and a single output = of =91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s= ends to the AP 2. AP adds to TX1; their inputs (if any), their change (if any), replaces OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and returns TX1 to User. 3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps it to himself. User, having completed TX1, knows its TxID and can now create TX2-Locked spending TX1 back to themselves. User sets nLockTime to the agreed point, signs SIGHASH_ALL, and sends TX2-Locked to AP. 4. AP verifies TX2-Locked and adds their signature, and returns TX2-Locked to User. User can now broadcast TX1 and TX2-Locked. 5. At each payment milestone, user creates TX2-Final; TX1 as input, final nSequence, no lock time, with a single output going back to to the user, and an amount equal to the remaining balance of the channel. User signs with SIGHASH_SINGLE and sends to the AP. 6. AP can add an output to TX2-Final sending their portion of the coins where ever they want, sign it SIGHASH_ALL, and broadcast it at any point, closing the channel. AP must broadcast TX2-Final before nLockTime, but has no guarantee the user hasn=92t offered a bribe for miners by spending TX2-Locked with a large fee, e.g. a pissed off user spends TX2-Locked entirely to fees just to see if they can convince miners to wait for it. The alternative to the TX2-Locked is a 3rd party in the MULTISIG who is trusted to close the channel at the request of either party, based on the latest TX2-Final which was sent by the user. In this case there is no TX2-Locked, only a single boardcast version of TX2-Final, and you do not need transaction replacement at all. Thanks, --Jeremy --047d7bfeb10a38f7d904dac10723 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I=92m not sure I followed John=92s proposal fully, why would a user si= gn TX1=20 committing funds to the MULTISIG they may never get back? I also don=92t s= ee the=20 problem with getting a signed TX2 back from the AP before releasing TX1... = see=20 the sequence below. But more importantly, we only need exactly one replacem= ent,=20 so for starters we could anti-DoS by allowing only nSequence of 0 or MAX.

If this was enabled on test-net, I would be including a link to=20 transactions that implement the following proposal. At the moment, the bes= t I=20 can do is unit test and generate the rawtransaction output at each step =96= you=20 can find source code and test output here: <= a href=3D"https://gist.github.com/jspilman/5424310">https://gist.github.com= /jspilman/5424310

The initial funding transaction and time-locked refund is pretty annoy= ing=20 to setup, if you want to support the general case of coins from arbitrarily= =20 sized inputs. You will have:
- 1 or more inputs from the user, 0 or 1 change outputs
- 0 or more inputs from the AP, 0 or 1 change outputs
- 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92

This precludes using SIGHASH_SINGLE except for the special cases where= =20 inputs are perfectly sized (i.e. they are created in a prior step).

0. User and AP negotiate how much to escrow, who pays the fees, and ho= w far=20 in the future nLockTime will be set (how long user=92s funds will be tied i= f AP=20 doesn=92t close the channel)

1. User creates an unsigned TX1 with 1 or more inputs from user=92s=20 =91listunspent=92, change going back to user (if any), and a single output = of=20 =91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s= ends to the=20 AP

2. AP adds to TX1; their inputs (if any), their change (if any), repla= ces=20 OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and= =20 returns TX1 to User.

3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps= it=20 to himself. User, having completed TX1, knows its TxID and can now create= =20 TX2-Locked spending TX1 back to themselves. User sets nLockTime to the agr= eed=20 point, signs SIGHASH_ALL, and sends TX2-Locked to AP.

4. AP verifies TX2-Locked and adds their signature, and returns TX2-Lo= cked=20 to User. User can now broadcast TX1 and TX2-Locked.

5. At each payment milestone, user creates TX2-Final; TX1 as input, fi= nal=20 nSequence, no lock time, with a single output going back to to the user, an= d an=20 amount equal to the remaining balance of the channel. User signs with=20 SIGHASH_SINGLE and sends to the AP.

6. AP can add an output to TX2-Final sending their portion of the coin= s=20 where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,= =20 closing the channel. AP must broadcast TX2-Final before nLockTime, but has= no=20 guarantee the user hasn=92t offered a bribe for miners by spending TX2-Lock= ed with=20 a large fee, e.g. a pissed off user spends TX2-Locked entirely to fees just= to=20 see if they can convince miners to wait for it.

The alternative to the TX2-Locked is a 3rd party in the MULTISIG who i= s=20 trusted to close the channel at the request of either party, based on the l= atest=20 TX2-Final which was sent by the user. In this case there is no TX2-Locked, = only=20 a single boardcast version of TX2-Final, and you do not need transaction=20 replacement at all.

Thanks,
--Jeremy
--047d7bfeb10a38f7d904dac10723--