Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-11 🗒️ Summary of this message: The email ...
📅 Original date posted:2023-06-11
🗒️ Summary of this message: The email discusses potential solutions for a bitcoin-native way to store data on the blockchain without compromising security or efficiency.
📝 Original message:
Hi Dave,
On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave at dtrt.org> wrote:
> 3. When paying the script in #2, Alice chooses the scriptpath spend from
> #1 and pushes a serialized partial signature for the ephemeral key
> from #2 onto the stack, where it's immediately dropped by the
> interpreter (but is permanently stored on the block chain). She also
> attaches a regular signature for the OP_CHECKSIG opcode.
>
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, effectively deleting the keys to the vault? If not, this would be a
great alternative!
Even better, I think you can achieve nearly the same safety without
> putting any data on the chain. All you need is a widely used
> decentralized protocol that allows anyone who can prove ownership of a
> UTXO to store some data.
>
I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.
By comparison, rolling
> out relay of the annex and witness replacement may take months of review
> and years for >90% deployment among nodes, would allow an attacker to
> lower the feerate of coinjoin-style transactions by up to 4.99%, would
> allow an attacker to waste 8 million bytes of bandwidth per relay node
> for the same cost they'd have to pay to today to waste 400 thousand
> bytes, and might limit the flexibility and efficiency of future
> consensus changes that want to use the annex.
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?
I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230611/bfbf1f51/attachment.html>;
🗒️ Summary of this message: The email discusses potential solutions for a bitcoin-native way to store data on the blockchain without compromising security or efficiency.
📝 Original message:
Hi Dave,
On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave at dtrt.org> wrote:
> 3. When paying the script in #2, Alice chooses the scriptpath spend from
> #1 and pushes a serialized partial signature for the ephemeral key
> from #2 onto the stack, where it's immediately dropped by the
> interpreter (but is permanently stored on the block chain). She also
> attaches a regular signature for the OP_CHECKSIG opcode.
>
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, effectively deleting the keys to the vault? If not, this would be a
great alternative!
Even better, I think you can achieve nearly the same safety without
> putting any data on the chain. All you need is a widely used
> decentralized protocol that allows anyone who can prove ownership of a
> UTXO to store some data.
>
I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.
By comparison, rolling
> out relay of the annex and witness replacement may take months of review
> and years for >90% deployment among nodes, would allow an attacker to
> lower the feerate of coinjoin-style transactions by up to 4.99%, would
> allow an attacker to waste 8 million bytes of bandwidth per relay node
> for the same cost they'd have to pay to today to waste 400 thousand
> bytes, and might limit the flexibility and efficiency of future
> consensus changes that want to use the annex.
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?
I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230611/bfbf1f51/attachment.html>;