public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
Date: Sat, 13 Jun 2020 01:20:16 +0000	[thread overview]
Message-ID: <7BPgx65Eh5HE5wLIqeG9G-bdsxxkDJJIzcyOJvS6_FIxXfA10sbFe5dfwQDNiEOExZ9Y72lHq88lKzcBRIFnYGFY5I2vwk6Dg7BcCMjmS2Y=@protonmail.com> (raw)
In-Reply-To: <m-yAKsQ52s-bYOrtEXVwETAcJ8sSbJt0k9WDN1ueidJ01IaEHRJtq9Odffmz_2utLxPfmI418x58aFc3vKBpOD2FKqgeCUAn1mvI1OSyGRY=@protonmail.com>

Good morning Antoine,

By dropping the requirement that a participant can seamlessly leave the CoinPool, it allows participants to split up their coins among new aliases and to use a different identity for later claiming coins.
With WabiSabi, none of the other participants can get a mapping between current-state aliases and the actual participants.

Now, in order to authorize moving coins from an output on the current state to a new output on the next state, obviously the pool needs to get a signature from its current owner.
Ideally, we would not want to have to implement SCRIPT inside the CoinPool software.

And with Taproot, a pubkey can hide one or more SCRIPTs.
If we use pubkeys as the identities of owners of coins, then it allows an alias to encode a SCRIPT.

With the combination of both features, we can instantiate HTLCs (or, with `SIGHASH_ANYPREVOUT`, PTLCs) inside a CoinPool "alias" pubkey identity, allowing for interoperation with LN.

Now suppose I have 1.0 BTC in a CoinPool.
I want to make an HTLC with you (hashlocked to you, timelocked to me), for 0.5 BTC.

I encode the HTLC SCRIPT, and put it into a Taproot whose internal pubkey is a MuSig of fresh identities of mine and yours.

Then, inside the CoinPool, I split my 1.0BTC to a 0.5BTC coin to a fresh identity of mine, and 0.5BTC to our HTLC Taproot.

If you can acquire the hash, you give it to me, and I am supposed to hand you a partial signature share to the HTLC Taproot that you can later complete and present to the CoinPool in the next update round in order to get the HTLC value.
If I do not hand you the signature share even after you hand the hash, you just drop the entire CoinPool onchain, instantiating the HTLC Taproot output onchain, and using the SCRIPT branch to claim using the hash you know.

If the timelock expires, I ask you to hand over your partial signature to the HTLC Taproot that I can later complete and present to the CoinPool in the next update round to recover the HTLC value.
If you do not hand over the signature share, I drop the CoinPool onchain, which instantiates the HTLC Taproot output onchain, and use the SCRIPT branch to claim using the timelock branch.

You can also ask to abort the HTLC "early", before the timelock expires, by handing over your partial signature to the HTLC Taproot, which I can later complete and present to the CoinPool in the next update round.
This is equivalent to `update_fail_htlc` in the current LN BOLT spec.

This allows operation of any SCRIPT, incidentally, without requiring that CoinPool software include a SCRIPT interpreter, only signature validation.
Any time an output absolutely needs a SCRIPT, we just drop the CoinPool onchain and let onchain handle the SCRIPT interpretation.

Regards,
ZmnSCPxj



  reply	other threads:[~2020-06-13  1:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11  8:53 [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy Antoine Riard
2020-06-11 17:21 ` Jeremy
2020-06-12 23:45   ` Antoine Riard
2020-06-12  8:39 ` ZmnSCPxj
2020-06-13  0:28   ` Antoine Riard
2020-06-13  0:45     ` ZmnSCPxj
2020-06-13  1:20       ` ZmnSCPxj [this message]
2020-06-16  5:23         ` ZmnSCPxj

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='7BPgx65Eh5HE5wLIqeG9G-bdsxxkDJJIzcyOJvS6_FIxXfA10sbFe5dfwQDNiEOExZ9Y72lHq88lKzcBRIFnYGFY5I2vwk6Dg7BcCMjmS2Y=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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