Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
Good morning Ryan, > I appreciate your questions, ZmnSCPxj. > > I will answer your second question first: Mainchain nodes do not ever > validate sidechain blocks. Sidechain nodes watch Bitcoin for invalid > withdrawals, and publish signed attestations to a public broadcast network > (such as Nostr) that a transaction is making an invalid withdrawal. These > sidechain nodes are the so-called sentinels. Let me reiterate my question: Suppose I trust some sidechain node that is publishing such an attestation. Then the sidechain node is hacked or otherwise wishes to disrupt the network for its own purposes. And it attests that a valid sidechain withdrawal is actually invalid. What happens then? To the point, suppose that the attestation private key is somehow leaked or determined by a third party that has incentive to disrupt the mainchain network. And it seems to me that this can be used to force some number of nodes to fork themselves off the network. This is dangerous as nodes may be monitoring the blockchain for time-sensitive events, such as Lightning Network theft attempts. Making "fork off bad miners!" a regular occurrence seems dangerous to me. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Private Collaborative Custody with FROST
Hey Rijndael, Here are some rough ideas for a draft scheme that I think will help explain this better. We begin by taking a single public nonce `D` from the collaborative signing server to form a nonce pair for FROST `(D, 0)`. This is then used to build the aggregate FROST nonce `R` which the signer set `S` is going to sign under: ``` R_i = D_i * (E_i)^ρ_i R = Product[R_i, i in S] ``` This aggregate FROST nonce is now blinded by the contributions from other signers (collaborative custodian doesn't know the other participant's nonces) Now with our FROST public key `X`, this aggregate nonce `R`, and a message `m` corresponding to our planned Bitcoin transaction input, we calculate the corresponding challenge `c` we need signed. ``` c = H(R || X || m) ``` Like regular blind schnorr, we also want to blind this challenge so that the signing server cannot recognize it onchain. The challenge can be blinded with a factor that includes the necessary Lagrange coefficient so that the partial signature correctly combines with the other FROST signatures from the signing quorum. Using their participant index `i` and the set of signing parties `S` ``` c' = λ_i_S * c ``` Note: if this `λ_i_S` is the sole challenge blinding factor, it is important that we give the collaborative custodian a non-trivial (random) participant index such that they cannot lookup onchain challenges multiplied by common Lagrange coefficients to match the challenge they signed. Now we have formed the challenge, we get the server to sign under the regular Schnorr singing equation using their FROST secret share `s_i` and nonce secret `d_i`: ``` z_i = d_i + (e_i * ρ_i) + λ_i * s_i * c # FROST signing equation = d_i + (0 * ρ_i) + s_i * c' # Since we're signing for binonce commitment (D, 0) = d_i + s_i * c' ``` Once we have this partial signature, we get the other `t-1` participants to undertake FROST signing. We take the collaborative custodian's signature and combine it with the other partial signatures to form a complete Schnorr signature for the message valid under the group's FROST key. Again, security needs a serious assessment. Especially because we're dropping the binding factor in the collaborative custodian's nonce. It's likely crucial that collaborative signing sessions are not done in parallel and transaction inputs are signed one at a time. Hope that explains the ideas for blinding and FROST compatibility better! Nick On Tue, Aug 29, 2023 at 1:52 PM rot13maxi wrote: > Good morning Nick, > > Love the direction of this. > > > We can achieve this compatibility by having the server sign under a > single nonce (not a binding nonce-pair like usual FROST), which is later > blinded by the nonce contributions from other signers. > > Can you say more about this? It sounds like the blinding is happening > post-signing? Or is it happening during the normal nonce commitment trading? > > Rijndael > > On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org > > > wrote: > > Hello all, > > Some thoughts on private collaborative custody services for Bitcoin. > > With multiparty computation multisignatures like FROST [0], it is possible > to build a collaborative custodian service that is extremely private for > users. > > Today's collaborative custodians can see your entire wallet history even > if you never require them to help sign a transaction, and they have full > liberty to censor any signature requests they deem inappropriate or are > coerced into censoring. > > With FROST, a private collaborative custodian can hold a key to a multisig > while remaining unaware of the public key (and wallet) which they help > control. By hiding this public key, we solve the issue of existing > collaborative custodians who learn of all wallet transactions even if you > never use them. > > Further, in the scenario that we do call upon a private collaborative > custodian to help sign a transaction, this transaction could be signed > **blindly**. Being blind to the transaction request itself and unknowing of > past onchain behavior, these custodians have no practical information to > enact censorship requests or non-cooperation. A stark contrast to today's > non-private collaborative custodians who could very easily be coerced into > not collaborating with users. > > > Enrolling a Private Collaborative Custodian > > Each signer in a FROST multisig controls a point belonging to a joint > polynomial at some participant index. > > Participants in an existing multisig can collaborate in an enrollment > protocol (Section 4.1.3 of [1], [2]) to securely generate a new point on > this shared polynomial and verifiably communicate it to a new participant, > in this case a collaborative custodian. > > The newly enrolled custodian should end by sharing their own *public* > point so that all other parties can verify it does in-fact lie on the image > of the joint polynomial at their index (i.e. belong to the FROST key). (
Re: [bitcoin-dev] Blinded 2-party Musig2
An update on progress on the development of the blinded two-party Schnorr scheme for statechains. As stated previously, we believe that one-more-signature and Wagner attacks are mitigated by the client committing the values of the blinding nonce used (labeled f) and the value of R2 used in a signing session to the server before the server responds with their value of R1. Then each time the generated signature is verified (in our application this is a new statecoin owner), the verifier retrieves the commitments and blinded challenge value from the server (c, SHA256(f) and SHA256(R2)) and f and R2 from the co-signer, and verifies that the blinded challenge value c = f + SHA256(X, R1 + R2 + f.X, m) and the commitments match f,R2. This ensures the signer cannot have chosen the values of f and R2 after the value of R1 is randomly generated by the server. This scheme has been implemented in a forked version of the secp256k1-zkp library: https://github.com/ssantos21/secp256k1-zkp where a new function has been added secp256k1_blinded_musig_nonce_process ( https://github.com/ssantos21/secp256k1-zkp/blob/ed08ad7603f211fdf39b5f6db9d7e99cf048a56c/src/modules/musig/session_impl.h#L580 ) which is required for the client generation of the blinded challenge value. One issue that came up and had to be solved was ensuring the R (curve point) is even (in MuSig2 the secret nonce is negated if R is odd) with the point f.X added (and f committed to). We will add a complete explanation of this to the updated spec. The scheme is implemented in a blind server: https://github.com/ssantos21/blinded-musig-sgx-server And client: https://github.com/ssantos21/blinded-musig2-client Any comments or questions appreciated. On Mon, Aug 7, 2023 at 1:55 AM Tom Trevethan wrote: > A follow up to this, I have updated the blinded statechain protocol > description to include the mitigation to the Wagner attack by requiring the > server to send R1 values only after commitments made to the server of the > R2 values used by the user, and that all the previous computed c values are > verified by each new statecoin owner. > https://github.com/commerceblock/mercury/blob/master/layer/protocol.md > > Essentially, the attack is possible because the server cannot verify that > the blinded challenge (c) value it has been sent by the user has been > computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN > be verified by each new owner of a statecoin for all the previous > signatures. > > Each time an owner cooperates with the server to generate a signature on a > backup tx, the server will require that the owner send a commitment to > their R2 value: e.g. SHA256(R2). The server will store this value before > responding with it's R1 value. This way, the owner cannot choose the value > of R2 (and hence c). > > When the statecoin is received by a new owner, they will receive ALL > previous signed backup txs for that coin from the sender, and all the > corresponding R2 values used for each signature. They will then ask the > server (for each previous signature), the commitments SHA256(R2) and the > corresponding server generated R1 value and c value used. The new owner > will then verify that each backup tx is valid, and that each c value was > computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals > SHA256(R2). This ensures that a previous owner could not have generated > more valid signatures than the server has partially signed. > > On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan > wrote: > >> >> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick wrote: >> >>> No, proof of knowledge of the r values used to generate each R does not >>> prevent >>> Wagner's attack. I wrote >>> >>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that >>> >c[0] + ... + c[K-1] = c[K]. >>> >>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1] >>> and >>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't >>> make >>> sense if he didn't. >>> >> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Announcing B'SST: Bitcoin-like Script Symbolic Tracer
Hello list, I have released B'SST: Bitcoin-like Script Symbolic Tracer It can be found at https://github.com/dgpv/bsst B'SST analyses Bitcoin and Elements scripts by symbolically executing all possible execution paths, and tracking constraints that opcodes impose on values they operate on. It then outputs a report based on this analysis. It can do analysis with the help of Z3 theorem prover [1]. With Z3 enabled, analysis will take more time, but all the features that depend on SMT solver can be employed. By default, the analysis does not use Z3, so it is fast, but not nearly as thorough. Regarding the analysis performed, there are limitations and caveats. Please refer to README.md in the repo at [0] for details. I am aware of only one project that has aimed to do this type of analysis before - the "SCRIPT Analyser" [2], but it had no updates in its github repo for 5 years. Compared to [2], B'SST is more thorough in its effort to match the reference interpreter closely, and it also uses SMT solver, while [2] has used prolog for constraints solving. Elements script interpreter [3], which is an extension of Bitcoin script interpreter, was used as reference. As an illustration of what information the analysis can provide, for this rather contrieved example script: 7 ADD DUP 3 5 WITHIN IF 0x00 ELSE 0 ENDIF EQUALVERIFY 2DUP EQUALVERIFY SUB 0 EQUAL The analysis report will show that: - The first branch of IF will always fail - Witness 0 must be -7 for script to succeed, - Possible values for witness 1 and 2 are -1 - Result of last EQUAL is always true (because this condition was already checked by second EQUALVERIFY) For more extensive example, please look at the report [5] for a rather complex Elements script [4] Plugins to implement custom opcodes are supported, please see "Custom opcodes" section in README.md B'SST is released under Prosperity Public License 3.0.0, which is a "Free for non-commercial use" license, with a trial period for commercial use and exemptions for educational institutions, public research organizations, etc. Please refer to LICENSE.md file in the repo at [0] for details. [0] https://github.com/dgpv/bsst [1] https://github.com/Z3Prover/z3 [2] https://github.com/RKlompUU/SCRIPTAnalyser [3] https://github.com/ElementsProject/elements/blob/master/src/script/interpreter.cpp [4] https://github.com/fuji-money/tapscripts/blob/with-annotations-for-bsst/beta/mint-mint.tapscript [5] https://gist.github.com/dgpv/b57ecf4d9e3d0bfdcc2eb9147c9b9abf ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Sentinel Chains: A Novel Two-Way Peg
Good morning Ryan, et al., My long-ago interest in sidechains was the hope that they would be a scaling solution. However, at some point I thought "the problem is that blockchains cannot scale, sidechains means MORE blockchains that cannot scale, what was I thinking???" This is why I turned my attention to Lightning, which is a non-blockchain mechanism for scaling blockchains. The only other reason for sidechains is to develop new features. However, any actually useful features should at some point get onto the "real" Bitcoin. In that case, a sidechain would "only" be useful as a proof-of-concept. And in that case, a federated sidechain among people who can slap the back of the heads of each other in case of bad behavior would be sufficient to develop and prototype a feature. -- In any case, if you want to consider a "user-activated" sidechain feature, you may be interested in an old idea, "mainstake", by some obscure random with an unpronouncable name: https://zmnscpxj.github.io/sidechain/mainstake/index.html Here are some differences compared to e.g. drivechains: * Mainchain miners cannot select the builder of the next sidechain block, without increasing their required work (possibly dropping them below profitability). More specifically: * If they want to select a minority (< 50%) sidechain block builder, then their difficulty increases by at least one additional bit. The number of bits added is basically the negative log2 of the share of the sidechain block builder they want to select. * The intent is to make it very much more unpalatable for a sidechain block builder to pay fees to the mainchain miner to get its version of the sidechain block confirmed. A minority sidechain block builder that wants to lie to the mainchain about a withdrawal will find that the fees necessary to convince a miner to select them are much higher than the total fees of a block. This better isolates sidechain conflicts away from mainchain miners. * Miners can censor the addition of new mainstakes or the renewal of existing mainstakes. However, the same argument of censorship-resistance should still apply here (< 51% cannot reliably censor, and >=51% *can* censor but that creates an increasing feerate for censored transactions that encourages other potential miners to evict the censor). * In particular, miners cannot censor sidechain blocks easily (part of the isolation above), though they *can* censor new mainstakers that are attempting to evict mainstakers that are hostile to a sidechain. There are still some similarities. Essentially, all sidechain funds are custodied by a set of anonymous people. One can consider as well that fund distribution is unlikely to be well-distributed, and thus it is possible that a small number of very large whales can simply take over some sidechain with small mainstakers and outright steal the funds in it, making them even richer. (Consider how the linked write-up mentions "PoW change" much, much too often, I am embarassed for this foolish pseudonymous writer) Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
