📅 Original date posted:2022-07-24
📝 Original message:------- Original Message -------
On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Michael,
>
> I'm thinking such a covenant effort would be more a technical process aiming to advance the state of covenant & contracting knowledge, collect and document the use-cases, exchange engineering learnings from the prototype, share the problem space, etc. In the same fashion we have the BOLT one or even more remote the IETF working groups about a bunch of Internet technology [0]. I think that Taproot/Schnorr has set a high standard in terms of safety-first and careful Bitcoin engineering effort, aggregating 8 years of thinking around MAST and friends but also exploring other signature schemes like BLS. And I hope with covenants we aim for higher standards, as if there is one learning from Taproot we could have spent more time working out use-cases prototypes (e.g joinpools) and standard libraries to mature, it could have save actual headache around x-pubkeys [1]
Hi Antoine,
Claiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not entitled to be hard coded as standard.
Schnorr/MAST development history, is a good subject for case study, but it is not guaranteed that the outcome to be always the same as your take.
I'd suggest instead of inventing a multi-decades-lifecycle based methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind enough for examining more agile approaches and their inevitable effect on the course of discussions,
Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220724/8de09dce/attachment.html>;
aliashraf.btc At protonmail [ARCHIVE] /
npub16y…en0h8
2023-06-07 23:12:04
in reply to nevent1q…evxq
Author Public Key
npub16ymxe6ccxy3e2r3q48akx3ncyj6n48ujheere8r0ptk6f3j4y0vqcen0h8Seen on
wss://relay.nostr.bandPublished at
2023-06-07 23:12:04Event JSON
{
"id": "4e356af58e165305f519891b54d2c0379b28866003ebc109bebd0af78cae4bbf",
"pubkey": "d1366ceb183123950e20a9fb63467824b53a9f92be723c9c6f0aeda4c65523d8",
"created_at": 1686179524,
"kind": 1,
"tags": [
[
"e",
"32278431461b2aef74d3e0bd3f2c67c0cb2a1196ed72c760c4d2cf2b42931ee2",
"",
"root"
],
[
"e",
"e56141f006e4b2e4222ed463ce4991ad6fa2b5a657dc44968efc6fadf3ef3882",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2022-07-24\n📝 Original message:------- Original Message -------\nOn Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Michael,\n\u003e\n\u003e I'm thinking such a covenant effort would be more a technical process aiming to advance the state of covenant \u0026 contracting knowledge, collect and document the use-cases, exchange engineering learnings from the prototype, share the problem space, etc. In the same fashion we have the BOLT one or even more remote the IETF working groups about a bunch of Internet technology [0]. I think that Taproot/Schnorr has set a high standard in terms of safety-first and careful Bitcoin engineering effort, aggregating 8 years of thinking around MAST and friends but also exploring other signature schemes like BLS. And I hope with covenants we aim for higher standards, as if there is one learning from Taproot we could have spent more time working out use-cases prototypes (e.g joinpools) and standard libraries to mature, it could have save actual headache around x-pubkeys [1]\n\nHi Antoine,\nClaiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not entitled to be hard coded as standard.\n\nSchnorr/MAST development history, is a good subject for case study, but it is not guaranteed that the outcome to be always the same as your take.\n\nI'd suggest instead of inventing a multi-decades-lifecycle based methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind enough for examining more agile approaches and their inevitable effect on the course of discussions,\n\nCheers,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220724/8de09dce/attachment.html\u003e",
"sig": "52ac04568cc2facc29a4d0a77722b6c3e1e96169cd5bb4cce374dfe454c2911bf7db815f8e971591fa3488c8ddbfd88e90241c697a72c4c32ecc302bdea45278"
}