Antoine Riard [ARCHIVE] on Nostr: ð Original date posted:2022-07-20 ð Original message:Hi, Discussions on ...
ð
Original date posted:2022-07-20
ð Original message:Hi,
Discussions on covenants have been prolific and intense on this mailing
list and within the wider Bitcoin technical circles, I believe however
without succeeding to reach consensus on any new set of contracting
primitives satisfying the requirements of known covenant-enabled use-cases.
I think that's a fact to deplore as covenants would not only offer vast
extensions of the capabilities of Bitcoin as a system, i.e enabling new
types of multi-party contract protocols. But also empowering Bitcoin on its
fundamental value propositions of store of value (e.g by making vaults more
flexible) and payment system (e.g by making realistic channel
factories/payment pools).
If we retain as a covenant definition, a spending constraint restricting
the transaction to which the spent UTXO can be spent, and enabling to
program contracts/protocols at the transaction-level instead of the
script-level, the list of Script primitives proposed during the last years
has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1],
CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4],
PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP
[9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all
the listed primitives are at different states of formalization, some
already fully fleshed-out in BIPs, other still ideas on whiteboard, yet
they all extend the range of workable multi-party contract protocols.
Indeed this range has grown wild. Without aiming to be exhaustive (I'm
certainly missing some interesting proposals lost in the abyss of
bitcointalk.org), we can mention the following use-cases: multi-party
stateful contracts [11], congestion trees [12], payment pools [13], "eltoo"
layered commitments [14], programmable vaults [15], multi-events contracts
[16], blockchain-as-oracle bets [17], spacechains [18], trustless
collateral lending [19], ...
Minding all those facts, I would say the task of technical evaluation of
any covenant proposal sounds at least two fold. There is first reasoning
about the enabled protocols on a range of criterias such as scalability,
efficiency, simplicity, extensibility, robustness, data confidentiality,
etc. Asking questions like what are the interactions between layers, if any
? Or how robust is the protocol, not just interactivity failure between
participant nodes but in the face of mempools spikes or internet
disruption ? Or if the performance is still acceptable on shared resources
like blockspace or routing tables if everyone is using this protocol ? Or
if the protocol minimizes regulatory attack surface or centralization
vectors ?
Though once this step is achieved, there is still more reasoning work to
evaluate how good a fit is a proposed Script primitive, the
efficiency/simplicity/ease to use trade-offs, but also if there are no
functionality overlap or hard constraints on the use-cases design
themselves or evolvability w.rt future Script extensions or generalization
of the opcode operations.
Moreover, if you would like your evaluation of a covenant proposal to be
complete, I don't believe you can squeeze the implications with the mempool
rules and combination with any consistent fee-bumping strategy. To say
things politely, those areas have been a quagmire of vulnerabilities,
attacks and defects for second-layers Bitcoin protocols during the last
years [20].
Considering the abundant problem-space offered by covenants, I believe
there is a reasonable groundwork to pursue in building the use-cases
understanding (e.g prototype, pseudo-specification, documentation, ...) and
building consensus on the framework of criterias on which to evaluate them
[21]. It might raise a really high bar for any covenant proposal compared
to previous softforks, however I think it would adequately reflect the
growth in Bitcoin complexity and funds at stakes during the last years.
Moving towards this outcome, I would like to propose a new covenant open
specification process, in the same spirit as we have with the BOLTs or
dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
agenda where topics of discussion can be pinned in advance and
documentation artifacts would be built with time driven by consensus (e.g
1st phase could be to collect, pseudo-specify and find champion(s) for
known use-cases ?) and no timeframe. Starting date could be September /
October / November (later, 2023 ?), giving time for anyone interested in
such a covenant process to allocate development and contribution bandwidth
in function of their involvement interest.
Learning from the good but specially from the bad with setting up the L2
onchain support meetings last year, I think it would be better to keep the
agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
avoiding to create a sense of commitment or perceived signaling in the
process participants towards any covenant solution. I would guess things to
be experimental and evolutionary and folks to spend the first meetings
actually to express what they would like the covenant process to be about
(and yes that means if you're a domain expert and you find the pace of
things too slow sometimes, you have to learn to handle your own
frustration...).
In a "decentralize-everything" fashion, I believe it would be good to have
rotating meeting chairs and multiple covenant documentation archivists. I'm
super happy to spend the time and energy bootstrapping well such covenant
process effort, though as it's Bitcoin learn to decentralize yourself.
I'm really curious what the outcome of such a covenant process would look
like. We might end up concluding that complex covenants are too unsafe by
enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
emergent technical consensus, it doesn't mean there is a real market
interest for such covenant solutions. That said, I'm not sure if it's
really a subject of concern when you're reasoning as a scientist/engineer
and you value technical statements in terms of accuracy, systematic
relevance and intrinsic interest.
Overall, my motivation to kick-start such a process stays in the fact that
covenants are required building blocks to enable scalable payments pools
design like CoinPool. I believe payments pools are a) cool and b) a good
shot at scaling Bitcoin as a payment system once we have reached
scalability limits of Lightning, still under the same security model for
users. However, as a community we might sense it's not the good timing for
a covenant process. I'm really fine with that outcome as there are still
holes to patch in LN to keep me busy enough for the coming years.
Zooming out, I believe with any discussion about covenants or other soft
forks, the hard part isn't about coming up with the best technical solution
to a set of problems but in the iterative process where all voices are
listened to reach (or not) consensus on what is actually meant by "best"
and if the problems are accurate. The real physics of Bitcoin is the
physics of people. It's a work of patience.
Anyways, eager to collect feedbacks on what the ideal covenant
specification process looks like. As usual, all opinions and mistakes are
my own.
Cheers,
Antoine
[0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[1] https://bitcoinops.org/en/topics/op_checksigfromstack/
[2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
[6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
[7]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
[8]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
[9]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
[11]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
[12]
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
[13]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[14]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
[15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
[16]
https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
[17] https://blog.bitmex.com/taproot-you-betcha/
[18]
https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
[19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
[20] https://github.com/jamesob/mempool.work
[21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
[22] https://blog.bitmex.com/txwithhold-smart-contracts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220720/146ede32/attachment-0001.html>;
ð Original message:Hi,
Discussions on covenants have been prolific and intense on this mailing
list and within the wider Bitcoin technical circles, I believe however
without succeeding to reach consensus on any new set of contracting
primitives satisfying the requirements of known covenant-enabled use-cases.
I think that's a fact to deplore as covenants would not only offer vast
extensions of the capabilities of Bitcoin as a system, i.e enabling new
types of multi-party contract protocols. But also empowering Bitcoin on its
fundamental value propositions of store of value (e.g by making vaults more
flexible) and payment system (e.g by making realistic channel
factories/payment pools).
If we retain as a covenant definition, a spending constraint restricting
the transaction to which the spent UTXO can be spent, and enabling to
program contracts/protocols at the transaction-level instead of the
script-level, the list of Script primitives proposed during the last years
has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1],
CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4],
PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP
[9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all
the listed primitives are at different states of formalization, some
already fully fleshed-out in BIPs, other still ideas on whiteboard, yet
they all extend the range of workable multi-party contract protocols.
Indeed this range has grown wild. Without aiming to be exhaustive (I'm
certainly missing some interesting proposals lost in the abyss of
bitcointalk.org), we can mention the following use-cases: multi-party
stateful contracts [11], congestion trees [12], payment pools [13], "eltoo"
layered commitments [14], programmable vaults [15], multi-events contracts
[16], blockchain-as-oracle bets [17], spacechains [18], trustless
collateral lending [19], ...
Minding all those facts, I would say the task of technical evaluation of
any covenant proposal sounds at least two fold. There is first reasoning
about the enabled protocols on a range of criterias such as scalability,
efficiency, simplicity, extensibility, robustness, data confidentiality,
etc. Asking questions like what are the interactions between layers, if any
? Or how robust is the protocol, not just interactivity failure between
participant nodes but in the face of mempools spikes or internet
disruption ? Or if the performance is still acceptable on shared resources
like blockspace or routing tables if everyone is using this protocol ? Or
if the protocol minimizes regulatory attack surface or centralization
vectors ?
Though once this step is achieved, there is still more reasoning work to
evaluate how good a fit is a proposed Script primitive, the
efficiency/simplicity/ease to use trade-offs, but also if there are no
functionality overlap or hard constraints on the use-cases design
themselves or evolvability w.rt future Script extensions or generalization
of the opcode operations.
Moreover, if you would like your evaluation of a covenant proposal to be
complete, I don't believe you can squeeze the implications with the mempool
rules and combination with any consistent fee-bumping strategy. To say
things politely, those areas have been a quagmire of vulnerabilities,
attacks and defects for second-layers Bitcoin protocols during the last
years [20].
Considering the abundant problem-space offered by covenants, I believe
there is a reasonable groundwork to pursue in building the use-cases
understanding (e.g prototype, pseudo-specification, documentation, ...) and
building consensus on the framework of criterias on which to evaluate them
[21]. It might raise a really high bar for any covenant proposal compared
to previous softforks, however I think it would adequately reflect the
growth in Bitcoin complexity and funds at stakes during the last years.
Moving towards this outcome, I would like to propose a new covenant open
specification process, in the same spirit as we have with the BOLTs or
dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
agenda where topics of discussion can be pinned in advance and
documentation artifacts would be built with time driven by consensus (e.g
1st phase could be to collect, pseudo-specify and find champion(s) for
known use-cases ?) and no timeframe. Starting date could be September /
October / November (later, 2023 ?), giving time for anyone interested in
such a covenant process to allocate development and contribution bandwidth
in function of their involvement interest.
Learning from the good but specially from the bad with setting up the L2
onchain support meetings last year, I think it would be better to keep the
agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
avoiding to create a sense of commitment or perceived signaling in the
process participants towards any covenant solution. I would guess things to
be experimental and evolutionary and folks to spend the first meetings
actually to express what they would like the covenant process to be about
(and yes that means if you're a domain expert and you find the pace of
things too slow sometimes, you have to learn to handle your own
frustration...).
In a "decentralize-everything" fashion, I believe it would be good to have
rotating meeting chairs and multiple covenant documentation archivists. I'm
super happy to spend the time and energy bootstrapping well such covenant
process effort, though as it's Bitcoin learn to decentralize yourself.
I'm really curious what the outcome of such a covenant process would look
like. We might end up concluding that complex covenants are too unsafe by
enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
emergent technical consensus, it doesn't mean there is a real market
interest for such covenant solutions. That said, I'm not sure if it's
really a subject of concern when you're reasoning as a scientist/engineer
and you value technical statements in terms of accuracy, systematic
relevance and intrinsic interest.
Overall, my motivation to kick-start such a process stays in the fact that
covenants are required building blocks to enable scalable payments pools
design like CoinPool. I believe payments pools are a) cool and b) a good
shot at scaling Bitcoin as a payment system once we have reached
scalability limits of Lightning, still under the same security model for
users. However, as a community we might sense it's not the good timing for
a covenant process. I'm really fine with that outcome as there are still
holes to patch in LN to keep me busy enough for the coming years.
Zooming out, I believe with any discussion about covenants or other soft
forks, the hard part isn't about coming up with the best technical solution
to a set of problems but in the iterative process where all voices are
listened to reach (or not) consensus on what is actually meant by "best"
and if the problems are accurate. The real physics of Bitcoin is the
physics of people. It's a work of patience.
Anyways, eager to collect feedbacks on what the ideal covenant
specification process looks like. As usual, all opinions and mistakes are
my own.
Cheers,
Antoine
[0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[1] https://bitcoinops.org/en/topics/op_checksigfromstack/
[2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
[6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
[7]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
[8]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
[9]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
[11]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
[12]
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
[13]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[14]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
[15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
[16]
https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
[17] https://blog.bitmex.com/taproot-you-betcha/
[18]
https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
[19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
[20] https://github.com/jamesob/mempool.work
[21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
[22] https://blog.bitmex.com/txwithhold-smart-contracts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220720/146ede32/attachment-0001.html>;