Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
Good morning Ruben,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, June 6, 2019 1:20 PM, Ruben Somsen 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 zmnsc...@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 “tr
Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
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 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
Re: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind signing server
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: [ots-dev] miniOTS: ots proofs that fit in a tweet
-- Forwarded message -
From: William Casarin
Date: Wed, Jun 5, 2019 at 9:13 AM
Subject: [ots-dev] miniOTS: ots proofs that fit in a tweet
To:
Hello OTS people,
Following from my previous post about cleartext OTS proof sharing[1],
I've been working on a new OTS format called miniOTS, which is
minimal/compressed format that allows attestations to fit in a tweet[2]
and for other space constrained contexts.
Just stripping out additional attestations in the standard format only
gets it down to just above ~280 bytes when base58 encoded, which is too
much for a tweet, so I decided to roll a custom format that is a bit
more efficient with attestation and op tags.
The goal was to have small enoughs proofs that I could reply to a tweet
with the stamp of the previous message, instead of relying on external
sites such as @otsproofbot
Current format (210 bytes, 288 bytes base58-encoded):
: 004f 7065 6e54 696d 6573 7461 6d70 7300 .OpenTimestamps.
0010: 0050 726f 6f66 00bf 89e2 e884 e892 9401 .Proof..
0020: 08cb 2d4a f572 8d44 a5b0 7c7b f1ff 78a9 ..-J.r.D..|{..x.
0030: 1818 7270 13f1 9bbd f4b0 344b 9e93 0c6b ..rp..4K...k
0040: 39f0 1020 34fe cad9 edef bab0 3420 e4ee 9.. 4...4 ..
0050: d3a7 c608 fff0 107c 31f7 da6c dbf2 3271 ...|1..l..2q
0060: 904c c5dd f58d eb08 f120 e4f7 3eaf a747 .L... ..>..G
0070: 324a f096 1aa0 928d e1c1 91bf 3c38 237d 2J..<8#}
0080: d412 c1c0 e94c d4ae 3f76 08f1 045c 4cb3 .L..?v...\L.
0090: a4f0 08f7 834d 4b14 68fd 41ff 0083 dfe3 .MK.h.A.
00a0: 0d2e f90c 8e2c 2b68 7474 7073 3a2f 2f62 .,+https://b
00b0: 6f62 2e62 7463 2e63 616c 656e 6461 722e ob.btc.calendar.
00c0: 6f70 656e 7469 6d65 7374 616d 7073 2e6f opentimestamps.o
00d0: 7267 rg
miniOTS format (133 bytes, 183 bytes base58-encoded):
: 6f74 7301 8a20 34fe cad9 edef bab0 3420 ots.. 4...4
0010: e4ee d3a7 c683 8a7c 31f7 da6c dbf2 3271 ...|1..l..2q
0020: 904c c5dd f58d eb83 8be4 f73e afa7 4732 .L.>..G2
0030: 4af0 961a a092 8de1 c191 bf3c 3823 7dd4 J..<8#}.
0040: 12c1 c0e9 4cd4 ae3f 7683 8b5c 4cb3 a48a L..?v..\L...
0050: f783 4d4b 1468 fd41 9a2b 6874 7470 733a ..MK.h.A.+https:
0060: 2f2f 626f 622e 6274 632e 6361 6c65 6e64 //bob.btc.calend
0070: 6172 2e6f 7065 6e74 696d 6573 7461 6d70 ar.opentimestamp
0080: 732e 6f72 67 s.org
base58 before:
12j6JNmon36jC1MMcpvC8nHqg5p8DAT2mmPQ5aLaBmAbk8naEVt8HFVohRqkuMXZF2Wo2n9kv
5ByeL17yUww4NHuFyCT6PXsGxRuEZ12Z33gsLbXL5FuFmnvMLd3tzf76n69J7qxLPxmoAgm1z
9NEMi2MRypDNKy1GypGN5NLwerzy1nU5g5dZxV6TZ5rBs4gYqnMNJn9VMkfKeDSZ9M8aoMWrL
ShokXUpnS1qrqkTvTwyKMx17fhKfcP9FyhNkb81t8dwYLtBsN4QuP9UAktMUvjEoBzHt
base58 after:
6gQjQUehytgUevKLRtAFYbC6UJX72LCDgVWxAUPsCt3tqEVTEQfmUB1T1Y1GTyY8sugiPY97K
gWRPPXYJmH3J5jqVtyNLrzdkySM6VAYDVckya9BxbUbFB8Gs4U3LHEauTmgCPEhGhiRdC3eFW
63SwfAvKB8Q8Ku8ZM9uASCwWZ8K2AoVabuAn
You can check it out here:
git clone https://git.sr.ht/~jb55/ots-tool
This is still a work in progress, I haven't built the miniOTS -> OTS
decoder yet.
make
./otsmini file.ots
Cheers,
Will
[1] id:878t1fzn0v@jb55.com
[2] https://twitter.com/jb55/status/1136260220521336832
--
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. I think you could generalise that slightly and make it fit in with the existing opcode naming by calling it something like "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of info you want to include in the hash, which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL" FWIW, I'm not really seeing any reason to complicate the spec to ensure the digest is precommitted as part of the opcode. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
