New BIP: PubRef - OP Code For Public Data References #807
pull TheRook wants to merge 10 commits into bitcoin:master from TheRook:master changing 2 files +100 −0-
TheRook commented at 2:49 am on July 24, 2019: noneAfter 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
-
bip-0323 formatting changes for code blocks
bip-0323 formatting changes for code blocks
-
Update bip-0323.mediawiki 4199392fc4
-
Update Readme.midawiki
Adding bip-0323 to the index.
-
Update bip-0323
updated Layer to match whitelist used by circle-ci
-
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
-
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 2TheRook 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:32 pm on July 24, 2019: noneSince this is not the ideal forum for this discussion, feel free to answer on the mailing list.removing bip number
updating rational
removing bip number a06211a045luke-jr renamed this:
Creation BIP-0323
New BIP: PubRef - OP Code For Public Data References
on Jul 25, 2019TheRook closed this on Jul 25, 2019
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 03:10 UTC
More mirrored repositories can be found on mirror.b10c.me