Addendum:
Tomorrow I'll host a Twitter Spaces on this topic:
https://twitter.com/yurivillasboas/status/1743305920937963696
You are all welcome to join!
YSVB
Sent with Proton Mail secure email.
On Friday, January 5th, 2024 at 7:02 PM, yuri...@pm.me wrote:
> Dear friends and colleagues,
>
>
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
On 2024-01-01 00:17, yuri...@pm.me wrote:
I'm afraid I didn't understand your objection. [...]
I suspect my proposed scheme can be
implemented with available, existing Bitcoin infrastructure.
Is a soft fork or a hard fork required? If so, the proposal will need a
lot of peer review and user
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,
Dear all,
Below goes reference to diagram of key derivation of current (hopefully final)
version of my proposed protocol, which, now, doesn't rely on FFM cryptosystem.
https://github.com/Yuri-SVB/LVBsig/blob/main/docs/keys_diagram.jpg
Here, you have one-way function derivations happening from
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,
Dear all,
Upon a few more days working on my proposed protocol, I've found a way to waive
the need for:
1) mining the conventional public key;
2) user broadcasting 2 distinct payloads a few blocks apart;
Up to 66% footprint reduction.
I'll be publishing and submitting it as BIP soon. Those who
Dear all,
Upon second thoughts, I concluded have to issue a correction on my last
correspondence. Where I wrote:
> For 2: a pre-image problem for a function
> f2_(TX,ECCPUB): {l | l is 'a valid LAMPPRI'} -> {a | a is 'in the format of
> ADDRs'} X {LSIG}
>
> (notice the nuance: {LSIG} means
There are three possible cryptanalysis to LAMPPRI in my scheme:
1. From ADDR alone before T0-1 (to be precise, publishing of (TX, SIG));
2. From ADDR and (TX, SIG) after T0-1 (to be precise, publishing of (TX, SIG));
3. Outmine the rest of mining community starting from a disadvantage of not
Does this affect the security model WRT chain reorganizations? In the
classic doublespend attack, an attacker can only redirect UTXOs that they
spent. With this proposal, if I understand it correctly, an attacker could
redirect all funds that have "matured" (revealed the previous preimage in
the
You are right to point out that my proposal was lacking defense against
rainbow-table, because there is a simple solution for it:
To take nonces from recent blocks, say, T0-6, ..., T0-13, for salting LSIG, and
ECCPUB to salt LAMPPUB. Salts don't need to be secret, only unknown by the
builder of
On Tue, Dec 19, 2023 at 6:22 PM wrote:
>
> Thank you for putting yourself through the working of carefully analyzing my
> proposition, Boris!
>
> 1) My demonstration concludes 12 bytes is still a very conservative figure
> for the hashes. I'm not sure where did you get the 14 bytes figure. This
Thank you for putting yourself through the working of carefully analyzing my
proposition, Boris!
1) My demonstration concludes 12 bytes is still a very conservative figure for
the hashes. I'm not sure where did you get the 14 bytes figure. This is
2*(14-12) = 4 bytes less.
2) Thank you for
On Tue, Dec 19, 2023 at 11:07 AM wrote:
>
> Thank you for the question, Boris. That was an easy one:
>
> Short answer is Lamport hashes are protected by long hash of key fingerprint
> an ECC (Schnorr or otherwise conventional) public-key, which is not published
> until first transaction. For
Thank you for the question, Boris. That was an easy one:
Short answer is Lamport hashes are protected by long hash of key fingerprint an
ECC (Schnorr or otherwise conventional) public-key, which is not published
until first transaction. For clarity:
HL(.) = serial-work- and memory-*hard* hash
I beg to disagree: key owner broadcasts first bundle (let's call it this way)
so that it is on any miner's best interest to include said bundle on their's
attempted coinbase because they know if they don't any other competing miner
will in the next block.
Once more I think it's worth
On Mon, Dec 18, 2023 at 7:44 PM wrote:
>
> I beg to disagree: key owner broadcasts first bundle (let's call it this way)
> so that it is on any miner's best interest to include said bundle on their's
> attempted coinbase because they know if they don't any other competing miner
> will in the
Hey Yuri,
On Mon, Dec 18, 2023 at 6:19 AM Yuri S VB via bitcoin-dev
wrote:
> down from 136 from ECC.
Schnorr signature has size 64 bytes (serialized format consists of x
coordinate of R and of s, 32 bytes each).
> The whole point is that, in the typical use case in which pre-image of hash
>
Hi Yuri,
While not exactly the same, the idea of using Lamport chains was analyzed
circa 2012 in the context of cryptocurrencies.
I proposed a new signature scheme called MAVE [1], and then a
cryptocurrency scheme called MAVEPAY [2] to reduce the size of signatures
to a minimum of 3 hash
Dear colleagues,
After having mentioned it in a Twitter Space a few moments ago, I felt the need
to share the idea with you even just as a draft. Utilizing Lamport Scheme (not
signature) for better byte-efficiency in L1:
1. Have signing keys consist of the current ECC key AND a Lamport chain;
20 matches
Mail list logo
