New BIP: PubRef - OP Code For Public Data References

TheRook commented at 2:49 am on July 24, 2019: none

After a feedback on the mailing list, we can see that there are clear advantages and disadvantages of this proposal. I think the good outweighs the bad, and I think this proposal should move forward.

bip323: let there be light a6a6bff4e1

Update BIP-0323

wiki formatting changes

ed3ab48f78

bip-0323 formatting changes for code blocks

bip-0323 formatting changes for code blocks

f526ff512c

Update bip-0323.mediawiki 4199392fc4

Update Readme.midawiki

Adding bip-0323 to the index.

9b8a25ca5f

Update bip-0323

updated Layer to match whitelist used by circle-ci

b592ffad45

sipa commented at 2:52 am on July 24, 2019: member

This is not a soft fork
This worsens fungibility by incentivizing reuse.
This breaks independent verifiability of transactions.
This introduces an ever-growing data structure necessary for validation, making scalability significantly worse.

All of these things have been pointed out.

Update bip-0323.mediawiki 87d9d20dd8

Update Readme

title limit 44 char

b3b92b2c66

TheRook commented at 3:03 am on July 24, 2019: none

sipa.

All evidence provided shows that;

This is in fact a soft fork
This change massively improves improves fungibility for every single bitcoin user
Transactions are always verifiable to all parties, forever.
Complexity is a fact of life, and an O(1) time complexity should be acceptable.

This submission has done its due diligence in supporting a useful feature. Please provide some evidence to support your claims.

sipa commented at 3:33 am on July 24, 2019: member

You cannot modify the stack when redefining NOP opcodes. For example “PUBREF DEPTH VERIFY” would be invalid before your code activates, and valid after. That’s not a softfork.
You’re making the reuse of keys cheaper than non-reuse. This incentivizes people to reduce their privacy, which worsens fungibility. The average reduction is cost has nothing to do with fungibility.
That’s not true, because PUBREF depends on the order in which transactions are included in the chain. If you’re referring to a recent transaction, the validity of a transaction may be affected by a (shallow) reorg. So far Bitcoin transactions are always objectively valid or invalid, independent of context, as long as its UTXOs are available. Your change makes it impossible to reason about transaction validity before being included in the chain.
This is not about complexity, but about the amount of (fast) storage validating nodes need. Right now, all a node needs is the UTXO set and the chain of block headers. With your change, it also needs a copy of all pushes ever created.

TheRook commented at 4:01 am on July 24, 2019: none

Any version change would result in transactions being invalid prior to accepting this new version. If the SegWit version param is intended to produce a softfork, then this is a good use case.
Utility often has a tradeoff, and being cheaper is also useful. Any reputable merchant that doesn’t care about anonymity can directly benefit from PubRef. Privacy and fungibility are only tightly connected for a minority of users.
This is a good point and I’ll account for this in my reference implementation, this is by no means a blocking issue.
The amount of repeated data is also a factor, PubRef also helps with scalability - it isn’t a one sided tradeoff.

jb55 commented at 4:19 am on July 24, 2019: none

All evidence provided shows that

This change massively improves improves fungibility for every single bitcoin user

We have repeatedly given explanations for why this isn’t the case. I have asked you personally via email to explain your case, and you did not respond. What is this evidence?

sipa commented at 4:22 am on July 24, 2019: member

There are ways to make something like this a softfork, but it is not as easy as just defining a new opcode. Using a segwit script version number is one possibility.
In recommended practice (no key reuse) this literally has zero impact, so it’s very hard to argue how it can have benefits while simultaneously clearly worsening fungibility.
To me this is an absolute dealbreaker, and I suspect to many others as well. I don’t see how you can avoid this problem. To prevent it, transaction validity cannot depend on any data that isn’t committed to by the transaction.
That’s a matter of perspective; blockchain size isn’t a big problem due to the weight limit; chainstate growth is possibly a very big one in the long term.

There are ways to get the same scalability advantages this gives by treating the deduplication of stack elements as an P2P/storage layer compression scheme, rather than as a consensus change that integrates into script. I cannot speak for others of course, but I feel you’re very dismissive of all the concerns people have brought up on the ML, and as is there is very little chance this will be adopted. As an alternative compression approach on top of the tx/block data it would make much more sense (though still not particularly useful, as it’d still not help unless there was key reuse).

TheRook commented at 4:36 am on July 24, 2019: none

@jb55 I believe I have responded to all email. You are welcome to provide specific details here. sipa has been notable in being able to backup his statements. A lot of the feedback on the mailing list was not constructive or informed, specifically the comment related to “O(1) is a DoS risk”. @sipa Correct me if I am wrong but any stream or block compression algorithm would run into the issue you brought up #3. In some sense, PubRef is a way of achieving stream compression of newly formed blocks. As long as new references are created from transactions found in blocks n-1, where n is the most recent confirmed block then these values are immutable and globally visible to all peers. I believe this satisfies this concern. Scaleability is a more complex question, but is possible to quantify, we can gather stats related to how PubRef would reshape the network.

jb55 commented at 10:00 am on July 24, 2019: none

You are welcome to provide specific details here.

My specific concern was the inclusion of an opcode that would be cheaper than not using it. This economically incentivizes key reuse. This would hurt fungibility in p2sh cases when pubkey refs are revealed in the redeem script during spending. It’s really that simple.

As far as I know you have not responded to this fact, simply stating that “this this actually improves fungibility” without giving any evidence of that. All I’m asking is that you explain your reasoning.

in README.mediawiki:893 in b3b92b2c66 outdated

888@@ -889,6 +889,13 @@ Those proposing changes should consider that ultimately consent may rest with th
889 | Karl-Johan Alm
890 | Standard
891 | Draft
892+|-
893+| [[bip-0323.mediawiki|323]]

MarcoFalke commented at 11:38 am on July 24, 2019:

Please do not self-assign BIP numbers, there is a process for that in BIP 2

TheRook commented at 6:22 pm on July 24, 2019: none

@jb55 This is a reasonable question, and I am happy to address it. Currently the smallest two party transaction can be achieved with SegWit at 233 bytes - a lot of this overhead comes from the Script, and more specifically the public-key material being pushed onto the stack. By using PubRef we could get a 85 byte savings or a 148 byte transaction - which is hot. Opening the door for more compact scripts only helps p2sh because it makes the Script language more useful. If that p2sh ends up being a multi-sig transaction, then each public-key can be defined using a PubRef with compounded linear savings. Even putting this edge-case aside - there are legitimate reasons to reuse key-material and any time this happens all users can benefit from the block weight savings that come with compression.

jb55 commented at 6:31 pm on July 24, 2019: none

@TheRook I’m asking specifically about your claim that this “improves fungibility” which you still have not answered.

jb55 commented at 6:32 pm on July 24, 2019: none

Since this is not the ideal forum for this discussion, feel free to answer on the mailing list.

TheRook commented at 7:50 pm on July 24, 2019: none

@jb55 I agree, I just posted my comments related to fungibility to the mailing list. Additionally, i just realized i was replying to individual users - and not to the entire mailing list, FML.

removing bip number

updating rational

00792c891c

removing bip number a06211a045

luke-jr renamed this:
~~Creation BIP-0323~~
New BIP: PubRef - OP Code For Public Data References
on Jul 25, 2019

TheRook closed this on Jul 25, 2019

New BIP: PubRef - OP Code For Public Data References #807