Re: [bitcoin-dev] Concrete MATT opcodes
> I think cross-input inspection (not cross-input signature aggregation which > is different) is opening a pandora box in terms of "malicious" off-chain > contracts than one could design. E.g miners bribing contracts to censor the > confirmation of time-sensitive lightning channel transactions, where the > bribes are paid on the hashrate distribution of miners during the previous > difficulty period, thanks to the coinbase pubkey. > > See https://blog.bitmex.com/txwithhold-smart-contracts/ and > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html Hi Antoine, These two papers make a lot of incorrect assumptions about bitcoins security model. The assumption of the existence of constructs such as oracles or altchains for “trustless” out-of-band payments opens the door for plenty of things that in reality are not possible without sacrificing security. The assumption that these constructs “minimize” miner / attacker trust is no better than assuming the existence of an oracle that can simply perform the entire attack. Moreover, even the limited examples of attacks that do not use these constructs completely overlook the fact that bitcoins security model is dependent on the preservation of the nash equilibrium between miners. Not only is it disincentivized for miners to engage in any form of censorship, because they can all be fired by node-runners at any time, it is also not in miners interests to reorg the chain if say an anonymous miner mines some transactions that were being censored. Sustained, successful censorship in any capacity assumes that bitcoin is compromised, a 51% attack has occurred, and necessitates a change in PoW algorithm. A sufficient CSV in LN-like protocols is always sufficient to avoid being attacked in this way. The addition of most forms of covenant does not assist any of these attacks afaict because they already make assumptions rendering them invalid. Symphonic --- Original Message --- On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev wrote: > Hi Salvatore, > > This also allows inspection of other inputs, that was not possible with the > > original opcodes. > > I think cross-input inspection (not cross-input signature aggregation which > is different) is opening a pandora box in terms of "malicious" off-chain > contracts than one could design. E.g miners bribing contracts to censor the > confirmation of time-sensitive lightning channel transactions, where the > bribes are paid on the hashrate distribution of miners during the previous > difficulty period, thanks to the coinbase pubkey. > > See https://blog.bitmex.com/txwithhold-smart-contracts/ and > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html > > I wonder if we might face the dilemma of miners censorship attacks, if we > wish to have more advanced bitcoin contracts, though I think it would be safe > design practice to rule out those types of concerns thanks to smart bitcoin > contracting primitives. > > I think this is a common risk to all second-layers vaults, lightning channels > and payment pools. > > > A flag can disable this behavior" > > More than a binary flag like a matrix could be introduced to encode subset of > introspected inputs /outputs to enable sighash_group-like semantic: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html > > > There are two defined flags: > > - CCV_FLAG_CHECK_INPUT = 1: if present, refers to an input; > > otherwise, it refers to an output. > > - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT > > is absent, it disables the deferred checks logic for amounts. > > Or even beyond a matrix, it could be a set of "tags". There could be a > generalized tag for unstructured data, and another one for bitcoin > transaction / script data types (e.g scriptpubkey, amount, nsequence, merkle > branch) that could be fetched from the taproot annex. > > > After the evaluation of all inputs, it is verified that each output's > > amount is greater than or equal to the total amount in the bucket > > if that output (validation of the deferred checks). > > At the very least, I think for the payment pool, where you're fanning-out > satoshis value from a subset of inputs to another subset of outputs, I think > you would need more malleability here. > > > It is unclear if all the special values above will be useful in > > applications; however, as each special case requires very little added > > code, I tried to make the specs as flexible as possible at this time. > > I think this generic framework is interesting for joinpool / coinpool / > payment pool, as you can check that any withdrawal output can be committed as > part of the input scriptpubkey, and spend it on > blessed-with-one-participant-sig script. There is still a big open question > if it's efficient in terms of witness space consumed. > > That said, I sti
Re: [bitcoin-dev] Blinded 2-party Musig2
Hi Tom, Thanks for the explanation. There's one remaining thing that isn't clear: do you actually require parallel signing requests under the same key. It seems to me that the protocol is very sequential in that you are passing a utxo from one point to another in sequence. If so then the Schnorr blind sigs problem doesn't apply. LL On Thu, 10 Aug 2023 at 20:00, Tom Trevethan wrote: > HI Lloyd, > > Yes, the blind signatures are for bitcoin transactions (these are > timelocked 'backup txs' if the server disappears). This is not standard > 'Schnorr blind signature' (like > https://suredbits.com/schnorr-applications-blind-signatures/) but a > 2-of-2 MuSig where two keys are required to generate the full signature, > but one of them (the server) does not learn of either the full key, message > (tx) or final signature. > > The server is explicitly trusted to report the total number of partial > signatures it has generated for a specific key. If you can verify that ALL > the signatures generated for a specific key were generated correctly, and > the total number of them matches the number reported by the server, then > there can be no other malicious valid signatures in existence. In this > statechain protocol, the receiver of a coin must check all previous backup > txs are valid, and that the total number of them matches the server > reported signature count before accepting it. > > On Thu, Aug 10, 2023 at 4:30 AM Lloyd Fournier > wrote: > >> Hi Tom, >> >> These questions might be wrongheaded since I'm not familiar enough with >> the statechain protocol. Here goes: >> >> Why do you need to use schnorr blind signatures for this? Are the blind >> signatures being used to produce on-chain tx signatures or are they just >> for credentials for transferring ownership (or are they for both). If they >> are for on-chain txs then you won't be able to enforce that the signature >> used was not generated maliciously so it doesn't seem to me like your trick >> above would help you here. I can fully verify that the state chain >> signatures were all produced non-maliciously but then there may be another >> hidden forged signature that can take the on-chain funds that were produced >> by malicious signing sessions I was never aware of (or how can you be sure >> this isn't the case). >> >> Following on from that point, is it not possible to enforce sequential >> blind signing in the statechain protocol under each key. With that you >> don't have the problem of wagner's attack. >> >> LL >> >> On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> @moonsettler >>> >>> When anyone receives a coin (either as payment or as part of a swap) >>> they need to perform a verification of all previous signatures and >>> corresponding backup txs. If anything is missing, then the verification >>> will fail. So anyone 'breaking the chain' by signing something >>> incorrectly simply cannot then send that coin on. >>> >>> The second point is important. All the 'transfer data' (i.e. new and all >>> previous backup txs, signatures and values) is encrypted with the new owner >>> public key. But the server cannot know this pubkey as this would enable it >>> to compute the full coin pubkey and identify it on-chain. Currently, the >>> server identifies individual coins (shared keys) with a statechain_id >>> identifier (unrelated to the coin outpoint), which is used by the coin >>> receiver to retrieve the transfer data via the API. But this means the >>> receiver must be sent this identifier out-of-band by the sender, and also >>> that if anyone else learns it they can corrupt the server key >>> share/signature chain via the API. One solution to this is to have a second >>> non-identifying key used only for authenticating with the server. This >>> would mean a 'statchain address' would then be composed of 2 separate >>> pubkeys 1) for the shared taproot address and 2) for server authentication. >>> >>> Thanks, >>> >>> Tom >>> >>> On Tue, Aug 8, 2023 at 6:44 PM moonsettler >>> wrote: >>> Very nice! Is there an authentication mechanism to avoid 'breaking the chain' with an unverifiable new state by a previous owner? Can the current owner prove the knowledge of a non-identifying secret he learned as recipient to the server that is related to the statechain tip? BR, moonsettler --- Original Message --- On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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/m
Re: [bitcoin-dev] Concrete MATT opcodes
Hi Salvatore,
> This also allows inspection of other inputs, that was not possible with
the original opcodes.
I think cross-input inspection (not cross-input signature aggregation which
is different) is opening a pandora box in terms of "malicious" off-chain
contracts than one could design. E.g miners bribing contracts to censor the
confirmation of time-sensitive lightning channel transactions, where the
bribes are paid on the hashrate distribution of miners during the previous
difficulty period, thanks to the coinbase pubkey.
See https://blog.bitmex.com/txwithhold-smart-contracts/ and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html
I wonder if we might face the dilemma of miners censorship attacks, if we
wish to have more advanced bitcoin contracts, though I think it would be
safe design practice to rule out those types of concerns thanks to smart
bitcoin contracting primitives.
I think this is a common risk to all second-layers vaults, lightning
channels and payment pools.
> A flag can disable this behavior"
More than a binary flag like a matrix could be introduced to encode subset
of introspected inputs /outputs to enable sighash_group-like semantic:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.
Or even beyond a matrix, it could be a set of "tags". There could be a
generalized tag for unstructured data, and another one for bitcoin
transaction / script data types (e.g scriptpubkey, amount, nsequence,
merkle branch) that could be fetched from the taproot annex.
> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).
At the very least, I think for the payment pool, where you're fanning-out
satoshis value from a subset of inputs to another subset of outputs, I
think you would need more malleability here.
> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.
I think this generic framework is interesting for joinpool / coinpool /
payment pool, as you can check that any withdrawal output can be committed
as part of the input scriptpubkey, and spend it on
blessed-with-one-participant-sig script. There is still a big open question
if it's efficient in terms of witness space consumed.
That said, I still think you would need at least ANYPREVOUT and more
malleability for the amount transfer validation as laid out above.
Looking on the `DeferredCheck` framework commit, one obvious low-level
concern is the DoS risk for full-nodes participating in transaction-relay,
and that maybe policy rules should be introduced to keep the worst-CPU
input in the ranges of current transaction spend allowed to propagate on
the network today.
Thanks for the proposal,
Best,
Antoine
Le dim. 30 juil. 2023 à 22:52, Salvatore Ingala via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
> Hi all,
>
> I have put together a first complete proposal for the core opcodes of
> MATT [1][2].
> The changes make the opcode functionally complete, and the
> implementation is revised and improved.
>
> The code is implemented in the following fork of the
> bitcoin-inquisition repo:
>
> https://github.com/Merkleize/bitcoin/tree/checkcontractverify
>
> Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
> previous early demo for vaults [3].
>
> Please check out the diff [4] if you are interested in the
> implementation details. It includes some basic functional tests for
> the main cases of the opcode.
>
> ## Changes vs the previous draft
>
> These are the changes compared to the initial incomplete proposal:
> - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode
> OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows
> to specify if the opcode operates on an input or an output.
> This also allows inspection of other inputs, that was not possible
> with the original opcodes.
> - For outputs, the default behavior is to have the following deferred
> checks mechanism for amounts: all the inputs that have a CCV towards
> the same output, have their input amounts summed, and that act as a
> lower bound for that output's amount.
> A flag can disable this behavior. [*]
> - A number of special values of the parameters were defined in order
> to optimize for common cases, and add some implicit introspection.
> - The order of parameters is modified (particularly, is at the
> bottom of the arguments, as so is more natural when writing Scripts).
>
> ## Semantics
>
