From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Christian Decker <decker.christian@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Date: Fri, 04 May 2018 05:15:41 -0400 [thread overview]
Message-ID: <qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.com> (raw)
In-Reply-To: <877eongu33.fsf@gmail.com>
Good morning Christian and list,
It seems to me, that `SIGHASH_NOINPUT` may help make some protocol integrate better with existing wallets.
I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in LN discussions, when the issue of transaction malleation was considered (before SegWit, being totally uncontroversial, was massively adopted). The sketch below, I believe, is somewhat consistent with how it could have been used in funding a channel.
Consider a CoinSwap protocol. Each side writes a transaction that pays out to an ordinary 2-of-2 multisig address. But before each side writes and signs that transaction, it first demands a timelocked backout transaction to let them recover their own funds in case it falls through (more generally, every offchain protocol has a similar setup stage where some way to back out is signed before all parties enter into the contract).
Now, without `SIGHASH_NOINPUT`, we would first require that the initial funding transaction be written (but not signed and broadcast), and then the txid to the other side. The other side then generates the backout transaction (which requires the txid and outnum of the funding outpoint) and returns the signature for the backout transaction to the first side.
Because of this, an implementation of CoinSwap needs to have control of its own coins. This means that coin selection, blockchain tracking, and mempool tracking (i.e. to handle RBFs, which would invalidate any further transactions if you used coins received by RBF-able transactions while unconfirmed) needs to be implemented.
But it would be much nicer if instead the CoinSwap implementation could simply say "okay, I started our CoinSwap, now send X coins to address A", and then the user uses their ordinary wallet software to send to that address (obviously before the CoinSwap can start, the user must first provide an address to which the backoff transaction should pay; but in fact that could simply be the same as the other address in the swap).
1. The user will not have to make a separate transfer from their wallet, then initiate a swap, then transfer from the CoinSwap implementation to their usual wallet: instead the user gets an address from their wallet, initiates the swap, then pays to the address the CoinSwap implementation said to pay and wait to receive the swapped funds to their normal wallet.
2. Implementing the CoinSwap program is now somewhat easier since we do not need to manage our own funds: the software only needs to manage the single particular coin that was paid to the single address being used in the swap.
3. The smaller number of required features for use means easier implementation and testing. It also makes it more likely to be implemented in the first place, since the effort to make it is smaller.
4. The lack of a wallet means users can use a trusted wallet implementation (cold storage, hardware wallet, etc) in conjunction with the software, and only risk the amount that passes through the CoinSwap software (which is smaller, since it does not have to include any extra funds to pay for fees).
With `SIGHASH_NOINPUT`, we can indeed implement such a walletless CoinSwap (or other protocol) software. We only need to provide the public keys that will be used in the initial 2-of-2, and the other side can create a signature with `SIGHASH_NOINPUT` flag.
The setup of the CoinSwap then goes this way. The swapping nodes exchange public keys (two for each side in this case), they agree on who gets to move first in the swap and who generates the preimage, and then they agree on what the backout transactions look like (in particular, they agree on the address the backout transactions spend) and create signatures, with `SIGHASH_NOINPUT`. In particular, the signatures do not commit to the txid of the transaction that they authorize spending. The CoinSwap sofwares then turn around to their users and say "okay, send to this address", the users initiate the swap using their normal wallet software, the CoinSwap software monitors only the address it asked the user to use, then when it appears onchain (the CoinSwap software does not even need to track the mempool) it continues with the HTLC offers and preimage exchanges until the protocol completes.
In a world where walletless CoinSwap exists, consider this:
1. A user buys Bitcoin from an exchange. The exchange operates a wallet which they credit when the user buys Bitcoin.
2. The user starts a CoinSwap, giving the destination address from their cold-storage wallet.
3. The CoinSwap tells the user an address to send to. The user withdraws money from the exchange using that address as destination (1 transaction)
4. The user waits for the CoinSwap to finish, which causes the funds to appear in their cold-storage wallet (1 transaction).
If CoinSwap implementations all needed their own wallets, then instead:
1. A user buys Bitcoin from an exchange.
2. The user withdraws the funds from the exchange to a CoinSwap implementation wallet (1 transaction).
3. The user performs a CoinSwap which goes back to the CoinSwap implementation wallet (2 transactions).
4. The user sends from the CoinSwap wallet to their cold storage (1 transaction). (granted, the CoinSwap implementation could offer a feature that immediately transfers the swapped funds to some other wallet, but we still cannot get around the transfer from the exchange to the CoinSwap wallet)
A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to use; it immediately paints the user as using some special protocol. So much for `SIGHASH_NOINPUT` CoinSwap.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2018-05-04 9:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 16:29 Christian Decker
2018-04-30 18:25 ` Dario Sneidermanis
2018-05-01 16:58 ` Russell O'Connor
2018-05-01 17:32 ` Christian Decker
2018-05-04 9:15 ` ZmnSCPxj [this message]
2018-05-04 11:09 ` Christian Decker
2018-05-04 14:25 ` ZmnSCPxj
2018-09-26 9:36 ` Jonas Nick
2018-09-26 19:45 ` Johnson Lau
2018-09-26 20:40 ` Jonas Nick
2018-05-07 19:40 ` Christian Decker
2018-05-07 20:51 ` Bram Cohen
2018-07-03 6:58 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-07-03 11:54 ` William Casarin
2018-05-08 14:40 ` [bitcoin-dev] " Anthony Towns
2018-05-09 23:01 ` Olaoluwa Osuntokun
2018-05-09 23:04 ` Rusty Russell
2018-05-14 9:23 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2018-05-15 14:28 ` Christian Decker
2018-05-07 23:47 ` [bitcoin-dev] " Olaoluwa Osuntokun
2018-05-10 14:12 ` Christian Decker
2018-07-02 18:11 ` Gregory Maxwell
2018-07-03 4:56 ` Rusty Russell
2018-07-03 5:21 ` Peter Todd
2018-07-03 23:45 ` Gregory Maxwell
2018-07-09 9:41 ` Peter Todd
2018-07-03 12:05 ` Christian Decker
2018-07-03 12:13 ` [bitcoin-dev] [Lightning-dev] " Luke Dashjr
2018-07-04 18:08 ` fred savage
2018-07-05 8:18 ` vv01f
[not found] ` <CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>
2018-07-11 7:43 ` ZmnSCPxj
2018-07-13 0:04 ` Rusty Russell
2018-07-13 9:50 ` fred savage
2018-07-13 11:07 ` Christian Decker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='qFwv4IxuQlev23nK6hMyrDz231PXkGTBGZvaa3VAQs-32VcpjR18bsKQEioxOuauD9tDCUap2DlBGbr9QD0OC9-w_55tbo25P1BjK75Xj30=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=decker.christian@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox