š
Original date posted:2023-06-13
šļø Summary of this message: A proposal for a bitcoin-native solution to leverage bitcoin's security properties for vaults was discussed, with considerations for scalability and privacy. The need for an alternative way to relay transactions to miners besides the p2p network was also mentioned.
š Original message:
On 2023-06-11 09:25, Joost Jager wrote:
> Isn't it the case that that op-dropped partial signature for the
> ephemeral key isn't committed to and thus can be modified by anyone
> before it is mined
That's correct; I hadn't thought of that, sorry.
> I am really looking for a bitcoin-native solution to leverage
> bitcoin's robustness and security properties.
I understand. I would briefly point out that there are other advantages
to not storing a signature for an ephemeral key in the annex. For
example, if you want to generate multiple different potential spending
transactions, you need to store one signature for each potential
transaction. The more data you store in the annex, the less scalable
the vault protocol becomes; by comparison, it's possible to cheaply
store a very large amount of data offchain with high robustness.
Also, depending on construction of the vault, a possible advantage of a
presigned vault (without using the annex) over a solution like OP_VAULT
is that all actions might be able to use keypath spends. That would be
highly efficient, increasing the usability of vaults. It would also be
more private, which may be important to certain classes of vault users.
Even if OP_VAULT was added to Bitcoin, it would be interesting to have
an alternative vault protocol that offered different tradeoffs.
> That years-long timeline that you sketch for witness replacement (or
> any other policy change I presume?) to become effective is perhaps
> indicative of the need to have an alternative way to relay
> transactions to miners besides the p2p network?
The speed depends on the policy change. In this case, I think there's a
reasonable argument to be made that a mitigation for the problems of
annex relay should be widely deployed before we enable annex relay.
Bitcoin Core's policy is designed to both prevent the abuse of relay
node resources and also serve the transaction selection needs of miners.
Any alternative relay system will need to solve the same general
problems: how to prevent abuse of the relayers and help miners choose
the best transactions. Ideas for alternative relay like those
previously proposed on this list[1] avoid certain problems but also
(AFAICT) create new problems.
To be specific towards this proposal, if an alternative relay network
naively implemented annex relay, any miners who used that network could
receive a coinjoin-style transaction with a large annex that
significantly reduced the transaction's feerate. By comparison, any
miners who continued to only receive transactions from the P2P network
of Bitcoin Core (or similar) nodes would have received the transaction
without an annex at its original (higher) feerate, allowing them to to
receive greater revenue if they mined it. If, instead, the alternative
relay network implemented the witness replacement proposal you've linked
to, those miners could still receive up to 4.99% less revenue than
Bitcoin Core-based miners and the operators of the alternative relay
network might have had to pay extra costs for the replacement relays.
You can tweak the proposal to tweak those ratios, but I'm not sure
there's a case where an alternative relay network comes up as a clear
winner over the existing network for general purpose transactions.
Instead, like many things, it's a matter of tradeoffs.
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
Apologies for the salt, but there is a good solution: don't use the
block chain to store backup data.
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-19 18:19:56
in reply to nevent1qā¦vqqt
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-19 18:19:56Event JSON
{
"id": "5ae9a8947bf1b431b234fe867b41d6f4197d4d1c86825dc71eeb0b4ff2216991",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1687198796,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"9cd2e84ae36b2057474e40526efcc8e1b769538822692fc592ecadcf48bb58da",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "š
Original date posted:2023-06-13\nšļø Summary of this message: A proposal for a bitcoin-native solution to leverage bitcoin's security properties for vaults was discussed, with considerations for scalability and privacy. The need for an alternative way to relay transactions to miners besides the p2p network was also mentioned.\nš Original message:\nOn 2023-06-11 09:25, Joost Jager wrote:\n\u003e Isn't it the case that that op-dropped partial signature for the\n\u003e ephemeral key isn't committed to and thus can be modified by anyone\n\u003e before it is mined\n\nThat's correct; I hadn't thought of that, sorry.\n\n\u003e I am really looking for a bitcoin-native solution to leverage\n\u003e bitcoin's robustness and security properties.\n\nI understand. I would briefly point out that there are other advantages\nto not storing a signature for an ephemeral key in the annex. For\nexample, if you want to generate multiple different potential spending\ntransactions, you need to store one signature for each potential\ntransaction. The more data you store in the annex, the less scalable\nthe vault protocol becomes; by comparison, it's possible to cheaply\nstore a very large amount of data offchain with high robustness.\n\nAlso, depending on construction of the vault, a possible advantage of a\npresigned vault (without using the annex) over a solution like OP_VAULT\nis that all actions might be able to use keypath spends. That would be\nhighly efficient, increasing the usability of vaults. It would also be\nmore private, which may be important to certain classes of vault users.\nEven if OP_VAULT was added to Bitcoin, it would be interesting to have\nan alternative vault protocol that offered different tradeoffs.\n\n\u003e That years-long timeline that you sketch for witness replacement (or\n\u003e any other policy change I presume?) to become effective is perhaps\n\u003e indicative of the need to have an alternative way to relay\n\u003e transactions to miners besides the p2p network?\n\nThe speed depends on the policy change. In this case, I think there's a\nreasonable argument to be made that a mitigation for the problems of\nannex relay should be widely deployed before we enable annex relay.\n\nBitcoin Core's policy is designed to both prevent the abuse of relay\nnode resources and also serve the transaction selection needs of miners.\nAny alternative relay system will need to solve the same general\nproblems: how to prevent abuse of the relayers and help miners choose\nthe best transactions. Ideas for alternative relay like those\npreviously proposed on this list[1] avoid certain problems but also\n(AFAICT) create new problems.\n\nTo be specific towards this proposal, if an alternative relay network\nnaively implemented annex relay, any miners who used that network could\nreceive a coinjoin-style transaction with a large annex that\nsignificantly reduced the transaction's feerate. By comparison, any\nminers who continued to only receive transactions from the P2P network\nof Bitcoin Core (or similar) nodes would have received the transaction\nwithout an annex at its original (higher) feerate, allowing them to to\nreceive greater revenue if they mined it. If, instead, the alternative\nrelay network implemented the witness replacement proposal you've linked\nto, those miners could still receive up to 4.99% less revenue than\nBitcoin Core-based miners and the operators of the alternative relay\nnetwork might have had to pay extra costs for the replacement relays.\nYou can tweak the proposal to tweak those ratios, but I'm not sure\nthere's a case where an alternative relay network comes up as a clear\nwinner over the existing network for general purpose transactions.\nInstead, like many things, it's a matter of tradeoffs.\n\n\u003e I agree though that it would be ideal if there is a good solution that\n\u003e doesn't require any protocol changes or upgrade path.\n\nApologies for the salt, but there is a good solution: don't use the\nblock chain to store backup data.\n\n-Dave\n\n[1] \nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html",
"sig": "c23b2bb97724c1e2a64477c10cc88fd49b66f072ea61000c7889870e741fd456916106e3a295803ab107b35a2587713076a513416720e59746a4c2b8f76cff5d"
}