sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
rejon1 has quit []
AaronvanW has quit [Remote host closed the connection]
hmachado has joined #bitcoin-wizards
belcher has quit [Quit: Leaving]
marcoagner has quit [Ping timeout: 260 seconds]
jungly has joined #bitcoin-wizards
jb551 has quit [Remote host closed the connection]
<zmnscpxj>
not instagibbs, but the core of statechains is basically to use a multiparty update mechanism, like Decker-Wattenhofer, Poon-Dryja, or Decker-Russell-Osuntokun
<zmnscpxj>
the signing parties are trusted but auditable, and basically operate a custodial bank
<zmnscpxj>
the details can vary significantly, including the use of OP_CHECKMULTISIGNATURE, or 2p-ECDSA, or (eventually) MuSig on top of Schnorr
<zmnscpxj>
and it would still be approximately "statechain-like".
DeanGuss has quit [Remote host closed the connection]
<zmnscpxj>
Does that answer your question?
<bsm117532>
I understand all that. I think instagibbs is referring to a CMS-based statechain that I haven't seen described...but I don't doubt it's possible.
<zmnscpxj>
CMS=OP_CHECMULTISIGNATURE, from my understanding
<bsm117532>
yes
<zmnscpxj>
so what you are asking is...?
<bsm117532>
Is there a written description anywhere of a CMS-based statechain?
<bsm117532>
(thread confusion -- I didn't understand what instagibbs was saying was "incorrect" but anyway...)
<zmnscpxj>
none, but I did discuss some time ago with RubenSomsen: basically, you can use any multiparty update mechanism
<bsm117532>
Yes that seems clear
<zmnscpxj>
his original article focused on Decker-Russell-Osuntokun aka "eltoo", but it would work just as effectively with Decker-Wattenhofer
<zmnscpxj>
and you can use OP_CHECKMULTISIGNATURE just as effectively as a MuSig-based n-of-n or k-of-n VSSed key
<zmnscpxj>
with any of the update mechanisms
<zmnscpxj>
I think what instagibbs is saying as "incorrect" is the idea that the signing authority rotates keys
<zmnscpxj>
it can rotate keys "inside" the statechain
<zmnscpxj>
but the keys "outside" that will be on the blockchain remain the signing authority
<zmnscpxj>
which is a fixed set, because you are not doing any updates on the blockchain
<bsm117532>
I'm going to have to read and take some notes on these 3 update mechanisms. Do you know any talk or paper that discusses them side by side?
<zmnscpxj>
none, sorry
<zmnscpxj>
I just think about them all the time, so ---------------
<bsm117532>
It's ok, I can read 3 papers ;-)
<zmnscpxj>
You can rotate the signing authority by doing actions on the blockchain, i.e. spending the UTXO and then reassigning the value to a new pubkey/script/whatever
<zmnscpxj>
But in any case, possibly the confusion arises due to how the original statechains article was presented
<zmnscpxj>
Basically, the original statechains article suggested using the statechain to host one or more LN channels
<zmnscpxj>
The LN channel signatories can be changed offchain, inside the statechain
<zmnscpxj>
but the statechain signing authority remains the same
<zmnscpxj>
you can think of it as a Channel Factory where the signing authority is a custodian, instead of the actual owners of the LN channels
<zmnscpxj>
then you can manipulate channels inside the statechain
<zmnscpxj>
but only if the signing authority allows it
<bsm117532>
As I understand it, the statechain DOES rotate keys. With Schnorr it helps pass control of a UTXO signed by (p1+p2)*G where one of p1, p2 is held by the statechain. Tom's post rotates control of a UTXO signed by p1*p2*G, such that a new owner half-controls the UTXO, now signed by p3*p2_prime*G. (In Ruben's proposal, (p3+p2_prime)*G.
<bsm117532>
Is that understanding incorrect?
<bsm117532>
Where p1*p2*G = p3*p2_prime*G.
<bsm117532>
And the statechain deletes p2 to prevent collusion with p1.
<zmnscpxj>
from my understanding those rotations are "inside" the statechain
<bsm117532>
What do you mean "inside"? It requires cooperation of both 1 and 3.
<zmnscpxj>
The UTXO on the blockchain that anchors it will be released by a fixed signing set, the signing authority
<zmnscpxj>
this is a fixed set of signers
<zmnscpxj>
The statechain retains a Decker-Wattenhofer/Poon-Dryja/Decker-Russell-Osuntokun update/commitment/state transaction
<zmnscpxj>
which pays to (p1 + p2) * G
<zmnscpxj>
then when it rotates "inside" the statechain, it updates the update mechanism
<zmnscpxj>
it does not update the blockchain
<bsm117532>
Well that's the point of a statechain no? The set of signers isn't fixed and is transferrable. In the first state, p1 and p2 can collaborate to sign the UTXO. In the second, p3 and p2_prime can collaborate to sign it, and it's the SAME utxo since p1*p2*G = p3*p2_prime*G.
<zmnscpxj>
I do not think it works that way
<zmnscpxj>
Or possibly my understanding of RubenSomsen is wrong
* bsm117532
reads again.
<zmnscpxj>
because of p1*p2*G == p3*p2'*G, then p1 and p2 can always fork the statechain at genesis
<zmnscpxj>
so the entire point is to use an update mechanism to ensure that it is not possible to fork the statechain
<bsm117532>
In other words, old holders and current holder can validly spend the UTXO, this is correct, and this is where Eltoo comes in.
<zmnscpxj>
Yes
<zmnscpxj>
you actually change the eltoo state, i.e. the "inside" of the statechain
<zmnscpxj>
but the blockchain does not change its UTXO (because the point is to be off the chain)
<bsm117532>
Can you define "inside"? We have 3 parties here, all holding signed transactions. I don't know where "inside" is.
<zmnscpxj>
So on the blockchain, the *same* signer set still exists
<zmnscpxj>
An update mechanism is a mechanism to defer the assignment of a UTXO, re-assigning the value of the UTXO to 1 or more new UTXOs
<zmnscpxj>
do you agree?
<bsm117532>
Yes, that's why the statechain description requires key deletion. If p1 or p2 is deleted, then the signer set has changed.
<zmnscpxj>
This update mechanism has an "inside": i.e. the "latest state" that describes the current division of the fund
<zmnscpxj>
you can change this "inside" by performing an update ritual, i.e. in Poon-Dryja, you sign a new commitment, then exchange revocations for older commitments
<zmnscpxj>
then the mechanism ensures that old state can no longer be replayed
<zmnscpxj>
so the mechanism has an "inside", which is not *immediately* published "outside" on the blockchain
<zmnscpxj>
does that make better sense?
<bsm117532>
So "inside" is any set of offline valid broadcastable signed transactions?
<zmnscpxj>
yes
<zmnscpxj>
So suppose I want to reassign a UTXO "inside" the mechanism from A to B
<zmnscpxj>
Then I ask the signing authorities to update the update mechanism, invalidating the old state where the UTXO goes to A and creating a new state where the same UTXO goes to B
<zmnscpxj>
That is statechains
<zmnscpxj>
as I understood them
<zmnscpxj>
But A != B mathematically
<zmnscpxj>
Of course, this is not visible onchain
<zmnscpxj>
onchain, the funding UTXO that contains the sum total of all the UTXOs of the statechain
<zmnscpxj>
are still "owned" by the custodial signing authorities
<zmnscpxj>
Then, when we want to close the statechain we publish the last valid transaction onchain
<zmnscpxj>
which now exposes that the UTXO is now owned by B
<zmnscpxj>
as far as the blockchain (the "outside") it was owned by the SE, now it is owned by B.
<bsm117532>
But statechains are non-custodial...the original funding entity loses control when the statechain signs it over.
<zmnscpxj>
It never saw it as being owned by A, because that was a state that has been elided
<zmnscpxj>
......nope
<zmnscpxj>
statechains are custodial
<bsm117532>
Uh...no.
<zmnscpxj>
They have to be, because the only way for them to be noncustodial is to have an onchain action at each update
<zmnscpxj>
I have a box labelled "cookies", it does not contain cookies
<bsm117532>
The SE never has full control of the UTXO. In that sense it's non-custodial.
<bsm117532>
Neither do any of the outputs pay the SE.
aupiff has quit [Ping timeout: 240 seconds]
<zmnscpxj>
yes, but the owners of the coins inside the statechain do not have full control of the UTXO either. In that sense it is NOT non-custodial
<bsm117532>
Joint custody...
<zmnscpxj>
which does not make it non-custodial
<bsm117532>
Ok we're bickering over semantics... the SE cannot be hacked to steal funds, and is only responsible to co-sign transfers.
<zmnscpxj>
assumed to be so, yes
<zmnscpxj>
but the signing authority is still a fixed set
aupiff has joined #bitcoin-wizards
<zmnscpxj>
so if you assume the signing authority / SE is honest, then it is "noncustodial" in that sense
<bsm117532>
Well the signing authority is (p1 and p2) or (p3 and p2_prime) or (p4 and p2_primeprime) or ...
<zmnscpxj>
yes
<zmnscpxj>
since they are the same mathematically
<bsm117532>
We agree. Definition of "custody" aside ;-)
<zmnscpxj>
and as an optimization it could, you know, just not change any of the numbers
<sipa>
fwiw the us regulator gave some advisory a while ago (i don't remember which agency...) about what counts as custodial (and thus has stronger regulations attached) for cryptocurrenfies, and i believe (but IANAL) it would only treat a party as a custodian if that party could unilaterally spend the funds (however, a party which can prevent another from spending their coins on itself is not enough)
<zmnscpxj>
well, there is that
<zmnscpxj>
but "the power to destroy a thing, is the ultimate power over that thing"
<kanzure>
there are recent updates to the universal commercial code regarding property, possession, and ownership of digital assets for custodians -- at least for wyoming
<bsm117532>
Well, SE can prevent further transfer, but cannot destroy the coins.
<zmnscpxj>
"prevent further transfer" *is* destruction, or else 1BitcoinEater... is not destruction
<zmnscpxj>
but semantics
<bsm117532>
sipa: that's my understanding too. Custody, legally, means unilateral control. Multilateral control is a scenario the law is not prepared for.
<zmnscpxj>
assuming the SE works correctly, then it is noncustodial
<sipa>
zmnscpxj: haha
<zmnscpxj>
but it is helpful to remember that key rotation exists "inside" the statechain, and not outside it
<sipa>
according to that definition banks are not custodians either
<bsm117532>
sipa: They are not. But banking regulations are a different can of worms.
<zmnscpxj>
Yes, I can always bomb the bank if they do not release my money
<bsm117532>
zmnscpxj: your money was loaned out. They only have a 10% reserve requirement.
<zmnscpxj>
then I suppose I can reduce the bomb payload by 10%
DeanGuss has joined #bitcoin-wizards
<zmnscpxj>
this is a joke, by the way, and not any kind of incitement to actually bomb banks
<sipa>
a slowly exploding bomb is really the only way to reach MOON
<zmnscpxj>
sipa: agreed
<zmnscpxj>
But basically, that is the entirety of statechains: the changes in signers is implemented by being inside an update mechanism
mael-rolland[m] has quit [Ping timeout: 240 seconds]
<zmnscpxj>
and the signers of the update mechanism is a k-of-n of "Secure Elements"
michaelfolkson has joined #bitcoin-wizards
<zmnscpxj>
That we assume for some reason to work honestly, because we regularly open the packaging and inspect them with microscopes and etc
dl3br[m] has quit [Ping timeout: 256 seconds]
<zmnscpxj>
the signers of the update mechanism, i.e. the "SEs", live "outside" the update mechanism
<zmnscpxj>
since they are the ones who are operating the update mechanism.
<zmnscpxj>
the users of the statechain live inside the update mechanism
mael-rolland[m] has joined #bitcoin-wizards
<zmnscpxj>
it is similar to a federated blockchain in that respect, except the users can destroy the statechain at any time and recover the latest signed state of the statechain
<zmnscpxj>
But in theory, if I manage to pass my custom ASIC off as a "Secure Element" that actually duplicates a bunch of privkeys I have in my vault in the Sahara dessert
<zmnscpxj>
I could steal the funds in any statechains that use my custom ASIC as "Secure Element"
<zmnscpxj>
so you need a good way to audit the "Secure Element", which is what I think is difficult in practice
<zmnscpxj>
but yeah
<zmnscpxj>
stuff
<zmnscpxj>
(I do not own a vault in the Sahara dessert; it is stored in a quantum space beyond the edge of human-known science)
michaelfolkson has quit [Quit: Sleep mode]
rid3 has quit [Ping timeout: 272 seconds]
Chris_Stewart_5 has quit [Ping timeout: 246 seconds]
zmnscpxj has quit [Quit: Leaving]
michaelfolkson has joined #bitcoin-wizards
<bsm117532>
zmnscpxj: that SE stuff is just "deletion of the last state's privkey". It's a trust assumption. I'm not a fan of SE's but you could provide remote attestation to deletion of the key material, in principle.
aupiff has quit [Ping timeout: 258 seconds]
aupiff has joined #bitcoin-wizards
rid3 has joined #bitcoin-wizards
dl3br[m] has joined #bitcoin-wizards
Kiminuo has joined #bitcoin-wizards
aupiff has quit [Ping timeout: 264 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
DeanGuss has quit [Remote host closed the connection]
DeanGuss has joined #bitcoin-wizards
<RubenSomsen>
bsm117532: zmnscpxj: The novel thing that the post by Tom adds is a way to redistribute the shares of the shared secret that the UTXO is locked with. If the statechain entity throws away their old shares, then the secrets held by prior owners can no longer do any harm (e.g. when hacking occurs). A slight security improvement.
<RubenSomsen>
instagibbs was arguing that it's not worth the added complexity of needing 2p ecdsa, but when we have schnorr it'll definitely be worth it
<bsm117532>
RubenSomsen: maybe I misunderstood but I thought that was part of your Schnorr-based proposal too. In any case there's nothing unique about 2p-ECDSA there, it could be done with Schnorr too. (as I described above)
<RubenSomsen>
It wasn't, I hadn't thought of it.
Snowstormer has quit []
bitcoin-wizards0 has joined #bitcoin-wizards
bitcoin-wizards0 has quit [Client Quit]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 240 seconds]
them_ has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 256 seconds]
Guyver2_ is now known as Guyver2
michaelfolkson has quit [Quit: Sleep mode]
AaronvanW has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Client Quit]
michaelfolkson has joined #bitcoin-wizards
michaelfolkson has quit [Client Quit]
Dean_Guss has joined #bitcoin-wizards
DeanWeen has joined #bitcoin-wizards
DeanGuss has quit [Ping timeout: 240 seconds]
Dean_Guss has quit [Ping timeout: 240 seconds]
Guest79 has joined #bitcoin-wizards
aupiff has joined #bitcoin-wizards
Krellan_ has joined #bitcoin-wizards
Dean_Guss has joined #bitcoin-wizards
DeanGuss has joined #bitcoin-wizards
DeanWeen has quit [Ping timeout: 240 seconds]
Dean_Guss has quit [Ping timeout: 240 seconds]
aupiff has quit [Ping timeout: 240 seconds]
Guest79 has quit [Remote host closed the connection]
dllud has quit [Ping timeout: 240 seconds]
dllud has joined #bitcoin-wizards
luke-jr has quit [Ping timeout: 264 seconds]
roconnor has quit [Ping timeout: 260 seconds]
luke-jr has joined #bitcoin-wizards
DeanGuss has quit [Remote host closed the connection]
jungly has quit [Remote host closed the connection]
Krellan_ has quit [Ping timeout: 256 seconds]
aupiff has joined #bitcoin-wizards
captjakk has joined #bitcoin-wizards
Krellan_ has joined #bitcoin-wizards
DeanGuss has joined #bitcoin-wizards
Krellan_ has quit [Ping timeout: 256 seconds]
them_ has quit []
captjakk has quit [Remote host closed the connection]
slivera has joined #bitcoin-wizards
kutio has joined #bitcoin-wizards
aupiff has quit [Ping timeout: 240 seconds]
captjakk has joined #bitcoin-wizards
DeanGuss has quit [Ping timeout: 240 seconds]
jb55 has quit [Quit: jb55]
<bsm117532>
The keyshare computations involved in the transfer (Tom's ECDSA statechain) are occurring in Z_p. So the SE knows an equation in Z_p that gives both owner's private keys.
<bsm117532>
s1_inv * s2 = o2_inv*o1 such that s1 * o1 = P.
<bsm117532>
Given that the SE entity knows both s1 and s2, can this equation be efficiently solved? Or does this reduce to ECDLP?
<sipa>
which of those variables are points and which are scalars?
<bsm117532>
lower case are scalars. only P is an EC point (P = s1.o1.G)
<sipa>
ah, i was confused by your s1*o1=P
<bsm117532>
aaaahhhhh I'm so lazy...
<sipa>
so the attacker knows s1, s2, and tries to find out o1 and o2?
<bsm117532>
Yes.
<sipa>
and/or x (where P=x*G)
<bsm117532>
The attacker also knows P = o1.o2.G and P1 = o1.G and P2 = o2.G.
<sipa>
that's not useful
<bsm117532>
The attacker also knows P = s1.o1.G and P1 = o1.G and P2 = o2.G. <<< correction
<bsm117532>
yeah.
<sipa>
one equation, two unknowns.
<sipa>
or if you include x; two equations, three unknown
<bsm117532>
I mean, there should be sqrt(p) possible pairs no? So at the very least it reduces your search space by sqrt, and then you have to check them all by EC mult...
mdunnio has quit [Remote host closed the connection]
<sipa>
why only sqrt(p) ?
<sipa>
so call c = s2/s1, which is known to the attacker
mdunnio has joined #bitcoin-wizards
<sipa>
c = o1/o2, or o1 = c*o2
<sipa>
and x = s1*o1 = s1*c*o2... so instead of iterating over x you iterate over o2
<bsm117532>
Yep. I think you're right, no sqrt.
<bsm117532>
So then passing around products of private keys is secure? I would have thought this would push its security up to RSA-levels and require a larger prime...
mdunnio has quit [Ping timeout: 250 seconds]
<sipa>
in GF(p), every number can be written as a product of (anything)*(something)
<sipa>
factorization is not relevant, because every element is invertible
<bsm117532>
yep
<sipa>
or put otherwise: private_key*uniformly_random = uniformly_random
jonatack has quit [Ping timeout: 260 seconds]
jonatack has joined #bitcoin-wizards
Krellan_ has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Krellan_ has quit [Ping timeout: 240 seconds]
mdunnio has joined #bitcoin-wizards
mdunnio has quit [Ping timeout: 240 seconds]
AaronvanW has quit [Remote host closed the connection]
nuncanada2 has joined #bitcoin-wizards
nuncanada2 has quit [Read error: Connection reset by peer]
nuncanada2 has joined #bitcoin-wizards
nuncanada has quit [Read error: Connection reset by peer]
nuncanada2 has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 250 seconds]
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
mdunnio has joined #bitcoin-wizards
mdunnio has quit [Ping timeout: 240 seconds]
marcoagner has quit [Ping timeout: 250 seconds]
gleb has quit [Read error: Connection reset by peer]