Dear friends and colleagues, I believe this current version of the protocol and its documentation, now including a diagram answers the questions raised so far:
https://github.com/Yuri-SVB/LVBsig/blob/main/docs/white_paper.md All in all, in addition to the plain transaction TXi, only 36 bytes are needed to authenticate it. The number falls to 16 in case of address (address chain) is reused, because change address coincides with Lamport-scheme pre-image. YSVB. Sent with Proton Mail secure email. On Monday, January 1st, 2024 at 11:17 AM, yuri...@pm.me <yuri...@pm.me> wrote: > Hello, Dave, > > I'm afraid I didn't understand your objection. It would be great to have a > direct, real-time conversation with you, if you have the availability. Be my > guest to DM me for that. > > Though this is to be confirmed, I suspect my proposed scheme can be > implemented with available, existing Bitcoin infrastructure. As far as my > limited knowledge goes, the trickiest part would be to have miners agree that > pre-image of hash of a transaction, in a subsequent block is acceptable > authentication. As for the commitment, it could be implemented as ordinary > smart contracts are, and its size doesn't matter because in the normal use > case, it is not mined. > > To be clear: The only component that is mined other than addresses and the > plaintext transactions would be one hash, between 16 and 20 bytes. From the > No-Free-Lunch Principle, the cost for it is that transaction takes a few > blocks, instead of just one to be validated. > > YSVB > > Sent with Proton Mail secure email. > > > On Sunday, December 31st, 2023 at 8:33 PM, David A. Harding d...@dtrt.org > wrote: > > > > > Hi Yuri, > > > > I think it's worth noting that for transactions with an equal number of > > P2TR keypath spends (inputs) and P2TR outputs, the amount of space used > > in a transaction by the serialization of the signature itself (16 vbytes > > per input) ranges from a bit over 14% of transaction size (1-input, > > 1-output) to a bit less than 16% (10,000-in, 10,000-out; a ~1 MvB tx). > > I infer that to mean that the absolute best a signature replacement > > scheme can do is free up 16% of block space. > > > > An extra 16% of block space is significant, but the advantage of that > > savings needs to be compared to the challenge of creating a highly peer > > reviewed implementation of the new signature scheme and then convincing > > a very large number of Bitcoin users to accept it. A soft fork proposal > > that introduces new-to-Bitcoin cryptography (such as a different hash > > function) will likely need to be studied for a prolonged period by many > > experts before Bitcoin users become confident enough in it to trust > > their bitcoins to it. A hard fork proposal has the same challenges as a > > soft fork, plus likely a large delay before it can go into effect, and > > it also needs to be weighed against the much easier process it would be > > for experts and users to review a hard fork that increased block > > capacity by 16% directly. > > > > I haven't fully studied your proposal (as I understand you're working on > > an improved version), but I wanted to put my gut feeling about it into > > words to offer feedback (hopefully of the constructive kind): I think > > the savings in block space might not be worth the cost in expert review > > and user consensus building. > > > > That said, I love innovative ideas about Bitcoin and this is one I will > > remember. If you continue working on it, I very much look forward to > > seeing what you come up with. If you don't continue working on it, I > > believe you're likely to think of something else that will be just as > > exciting, if not more so. > > > > Thanks for innovating!, > > > > -Dave
publickey - yurisvb@pm.me - 0x535F445D.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
