* [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
@ 2019-06-04 11:28 Ruben Somsen
2019-06-06 0:09 ` ZmnSCPxj
0 siblings, 1 reply; 7+ messages in thread
From: Ruben Somsen @ 2019-06-04 11:28 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi everyone,
For those who are unfamiliar, Statechains enable the transfer UTXOs
off-chain with the help of a Statechain entity (trusted server(s))
without giving them full custodial control over your coins [0]. At
Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
[2] to make the entity unaware of what it's signing. I now think this
is the more interesting approach. The functionality can be described
fairly elegantly as follows.
Blind signing server with two functions users can call:
// Start new signature chain
(1) requestNewKey(userPubkey) => returns a new serverPubkey and
registers it to userPubkey
// Extend existing chain
(2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
returns blindSignature, registers the serverPubkey to nextUserPubkey
The resulting output is a public ECC chain (one blindSignature per
user, one chain per serverPubkey) of blindly signed messages,
requested by users (1, 2, 3, etc.):
userSignature1(blindedMessage1, userPubkey2) => blindSignature1
userSignature2(blindedMessage2, userPubkey3) => blindSignature2
etc.
Assuming the server is honest (more on this below), we can use it to
transfer over the signing rights of a private key without actually
changing the key itself.
The functionality is general and therefore suitable for more than just
Bitcoin, but let's walk through the primary envisioned use case where
we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
server is kept completely unaware that it's handling a BTC
transaction, since it's signing blindly:
- B uses function (1) with userPubkey = B to request serverPubkey A
- B then generates transitory key X, and creates a single MuSig key AX
(key X is called “transitory” because its private key will later be passed on)
- B prepares tx1: 1BTC to AX (he doesn't send it yet)
- B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
- B uses (2) with nextUserPubkey = B and blindedMessage = tx2
- B sends tx1 to the blockchain and waits for it to confirm
- B receives a key from C in order to prepare a payment
- B creates tx3: an eltoo tx (with higher priority) with 1BTC to C (off-chain)
- B uses (2) with nextUserPubkey = C and blindedMessage = tx3
- B passes the private key of X (the transitory key) on to C
- C takes blinded tx2 and tx3 from the public server output and
unblinds them with X
- C only accepts the payment if everything is in order [4]
Even if the server goes offline, C can still get the money by sending
tx3 to the blockchain.
A and B can collude to take the money from C, but since all instances
of userSignature and blindSignature are published openly, cheating is
publicly detectable (e.g. the server signed two messages from B
instead of one).
Trust can be distributed by turning the server into a multisig
threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
means security can be on par with federated sidechains [5], and is
similar to how ZmnSCPxj replaced the escrow key with a federation in
“Smart Contracts Unchained” [6].
Lastly, by utilizing adaptor signatures [7], the userSignature can be
tied to the blindSignature. In fact, this can be done for any number
of signatures, allowing multiple signing sessions to take place
atomically [8]. This denies the server the ability to selectively
publish one signature and not the other, allowing safe atomic swaps
via the server.
Essentially, anything that requires UTXO ownership can be achieved
off-chain via Blind Statechains. Coinjoin, Lightning channel
opening/adjusting/closing, Discreet Log Contract style bets [9],
cross-chain atomic swaps, etc. Since the blind signing server
functionality is non-specific to Bitcoin, it'll be useful for
non-cryptocurrency related use cases as well, but I have not given
this a lot of thought.
I also recently published a more high-level overview of Statechains
here, which may be of interest:
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
-- Ruben Somsen
[0] Statechains paper:
https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf
[1] Statechains Scaling Bitcoin ‘18: http://youtu.be/FI9cwksTrQs?t=47m36s
Transcript:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/statechains/
[2] Blind signatures, Jonas Nick:
http://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/blind-signatures-and-scriptless-scripts/
[3] eltoo: https://blockstream.com/eltoo.pdf
[4] Similar to client-side validation, Peter Todd:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/client-side-validation/
[5] Sidechains Appendix A, federated peg: https://blockstream.com/sidechains.pdf
[6] Smart Contracts Unchained ,ZmnSCPxj:
https://zmnscpxj.github.io/bitcoin/unchained.html
[7] Adaptor signatures, Andrew Poelstra:
http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/
[8] Adam Gibson (Waxwing) separately made a similar observation on his
blog: https://joinmarket.me/blog/blog/multiparty-s6/
[9] Discreet Log Contracts, Thaddeus Dryja: https://adiabat.github.io/dlc.pdf
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-04 11:28 [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server Ruben Somsen
@ 2019-06-06 0:09 ` ZmnSCPxj
2019-06-06 5:20 ` Ruben Somsen
0 siblings, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2019-06-06 0:09 UTC (permalink / raw)
To: Ruben Somsen, Bitcoin Protocol Discussion
Good morning Ruben,
> At
> Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> [2] to make the entity unaware of what it's signing. I now think this
> is the more interesting approach. The functionality can be described
> fairly elegantly as follows.
I agree.
I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
>
> Blind signing server with two functions users can call:
>
> // Start new signature chain
> (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> registers it to userPubkey
>
> // Extend existing chain
> (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> returns blindSignature, registers the serverPubkey to nextUserPubkey
>
> The resulting output is a public ECC chain (one blindSignature per
> user, one chain per serverPubkey) of blindly signed messages,
> requested by users (1, 2, 3, etc.):
>
> userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> etc.
>
> Assuming the server is honest (more on this below), we can use it to
> transfer over the signing rights of a private key without actually
> changing the key itself.
>
> The functionality is general and therefore suitable for more than just
> Bitcoin, but let's walk through the primary envisioned use case where
> we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> server is kept completely unaware that it's handling a BTC
> transaction, since it's signing blindly:
>
> - B uses function (1) with userPubkey = B to request serverPubkey A
> - B then generates transitory key X, and creates a single MuSig key AX
> (key X is called “transitory” because its private key will later be passed on)
>
> - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *strictly* required.
We can still make use of the Decker-Wattenhofer construction instead.
The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
> A and B can collude to take the money from C, but since all instances
> of userSignature and blindSignature are published openly, cheating is
> publicly detectable (e.g. the server signed two messages from B
> instead of one).
This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
>
> Trust can be distributed by turning the server into a multisig
> threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> means security can be on par with federated sidechains [5], and is
> similar to how ZmnSCPxj replaced the escrow key with a federation in
> “Smart Contracts Unchained” [6].
This makes me happy.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-06 0:09 ` ZmnSCPxj
@ 2019-06-06 5:20 ` Ruben Somsen
2019-06-06 6:31 ` ZmnSCPxj
0 siblings, 1 reply; 7+ messages in thread
From: Ruben Somsen @ 2019-06-06 5:20 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
Thank you for your comments.
>Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *strictly* required. We can still make use of the Decker-Wattenhofer construction instead.
Yes, an early draft (from before the eltoo paper) was using that
construction, but it seemed quite unwieldy. Timelocks have to be long,
nesting adds more transactions, channels expire faster with more use,
and tx fee handling is more complex. But you make a good point that if
SIGHASH_ANYPREVOUT turns out to be too controversial (or for
supporting older altcoins), this would be a potential fallback.
>This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
That is correct. The worst case for security still comes down to
having to trust the federation, but the transitory key, as well as the
blind signature scheme, does add an interesting layer of separation
that makes it essentially "non-custodial". The article I linked has
more on this.
Cheers,
Ruben
On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Ruben,
>
> > At
> > Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> > [2] to make the entity unaware of what it's signing. I now think this
> > is the more interesting approach. The functionality can be described
> > fairly elegantly as follows.
>
> I agree.
> I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
>
>
> >
> > Blind signing server with two functions users can call:
> >
> > // Start new signature chain
> > (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> > registers it to userPubkey
> >
> > // Extend existing chain
> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > returns blindSignature, registers the serverPubkey to nextUserPubkey
> >
> > The resulting output is a public ECC chain (one blindSignature per
> > user, one chain per serverPubkey) of blindly signed messages,
> > requested by users (1, 2, 3, etc.):
> >
> > userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> > userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> > etc.
> >
> > Assuming the server is honest (more on this below), we can use it to
> > transfer over the signing rights of a private key without actually
> > changing the key itself.
> >
> > The functionality is general and therefore suitable for more than just
> > Bitcoin, but let's walk through the primary envisioned use case where
> > we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> > server is kept completely unaware that it's handling a BTC
> > transaction, since it's signing blindly:
> >
> > - B uses function (1) with userPubkey = B to request serverPubkey A
> > - B then generates transitory key X, and creates a single MuSig key AX
> > (key X is called “transitory” because its private key will later be passed on)
> >
> > - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> > - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
>
> Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *strictly* required.
> We can still make use of the Decker-Wattenhofer construction instead.
>
> The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
> Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
> We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
>
> As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
>
> It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
>
> > A and B can collude to take the money from C, but since all instances
> > of userSignature and blindSignature are published openly, cheating is
> > publicly detectable (e.g. the server signed two messages from B
> > instead of one).
>
> This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
>
> >
> > Trust can be distributed by turning the server into a multisig
> > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> > means security can be on par with federated sidechains [5], and is
> > similar to how ZmnSCPxj replaced the escrow key with a federation in
> > “Smart Contracts Unchained” [6].
>
> This makes me happy.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-06 5:20 ` Ruben Somsen
@ 2019-06-06 6:31 ` ZmnSCPxj
2019-06-12 21:26 ` Ruben Somsen
0 siblings, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2019-06-06 6:31 UTC (permalink / raw)
To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
Good morning Ruben,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 6, 2019 1:20 PM, Ruben Somsen <rsomsen@gmail•com> wrote:
> Hi ZmnSCPxj,
>
> Thank you for your comments.
>
> > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required. We can still make use of the Decker-Wattenhofer construction instead.
>
> Yes, an early draft (from before the eltoo paper) was using that
> construction, but it seemed quite unwieldy. Timelocks have to be long,
> nesting adds more transactions, channels expire faster with more use,
> and tx fee handling is more complex. But you make a good point that if
> SIGHASH_ANYPREVOUT turns out to be too controversial (or for
> supporting older altcoins), this would be a potential fallback.
The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channel factory.
Factory operations would still require the signatures of all participants, but once a participant has released its signature, it cannot be sure whether its channels should be rooted on the previous factory state or the next (i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001974.html) ).
This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactions.
Alternately without that flag we can run channels rooted on both the previous and next factory states, which actually is similar to what we need to do for splice-in (so we could reuse that code, possibly).
>
> > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
>
> That is correct. The worst case for security still comes down to
> having to trust the federation, but the transitory key, as well as the
> blind signature scheme, does add an interesting layer of separation
> that makes it essentially "non-custodial". The article I linked has
> more on this.
Of note is that this is roughly the same as the common key in my own Smart Contracts Unchained.
If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
Going further on Smart Contracts Unchained, I observe that the below:
> // Start new signature chain
> (1) requestNewKey(userPubkey) => returns a new serverPubkey and registers it to userPubkey
> // Extend existing chain
> (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) => returns blindSignature, registers the serverPubkey to nextUserPubkey
Can be generalized, such that instead of pubKeys and their signatures, we have validation programs and their witnesses.
For example, instead of userPubkey and nextUserPubkey we have a userScript and nextUserScript, with userSignature replaced by a userWitness.
This would be nearer to my own Smart Contracts Unchained, though without committing to the smart contract onchain, only offchain in the server.
>
> Cheers,
> Ruben
>
> On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj ZmnSCPxj@protonmail•com wrote:
>
> > Good morning Ruben,
> >
> > > At
> > > Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> > > [2] to make the entity unaware of what it's signing. I now think this
> > > is the more interesting approach. The functionality can be described
> > > fairly elegantly as follows.
> >
> > I agree.
> > I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
> >
> > > Blind signing server with two functions users can call:
> > > // Start new signature chain
> > > (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> > > registers it to userPubkey
> > > // Extend existing chain
> > > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > > returns blindSignature, registers the serverPubkey to nextUserPubkey
> > > The resulting output is a public ECC chain (one blindSignature per
> > > user, one chain per serverPubkey) of blindly signed messages,
> > > requested by users (1, 2, 3, etc.):
> > > userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> > > userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> > > etc.
> > > Assuming the server is honest (more on this below), we can use it to
> > > transfer over the signing rights of a private key without actually
> > > changing the key itself.
> > > The functionality is general and therefore suitable for more than just
> > > Bitcoin, but let's walk through the primary envisioned use case where
> > > we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> > > server is kept completely unaware that it's handling a BTC
> > > transaction, since it's signing blindly:
> > >
> > > - B uses function (1) with userPubkey = B to request serverPubkey A
> > >
> > > - B then generates transitory key X, and creates a single MuSig key AX
> > > (key X is called “transitory” because its private key will later be passed on)
> > >
> > > - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> > >
> > > - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
> > >
> >
> > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required.
> > We can still make use of the Decker-Wattenhofer construction instead.
> > The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
> > Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
> > We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
> > As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
> > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
> >
> > > A and B can collude to take the money from C, but since all instances
> > > of userSignature and blindSignature are published openly, cheating is
> > > publicly detectable (e.g. the server signed two messages from B
> > > instead of one).
> > >
> >
> > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
> >
> > > Trust can be distributed by turning the server into a multisig
> > > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> > > means security can be on par with federated sidechains [5], and is
> > > similar to how ZmnSCPxj replaced the escrow key with a federation in
> > > “Smart Contracts Unchained” [6].
> > >
> >
> > This makes me happy.
> > Regards,
> > ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-06 6:31 ` ZmnSCPxj
@ 2019-06-12 21:26 ` Ruben Somsen
2019-06-13 1:22 ` ZmnSCPxj
0 siblings, 1 reply; 7+ messages in thread
From: Ruben Somsen @ 2019-06-12 21:26 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
Thanks for the reply. Sorry to keep you waiting, Coredev and Breaking
Bitcoin have been keeping me busy.
Transcript from Coredev (thanks Bryan):
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/
Blind Statechains at Breaking Bitcoin:
https://www.youtube.com/watch?v=DqhxPWsJFZE&t=4h59m4s
>an early draft
I meant an early draft of Statechains, sorry if that was confusing.
But yes, it's essentially no different from channel factories without
eltoo.
>If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
That is a good point. One thing I have not yet fully analysed are the
privacy considerations. Perhaps we don't want to reveal X on-chain.
>This would be nearer to my own Smart Contracts Unchained
Adding scripting is not my preferred approach. The beauty of the
system is that the server doesn't evaluate any scripts whatsoever.
That being said, Smart Contracts Unchained (SCU) can be inserted quite
elegantly as a separate smart contracting layer.
The observation is that anything that can be done with a UTXO
on-chain, can also be done off-chain via Statechains, including SCU.
If SCU is a single (N-of-N or (1-of-N + escrow)) key, you can simply
use this as the userKey (as well as inside the off-chain eltoo tx).
It's pretty interesting how smart contracting can be added like this.
Cool stuff, ZmnSCPxj. I'll definitely be thinking about this more.
Cheers,
Ruben
On Thu, Jun 6, 2019 at 8:32 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Ruben,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, June 6, 2019 1:20 PM, Ruben Somsen <rsomsen@gmail•com> wrote:
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your comments.
> >
> > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required. We can still make use of the Decker-Wattenhofer construction instead.
> >
> > Yes, an early draft (from before the eltoo paper) was using that
> > construction, but it seemed quite unwieldy. Timelocks have to be long,
> > nesting adds more transactions, channels expire faster with more use,
> > and tx fee handling is more complex. But you make a good point that if
> > SIGHASH_ANYPREVOUT turns out to be too controversial (or for
> > supporting older altcoins), this would be a potential fallback.
>
> The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channel factory.
> Factory operations would still require the signatures of all participants, but once a participant has released its signature, it cannot be sure whether its channels should be rooted on the previous factory state or the next (i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001974.html) ).
> This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactions.
> Alternately without that flag we can run channels rooted on both the previous and next factory states, which actually is similar to what we need to do for splice-in (so we could reuse that code, possibly).
>
> >
> > > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
> >
> > That is correct. The worst case for security still comes down to
> > having to trust the federation, but the transitory key, as well as the
> > blind signature scheme, does add an interesting layer of separation
> > that makes it essentially "non-custodial". The article I linked has
> > more on this.
>
> Of note is that this is roughly the same as the common key in my own Smart Contracts Unchained.
>
> If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
>
> Going further on Smart Contracts Unchained, I observe that the below:
>
> > // Start new signature chain
> > (1) requestNewKey(userPubkey) => returns a new serverPubkey and registers it to userPubkey
> > // Extend existing chain
> > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) => returns blindSignature, registers the serverPubkey to nextUserPubkey
>
> Can be generalized, such that instead of pubKeys and their signatures, we have validation programs and their witnesses.
>
> For example, instead of userPubkey and nextUserPubkey we have a userScript and nextUserScript, with userSignature replaced by a userWitness.
>
> This would be nearer to my own Smart Contracts Unchained, though without committing to the smart contract onchain, only offchain in the server.
>
>
>
> >
> > Cheers,
> > Ruben
> >
> > On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj ZmnSCPxj@protonmail•com wrote:
> >
> > > Good morning Ruben,
> > >
> > > > At
> > > > Scaling Bitcoin ‘18 [1] I briefly mentioned utilizing blind signatures
> > > > [2] to make the entity unaware of what it's signing. I now think this
> > > > is the more interesting approach. The functionality can be described
> > > > fairly elegantly as follows.
> > >
> > > I agree.
> > > I had no interest in Statechains at all before, but now that you have blind signing servers, this is significantly more interesting.
> > >
> > > > Blind signing server with two functions users can call:
> > > > // Start new signature chain
> > > > (1) requestNewKey(userPubkey) => returns a new serverPubkey and
> > > > registers it to userPubkey
> > > > // Extend existing chain
> > > > (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =>
> > > > returns blindSignature, registers the serverPubkey to nextUserPubkey
> > > > The resulting output is a public ECC chain (one blindSignature per
> > > > user, one chain per serverPubkey) of blindly signed messages,
> > > > requested by users (1, 2, 3, etc.):
> > > > userSignature1(blindedMessage1, userPubkey2) => blindSignature1
> > > > userSignature2(blindedMessage2, userPubkey3) => blindSignature2
> > > > etc.
> > > > Assuming the server is honest (more on this below), we can use it to
> > > > transfer over the signing rights of a private key without actually
> > > > changing the key itself.
> > > > The functionality is general and therefore suitable for more than just
> > > > Bitcoin, but let's walk through the primary envisioned use case where
> > > > we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
> > > > server is kept completely unaware that it's handling a BTC
> > > > transaction, since it's signing blindly:
> > > >
> > > > - B uses function (1) with userPubkey = B to request serverPubkey A
> > > >
> > > > - B then generates transitory key X, and creates a single MuSig key AX
> > > > (key X is called “transitory” because its private key will later be passed on)
> > > >
> > > > - B prepares tx1: 1BTC to AX (he doesn't send it yet)
> > > >
> > > > - B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain)
> > > >
> > >
> > > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not strictly required.
> > > We can still make use of the Decker-Wattenhofer construction instead.
> > > The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` update systems.
> > > Number of maximum updates is limited by the starting `nSequence`, however if we put an update system inside an update system, we can "reset" the `nSequence` of the inner update system by updating the outer update system.
> > > We can chain this concept further and add more update systems nested inside update systems to gain more leverage from the maximum relative wait time.
> > > As we expect fewer updates are needed for statechains than e.g. actual Lightning channels (your given CoinSwap protocol is "only" two updates, for instance) this is usually a good tradeoff,
> > > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is too controversial to get into Bitcoin, provided Schnorr (definitely uncontroversial) does get into Bitcoin.
> > >
> > > > A and B can collude to take the money from C, but since all instances
> > > > of userSignature and blindSignature are published openly, cheating is
> > > > publicly detectable (e.g. the server signed two messages from B
> > > > instead of one).
> > > >
> > >
> > > This still admits the possibility of an exit scam once a few "big enough" swaps are in position to be stolen, trading off earned reputation for cold-stored cash.
> > >
> > > > Trust can be distributed by turning the server into a multisig
> > > > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
> > > > means security can be on par with federated sidechains [5], and is
> > > > similar to how ZmnSCPxj replaced the escrow key with a federation in
> > > > “Smart Contracts Unchained” [6].
> > > >
> > >
> > > This makes me happy.
> > > Regards,
> > > ZmnSCPxj
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-12 21:26 ` Ruben Somsen
@ 2019-06-13 1:22 ` ZmnSCPxj
2019-06-14 7:18 ` Ruben Somsen
0 siblings, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2019-06-13 1:22 UTC (permalink / raw)
To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion
Good morning Ruben,
> > an early draft
>
> I meant an early draft of Statechains, sorry if that was confusing.
> But yes, it's essentially no different from channel factories without
> eltoo.
Sorry, I am referring to current issues with channel factories, which were not addressed in the original channel factories paper.
Basically, the "Stale Factory" and "Broken Factory" problems.
Broken factory seems unsolvable.
Stale factory is fixable if the channels within the factory use `SIGHASH_NOINPUT` (assuming it gets into Bitcoin) for all unilateral paths (use `SIGHASH_ALL` for cooperative paths).
>
> > If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
>
> That is a good point. One thing I have not yet fully analysed are the
> privacy considerations. Perhaps we don't want to reveal X on-chain.
On reflection, probably best not to.
It requires a script that reveals the pubkeys.
And it now becomes possible for the server to monitor the blockchain for revelation of server pubkey in a spend path.
This will let the server know, after-the-fact, that it was signing blockchain transactions.
This might not let it preemptively censor or otherwise disrupt, but it *could* sell the private fact that a statechain was used.
Combining it via MuSig is probably best, as the server is now unable to recognize even the pubkey (assuming it never is informed `X`).
>
> > This would be nearer to my own Smart Contracts Unchained
>
> Adding scripting is not my preferred approach. The beauty of the
> system is that the server doesn't evaluate any scripts whatsoever.
On reflection, this is probably best.
As the server is blinded, it cannot determine anything about the message being signed.
On the other cognition sub-agent, however, a simple scripting that allows "if somebody provides x of H(x) plus signature A, sign a blinded message M1, else if after 2:30PM PST on Jun 24 2019 if somebody provides signature of B, sign a blinded message M2" could still potentially be useful, and might allow "programmable escrow" like I imagine Smart Contracts Unchained could allow.
>
> That being said, Smart Contracts Unchained (SCU) can be inserted quite
> elegantly as a separate smart contracting layer.
>
> The observation is that anything that can be done with a UTXO
> on-chain, can also be done off-chain via Statechains, including SCU.
The Real (TM) observation is that anything that can be done with a UTXO onchain, can also be done offchain via any updateable offchain cryptocurrency system, whether Statechains, Spillman, Decker-Wattenhofer, Poon-Dryja, or Decker-Russell-Osuntokun.
(I should probably look up the authors of the Statechains paper to make my naming convention consistent)
One might observe that any updateable offchain cryptocurrency system worth its salt would have some way of unilaterally dropping transactions onchain.
Those transactions would create new UTXOs that can be spent by further transactions.
By presenting those "further transactions" to the offchain system, we can provide an argument that the offchain system can just "append" those "further transactions" to the existing unilateral-case transactions, then cut-through the further transactions on its next update (i.e. delete the current UTXOs spent and insert the new UTXOs introduced by the "further transactions").
(In the case of Statechains, you would present this argument to the signers of the latest `userPubKey`, not to the server, who is unaware of the semantics of what it is signing)
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
2019-06-13 1:22 ` ZmnSCPxj
@ 2019-06-14 7:18 ` Ruben Somsen
0 siblings, 0 replies; 7+ messages in thread
From: Ruben Somsen @ 2019-06-14 7:18 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi ZmnSCPxj,
>Basically, the "Stale Factory" and "Broken Factory" problems.
I see, I'll have to read up on those.
>Combining it via MuSig is probably best, as the server is now unable to recognize even the pubkey (assuming it never is informed `X`).
Yes, that's the current thinking. See also:
https://twitter.com/SomsenRuben/status/1138199578996555784 (sorry no
time to make a gist)
>As the server is blinded, it cannot determine anything about the message being signed.
Yes, you could build a non-blind variant with scripting, but that
would be quite different.
>a simple scripting that allows "if somebody provides x of H(x) plus signature A, sign a blinded message M1, else if after 2:30PM PST on Jun 24 2019 if somebody provides signature of B, sign a blinded message M2" could still potentially be useful
I believe adaptor signatures are enough to replace hashing. A time
lock could potentially be added with some very basic scripting, but my
feeling is still that this is better avoided. We're essentially
relying on the Bitcoin blockchain for that, because the off-chain
transactions can be encumbered by any script you like.
>anything that can be done with a UTXO onchain, can also be done offchain via any updateable offchain cryptocurrency system
You're right that I didn't properly point to the key difference, which
is transfer of UTXO ownership. Other off-chain systems don't allow you
to go from e.g. 2-of-2 to 3-of-3, but of course we're adding a
federation in order to make this happen, so it's not exactly a fair
comparison.
>(I should probably look up the authors of the Statechains paper to make my naming convention consistent)
That would be "Somsen". I am the sole author.
>By presenting those "further transactions" to the offchain system, we can provide an argument that the offchain system can just "append" those "further transactions" to the existing unilateral-case transactions, then cut-through the further transactions on its next update
That's an interesting way of looking at it. This is currently achieved
in Statechains by making the top-level on the Statechain N-of-N, so
all participants of the "further transactions" have to agree in order
to achieve full cut-through on the Statechain. In practice this would
mean that the final signature requested from the server is a
"cooperative close".
Cheers,
Ruben
On Thu, Jun 13, 2019 at 3:22 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Ruben,
> > > an early draft
> >
> > I meant an early draft of Statechains, sorry if that was confusing.
> > But yes, it's essentially no different from channel factories without
> > eltoo.
>
> Sorry, I am referring to current issues with channel factories, which were not addressed in the original channel factories paper.
> Basically, the "Stale Factory" and "Broken Factory" problems.
> Broken factory seems unsolvable.
> Stale factory is fixable if the channels within the factory use `SIGHASH_NOINPUT` (assuming it gets into Bitcoin) for all unilateral paths (use `SIGHASH_ALL` for cooperative paths).
>
> >
> > > If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems this transitory/common key can be used for the chaperone.
> >
> > That is a good point. One thing I have not yet fully analysed are the
> > privacy considerations. Perhaps we don't want to reveal X on-chain.
>
> On reflection, probably best not to.
> It requires a script that reveals the pubkeys.
> And it now becomes possible for the server to monitor the blockchain for revelation of server pubkey in a spend path.
> This will let the server know, after-the-fact, that it was signing blockchain transactions.
> This might not let it preemptively censor or otherwise disrupt, but it *could* sell the private fact that a statechain was used.
> Combining it via MuSig is probably best, as the server is now unable to recognize even the pubkey (assuming it never is informed `X`).
>
> >
> > > This would be nearer to my own Smart Contracts Unchained
> >
> > Adding scripting is not my preferred approach. The beauty of the
> > system is that the server doesn't evaluate any scripts whatsoever.
>
> On reflection, this is probably best.
> As the server is blinded, it cannot determine anything about the message being signed.
>
> On the other cognition sub-agent, however, a simple scripting that allows "if somebody provides x of H(x) plus signature A, sign a blinded message M1, else if after 2:30PM PST on Jun 24 2019 if somebody provides signature of B, sign a blinded message M2" could still potentially be useful, and might allow "programmable escrow" like I imagine Smart Contracts Unchained could allow.
>
> >
> > That being said, Smart Contracts Unchained (SCU) can be inserted quite
> > elegantly as a separate smart contracting layer.
> >
> > The observation is that anything that can be done with a UTXO
> > on-chain, can also be done off-chain via Statechains, including SCU.
>
> The Real (TM) observation is that anything that can be done with a UTXO onchain, can also be done offchain via any updateable offchain cryptocurrency system, whether Statechains, Spillman, Decker-Wattenhofer, Poon-Dryja, or Decker-Russell-Osuntokun.
> (I should probably look up the authors of the Statechains paper to make my naming convention consistent)
>
> One might observe that any updateable offchain cryptocurrency system worth its salt would have some way of unilaterally dropping transactions onchain.
> Those transactions would create new UTXOs that can be spent by further transactions.
> By presenting those "further transactions" to the offchain system, we can provide an argument that the offchain system can just "append" those "further transactions" to the existing unilateral-case transactions, then cut-through the further transactions on its next update (i.e. delete the current UTXOs spent and insert the new UTXOs introduced by the "further transactions").
> (In the case of Statechains, you would present this argument to the signers of the latest `userPubKey`, not to the server, who is unaware of the semantics of what it is signing)
>
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-06-14 7:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-04 11:28 [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server Ruben Somsen
2019-06-06 0:09 ` ZmnSCPxj
2019-06-06 5:20 ` Ruben Somsen
2019-06-06 6:31 ` ZmnSCPxj
2019-06-12 21:26 ` Ruben Somsen
2019-06-13 1:22 ` ZmnSCPxj
2019-06-14 7:18 ` Ruben Somsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox