[bitcoin-dev] Smaller Transactions with PubRef

[bitcoin-dev] Smaller Transactions with PubRef

[Mike Brooks]

[-- 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 --]

Re: [bitcoin-dev] Smaller Transactions with PubRef

[ZmnSCPxj]

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

Re: [bitcoin-dev] Smaller Transactions with PubRef

[Mike Brooks]

[-- 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 --]

Re: [bitcoin-dev] Smaller Transactions with PubRef

[ZmnSCPxj]

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