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 ar
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
t; (ECCPUB, LAMPPUB) pair. The increased size of LAMPPRI would be
> > > compensated by one entire ADDR less in the blockchain. Namely, we'd have
> > > an extra marginal reduction of 12 bytes per use (possibly more, depending
> > > on how much mor
e
> > bytes we can economize given that added strength).
> >
> > YSVB.
> >
> > On Friday, December 22nd, 2023 at 5:52 AM, G. Andrew Stone
> > g.andrew.st...@gmail.com wrote:
> >
> > > Does this affect the security model WRT chain reorganiz
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"
; and every coin spent by anyone between the fork point and
> the maturity depth is available to the attacker to doublespend?
>
> On Thu, Dec 21, 2023, 8:05 PM Yuri S VB via bitcoin-dev
> wrote:
>
> > You are right to point out that my proposal was lacking defense against
>
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
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 poi
Hello, colleagues
Since some of you seem to be enjoying my ideas and having a better time
understanding them than most of investors I share them with, here goes a white
paper of my proposed Kerckhoffian (non-obscure) protocol for
coercion-resistance in self-(not shared-)custody
https://github.c
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 w
vance (spending as much time as needed). He should do
> it twice to know the next two hashes. Then mines the first transaction
> (in which he steals coins from the address) with the first hash and
> then publish the second hash a few blocks later to finalize the theft.
>
> >
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;
Dear Mr. Dash Jr, Kalle Alm and other members of Bitcoin dev mailing list,
Upon receiving several constructive, technical, generous pieces of feedback,
and a few more months of continued development, I feel now ready to formally
file Formosa, my proposed expansion of BIP39 changing from words to
certainly make $5 wrench attacks more viable, not less. I can't
> > help but ask myself the question whether more Bitcoin is lost because of
> > seed phrases not being memorized, or because of social engineering
> > exercises used to scrape these phrases from the brains of
whether more Bitcoin is lost because of seed
> phrases not being memorized, or because of social engineering exercises used
> to scrape these phrases from the brains of users. I have a hunch that loss is
> a larger problem than theft, but it is a very real possibility that a wide
> d
Dear colleagues,
The following is a password format that improves upon BIP39 by allowing
meaningful, themed sentences with a regular grammatical structure instead of
semantically disconnected words, while keeping the same entropy/checksum and
total bits/non-repeating leading digits ratios (of 32
17 matches
Mail list logo
