Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 the singleton containing of only the
> specific LSIG that was actually public, not 'in the format of LSIGs').
Please read
"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 {s | s is 'in the format of LSIGs'}"
instead, and completely disregard the nuance below, which is wrong. I apologize
for the mistake, and hope I have made myself clear. Thank you, again for your
interest, and I'll be back with formulas for entropy in both cases soon!
YSVB
Sent with Proton Mail secure email.
On Friday, December 22nd, 2023 at 4:32 PM, yuri...@pm.me wrote:
> 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
> less than (T1-T0-1) after T1 (to be precise, at time of publishing of LAMPRI);
>
> ...which bring us back to my argument with Boris: There is something else we
> missed in our considerations, which you said yourself: ironically, LAMPPUB is
> never published.
>
> We can have LAMPPUB be 1Mb or even 1Gb long aiming at having rate of
> collision in HL(.) be negligible (note this is perfectly adherent to the
> proposition of memory-hard-hash, and would have the additional benefit of
> allowing processing-storage trade-off). In this case, we really have:
>
> For 1: a pre-image problem for a function
> f1: {k| k is a valid ECCPRI} X {l | l is a valid LAMPPRI} -> {a | a is in the
> format of a ADDR}
>
> having as domain the Cartesian product of set of possible ECCPRIs with set of
> possible LAMPPRIs and counter domain, the set of possible ADDRs.
>
> 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 the singleton containing of only the
> specific LSIG that was actually public, not 'in the format of LSIGs').
>
> Notice that, whatever advantage of 2 over 1 has to be compensated by the
> perspective of having the protocol be successfully terminated before the
> attack being carried out.
>
> For 3: Equivalente of a double-spending attack with, in the worst case, not
> less than (T1-T0-1) blocks in advantage for the rest of the community.
>
> When I have the time, I'll do the math on what is the entropy on each case,
> assuming ideal hashes, but taking for granted the approximation given by
> Boris, we would have half of size of ADDR as strength, not half of LAMPPRI,
> so mission accomplished!
>
> Another ramification of that is we can conceive a multi-use version of this
> scheme, in which LAMPPRI is the ADDR resulting of a previous (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 more
> 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 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 hash chain) to themselves. The # blocks to maturity in your proposal
> > becomes the classic "embargo period" 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
> > bitcoin-dev@lists.linuxfoundation.org wrote:
> >
> > > 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 rainbow table while they made it, which is the
> > > case, since here we have 8*32=256 bits for LSIG, and the entropy of
> > > ECCPUB in the second.
> > >
> > > With rainbow table out of our way, there is only brute-force analysis to
> > > mind. Honestly, Guess I should find a less 'outrageously generous' upper
> > > bound for adversary's model, than just assume they have a magic wand to
> > >
Re: [bitcoin-dev] Swift Activation - CTV
Hi Bitcoin Developers, I think CTV is not ready for activation yet. Although I want it to be activated and use payment pools, we still have some work to do and AJ is correct that we need to build more apps that use CTV on signet. Reasons: - Apart from a few PoCs that do not achieve anything big on mainnet, nobody has tried to build PoC for a use case that solves real problems - There is a bounty of 0.01 BTC to 1 BTC for creating such PoCs: https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/ - Some developers think TXHASH fixes all the issues although it doesn't so they need to be reviewed, tested and discussed - There is no clarity on activation method for CTV - Many users and developers believe timeline for activation is too aggressive, we should be patient and give more time for start and delay activation for 2 years _reardencode_ is working on something which might improve things for CTV and covenants in general. I have created an issue and if someone could close it with a PR that would be helpful: https://github.com/bitcoin-inquisition/bitcoin/issues/44 I apologize if my email caused any drama although most personal attacks were targeted towards people supporting CTV including me. Maybe one day we will have covenants on bitcoin to improve scaling and privacy. /dev/fd0 floppy disk guy Sent with Proton Mail secure email. On Friday, December 22nd, 2023 at 1:56 AM, alicexbt via bitcoin-dev wrote: > Hi Luke, > > This is not the first time I am writing this but you keep ignoring it and > threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its > the best way to activate and share it so that users can run it. > > I had created this branch specifically for it but needed help which I didn't > get: https://github.com/xbtactivation/bitcoin/tree/bip8-ctv > > Discussing trade-offs involved in different activation methods and providing > options to users is not an attack. > > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > > > On Friday, December 22nd, 2023 at 1:05 AM, Luke Dashjr l...@dashjr.org wrote: > > > > > This IS INDEED an attack on Bitcoin. It does not activate CTV - it would > > (if users are fooled into using it) give MINERS the OPTION to activate > > CTV. Nobody should run this, and if it gets any traction, it would > > behoove the community to develop and run a "URSF" making blocks > > signalling for it invalid. > > > > Luke > > > > On 12/19/23 20:44, alicexbt via bitcoin-dev wrote: > > > > > Hello World, > > > > > > Note: This is not an attack on bitcoin. This is an email with some text > > > and links. Users can decide what works best for themselves. There is also > > > scope for discussion about changing method or params. > > > > > > I want to keep it short and no energy left. I have explored different > > > options for activation and this feels the safest at this point in 2023. I > > > have not done any magic or innovation but updated activation params. If > > > you agree with them, please run this client else build your own. Anyone > > > who calls this attack and do not build alternative option is an attack in > > > itself. > > > > > > It activates CTV which is simple covenant proposal and achieves what we > > > expect it to. It is upgradeable. I like simple things, at least to start > > > with. > > > > > > Activation parameters: > > > > > > `consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = > > > 1704067200; > > > consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = > > > 1727740800; > > > consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height > > > = 874874;` > > > > > > I need payment pools and it does it for me. Apart from that it enables > > > vaults, congestion control etc. We have more PoCs for CTV than we had for > > > taproot and I understand it better. > > > > > > If you agree with me, please build and run this client before 01 Jan 2024 > > > else we can discuss ordinals for next 5 years and activate something in > > > 2028. > > > > > > Cheers > > > > > > /dev/fd0 > > > floppy disk guy > > > > > > Sent with Proton Mail secure email. > > > > > > ___ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks
Hi John! I have two questions regarding the window, which are related. 1. Why is the window aligned? IIUC, this means that the blocks mined since the latest block whose height is divisible by window_size do not affect transaction's validity. So a recent change of fees does not reflect if a transaction can be confirmed. 2. Does it make sense to have a global window_size? This would save space in FDT (= in transaction) and simplify verification, especially for a non-aligned window case (see 1). An array of integers of size window_size would be sufficient to give answer to a question if there were at least x blocks among window_size latest blocks with median fee rate <= y, using O(1) time per query. Moving on to another topic, what are the implications for light clients? A light client can validate current timelocks without downloading whole blocks, because they depend on timestamps and block height only, the information from block headers. To validate a transaction with FDT or to choose FDT parameters for its own transaction, a light client would have to determine the median fee rate of the recent blocks. To do that without involving trust, it has to download the blocks. What do you think about including median feerate as a required OP_RETURN output in coinbase transaction? A block without it would be invalid (new consensus rule). A light client can rely on median feerate value from coinbase transaction, downloading only one tx instead of the whole block. On Fri, Dec 15, 2023 at 6:20 AM jlspc via bitcoin-dev wrote: > > TL;DR > = > * All known Lightning channel and factory protocols are susceptible to forced > expiration spam attacks, in which an attacker floods the blockchain with > transactions in order to prevent honest users from putting their transactions > onchain before timelocks expire. > * Feerate-Dependent Timelocks (FDTs) are timelocks that automatically extend > when blockchain feerates spike. > - In the normal case, there's no spike in feerates and thus no tradeoff > between capital efficiency and safety. > - If a dishonest user attempts a forced expiration spam attack, feerates > increase and FDTs are extended, thus penalizing the attacker by keeping their > capital timelocked for longer. > - FDTs are tunable and can be made to be highly resistant to attacks from > dishonest miners. > * Of separate interest, an exact analysis of the risk of double spend attacks > is presented that corrects an error in the original Bitcoin whitepaper. > > Overview > > > Because the Lightning protocol relies on timelocks to establish the correct > channel state, Lightning users could lose their funds if they're unable to > put their transactions onchain quickly enough. > The original Lightning paper [1] states that "[f]orced expiration of many > transactions may be the greatest systemic risk when using the Lightning > Network" and it uses the term "forced expiration spam" for an attack in which > a malicious party "creates many channels and forces them all to expire at > once", thus allowing timelocked transactions to become valid. > That paper also says that the creation of a credible threat against "spamming > the blockchain to encourage transactions to timeout" is "imperative" [1]. > > Channel factories that create multiple Lightning channels with a single > onchain transaction [2][3][4][5] increase this risk in two ways. > First, factories allow more channels to be created, thus increasing the > potential for many channels to require onchain transactions at the same time. > Second, channel factories themselves use timelocks, and thus are vulnerable > to a "forced expiration spam" attack. > > In fact, the timelocks in Lightning channels and factories are risky even > without an attack from a malicious party. > Blockchain congestion is highly variable and new applications (such as > ordinals) can cause a sudden spike in congestion at any time. > As a result, timelocks that were set when congestion was low can be too short > when congestion spikes. > Even worse, a spike in congestion could be self-reinforcing if it causes > malicious parties to attack opportunistically and honest parties to put their > channels onchain due to the heightened risk. > > One way to reduce the risk of a forced expiration spam attack is to use > longer timelocks that give honest users more time to put their transactions > onchain. > However, long timelocks limit the ability to dynamically reassign the > channel's (or factory's) funds, thus creating a tradeoff between capital > efficiency and safety [6]. > While long timelocks could maintain safety for small numbers of channels, > supporting billions (or tens of billions) of channels while maintaining > safety is probably impossible [7]. > > Another way to reduce risk is to impose a penalty on an attacker. > Some channel protocols, such as the original Lightning protocol [1], a > version of the two-party eltoo protocol [8], the
