* [bitcoin-dev] Smaller Transactions with PubRef
@ 2020-08-01 5:09 Mike Brooks
2020-08-02 0:36 ` ZmnSCPxj
0 siblings, 1 reply; 4+ messages in thread
From: Mike Brooks @ 2020-08-01 5:09 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
The attached BIP describes a new opcode that unlocks the ability to have
transactions that are about 37% smaller than a traditional single-source
segwit transaction. (Savings vary based on the number of inputs.)
The pursuit of smaller transactions is vital for Inclusive Accountability
as less data needs to be recorded on chain. Frugality is improved in two
ways; more transactions can be confirmed in a block, and small value
inputs otherwise inaccessible can now be referenced without losing
unrecoverable value due to transaction overhead.
https://github.com/TheRook/bip-pubref/blob/master/bip-PubRef.mediawiki
The variant of this technology on the ethereum side is Ditto Transactions:
https://ethereum-magicians.org/t/eip-ditto-transactions/4455
[-- Attachment #2: Type: text/html, Size: 1033 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Smaller Transactions with PubRef
2020-08-01 5:09 [bitcoin-dev] Smaller Transactions with PubRef Mike Brooks
@ 2020-08-02 0:36 ` ZmnSCPxj
2020-08-02 1:12 ` Mike Brooks
0 siblings, 1 reply; 4+ messages in thread
From: ZmnSCPxj @ 2020-08-02 0:36 UTC (permalink / raw)
To: Mike Brooks, Bitcoin Protocol Discussion
Good morning Mike,
Hard NAK.
The responses to the original posting already pointed out important problems with this:
* Encourages address reuse, hurting fungibility and privacy.
* Prevents pruning, since access to previous blocks must always be available in order to validate.
* Optimized implementation requires creating yet another index to previous block data, increasing requirements on fullnodes.
* Requires SCRIPT to be re-evaluated on transactions arriving in newblocks, to protect against reorgs of the chaintip, and in particular `OP_PUBREF` references to near the chaintip.
None of these issues have been addressed in your current proposal.
The proposal looks at clients only, without considering what validators have to implement in order to validate new blocks with this opcode.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Smaller Transactions with PubRef
2020-08-02 0:36 ` ZmnSCPxj
@ 2020-08-02 1:12 ` Mike Brooks
2020-08-02 14:22 ` ZmnSCPxj
0 siblings, 1 reply; 4+ messages in thread
From: Mike Brooks @ 2020-08-02 1:12 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]
Hey ZmnSCPxj,
Re-orgs should be solved in a different way.
Best Regards,
Micahel
On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Mike,
>
> Hard NAK.
>
> The responses to the original posting already pointed out important
> problems with this:
>
> * Encourages address reuse, hurting fungibility and privacy.
> * Prevents pruning, since access to previous blocks must always be
> available in order to validate.
> * Optimized implementation requires creating yet another index to previous
> block data, increasing requirements on fullnodes.
> * Requires SCRIPT to be re-evaluated on transactions arriving in
> newblocks, to protect against reorgs of the chaintip, and in particular
> `OP_PUBREF` references to near the chaintip.
>
> None of these issues have been addressed in your current proposal.
> The proposal looks at clients only, without considering what validators
> have to implement in order to validate new blocks with this opcode.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #1.2: Type: text/html, Size: 1403 bytes --]
[-- Attachment #2: Floating-Point Nakamoto Consensus.pdf --]
[-- Type: application/pdf, Size: 70769 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Smaller Transactions with PubRef
2020-08-02 1:12 ` Mike Brooks
@ 2020-08-02 14:22 ` ZmnSCPxj
0 siblings, 0 replies; 4+ messages in thread
From: ZmnSCPxj @ 2020-08-02 14:22 UTC (permalink / raw)
To: Mike Brooks; +Cc: Bitcoin Protocol Discussion
Good morning Mike,
The issue with SCRIPT re-evaluation is that reorgs cause more processing to be done by nodes.
Floating-point Nakamoto Consensus does not help here, since a node can receive the lower-scored block first, and *then* a higher-scored block, and thus will ***still*** observe a reorg since the chain tip is replaced with a higher-scored block later.
This still increases the processing load on validating fullnodes, and prevents any kind of pruning from working for validating fullnodes.
A miner can also still mount a DoS on validating fullnodes, with `OP_PUBREF` and Floating-Point Nakamoto Consensus by re-mining the same block, and broadcasting a block if it has higher score than the previous chain tip.
This locks the blockchain ***and*** increases the load on fullnodes, which have to re-validate uses of `OP_PUBREF` that might refer to the chain tip.
Regards,
ZmnSCPxj
> Hey ZmnSCPxj,
>
> Re-orgs should be solved in a different way.
>
> Best Regards,
> Micahel
>
> On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> > Good morning Mike,
> >
> > Hard NAK.
> >
> > The responses to the original posting already pointed out important problems with this:
> >
> > * Encourages address reuse, hurting fungibility and privacy.
> > * Prevents pruning, since access to previous blocks must always be available in order to validate.
> > * Optimized implementation requires creating yet another index to previous block data, increasing requirements on fullnodes.
> > * Requires SCRIPT to be re-evaluated on transactions arriving in newblocks, to protect against reorgs of the chaintip, and in particular `OP_PUBREF` references to near the chaintip.
> >
> > None of these issues have been addressed in your current proposal.
> > The proposal looks at clients only, without considering what validators have to implement in order to validate new blocks with this opcode.
> >
> > Regards,
> > ZmnSCPxj
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-08-02 14:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-01 5:09 [bitcoin-dev] Smaller Transactions with PubRef Mike Brooks
2020-08-02 0:36 ` ZmnSCPxj
2020-08-02 1:12 ` Mike Brooks
2020-08-02 14:22 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox