Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 > convert SHA256 ASICS into CPU with the same hashrate for memory- and > serial-work-hard hashes (therefore giving away hash hardness). That's > because with such 'magic wand' many mining pools would, not only be capable > of cracking 2^48 hashes far within the protocol's prescribed 48 hours, but > also 2^64 within a block time, which would invalidate a lot of what is > still in use today. > > Please, allow me a few days to think that through. > > YSVB > > Sent with Proton Mail secure email. > > On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris < > bnag...@gmail.com> wrote: > > > > On Tue, Dec 19, 2023 at 6:22 PM yuri...@pm.me 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 is 2*(14-12) = 4 bytes less. > > > > > > I agree. It should have been 12. > > > > > 2) Thank you for pointing out that ECCPUB is necessary. That's exactly > right and I failed to realize that. To lessen the exposure, and the risk of > miner of LSIG, it can be left to be broadcast together with LAMPPRI. > > > > > > 3) I avail to advocate for economizing down the fingerprint to just > 128 bits for the weakest-link-principle, since 128 bits is a nearly > ubiquitous standard, employed even by the majority of seeds. Not an > argument against plain Schnorr, because Schnorr keys could use it too, but, > compared with current implementations, we have that would be 20-16=4 bytes > less. > > > > > > I think that the digest size for hash should be 2x key size for > > symmetric encryption. To find a collision (= break) for a hash > > function with digest size 128 bits one needs to calculate ~ 2^64 > > hashes because of the birthday paradox. > > > > > 4) [Again, argument against plain, because it cuts for both sides:] To > economize even further, there is also the entropy-derivation cost trade-off > of N times costlier derivation for log2(N) less bits. If applied to the > Address, we could shave away another byte. > > > > > > 5) T0 is just the block height of burying of LSIG doesn't need to be > buried. T2 can perfectly be hard-coded to always be the block equivalent of > T0 + 48 hours (a reasonable spam to prevent innocent defaulting on > commitment due to network unavailability). T1 is any value such as T0 < T1 > < T2, (typically T1 <= T0+6) of user's choosing, to compromise between, on > one hand, the convenience of unfreezing UTXO and having TX mining completed > ASAP and, on the other, avoiding the risk of blockchain forking causing > LAMPPRI to be accidentally leaked in the same block height as LSIG, which > allows for signatures to be forged. So this is 16 bytes less. > > > > > > Miners would keep record of unconfirmed BL's, because of the reward of > mining either possible outcome of it (successful transaction or execution > of commitment). Everything is paid for. > > > > > > So, unless I'm forgetting something else, all other variables kept > equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes less the > current implementation of Schnorr, if items 3 and 4 are implemented too. > Already we have a reduction of between 21% and 26%, while, so far, nobody > in the mailing list has disputed how 'outrageously' conservative the 12 > bytes figure is. > > > > > > 26% reduction of block space utilization would be great, but the price > > of relying on 12 bytes hashes (only need 2^48 hashes to find a > > collision) is too much for that, IMHO. > > > > Another consideration is about 12 byte hashes. Let's try to figure out
Re: [bitcoin-dev] Swift Activation - CTV
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
Re: [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
> Bob can craft a HTLC-preimage spend of the single offered output spending one > of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the > value as fee. This replaces out Alice's honest HTLC-timeout out of network > mempools, are they're concurrent spend. Bob can repeat this trick as long as > there is HTLC "payout" remaining in the offered set, until he's being able to > do a HTLC off-chain double-spend of the 1 BTC HTLC "payout". What do you mean by "do a HTLC off-chain double-spend of the 1 BTC HTLC"? Agreed on every detail up to this point. Note that every time Bob replaces Alice's timeout tx, he reveals a preimage that Alice can use to settle her incoming HTLC, so for those Alice loses nothing, Bob loses the HTLC value to fees. I believe for Bob to be able to profit from this, he would need to delay all of Alice's transactions until the timelock on Alice's incoming HTLC expires (CLTV delta blocks). Is this what you mean by "off-chain double spend"? Anyways, this means that Bob will have to pay ~next block fees each block in the delta period (assuming Alice is eager to get into the block since the timelocks are expiring on her incoming HTLCs), and burn the value of an HTLC for every such transaction. However, I think it is possible to make this very risky for Bob to play out, based on a simple fact: Alice can claim all the expired HTLCs cheaply (1 input 1 output tx, no merkle paths or preimages needed), and she is game theoretically willing to burn almost all of it to fees to get it confirmed before expiry. So for the last 1 BTC HTLC, she could pay ~0.9 BTC to fees, which Bob couldn't compete with by burning the much smaller HTLCs. However, Bob could of course grief Alice by making her do this, but unsure if that's rational. On Sun, Dec 17, 2023 at 11:56 PM Antoine Riard wrote: > > Hi Johan, > > > Is this a concern though, if we assume there's no revoked state that > > can be broadcast (Eltoo)? Could you share an example of how this would > > be played out by an attacker? > > Sure, let's assume no revoked state can be broadcast (Eltoo). > > My understanding of the new covenant mechanism is the aggregation or > collapsing of all HTLC outputs in one or at least 2 outputs (offered / > received). > Any spend of an aggregated HTLC "payout" should satisfy the script locking > condition by presenting a preimage and a signature. > An offerd aggregated HTLC output might collapse a M number of HTLC "payout", > where M is still limited by the max standard transaction relay, among other > things. > > The offered-to counterparty can claim any subset N of the aggregation M by > presenting the list of signatures and preimages (How they're feeded to the > spent script is a covenant implementation detail). However, there is no > guarantee that the offered-to counterparty reveal "all" the preimages she is > awarded off. Non-spent HTLC outputs are clawback to a remainder subset of M, > M'. > > I think this partial reveal of HTLC payout preimages still opens the door to > replacement cycling attacks. > > Let's say you have 5 offered HTLC "payouts" between Alice and Bob aggregated > in a single output, 4 of value 0.1 BTC and 1 of value 1 BTC. All expire at > timelock T. > At T, Alice broadcasts an aggregated HTLC-timeout spend for the 5 HTLC with > 0.0.1 BTC on-chain fee. > > Bob can craft a HTLC-preimage spend of the single offered output spending one > of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the > value as fee. This replaces out Alice's honest HTLC-timeout out of network > mempools, are they're concurrent spend. Bob can repeat this trick as long as > there is HTLC "payout" remaining in the offered set, until he's being able to > do a HTLC off-chain double-spend of the 1 BTC HTLC "payout". > > This stealing gain of the 1 BTC HTLC "payout" covers what has been burned as > miners fees to replace cycle out Alice's sequence of honest HTLC-timeout. > > And it should be noted that Bob might benefit from network mempools > congestion delaying the confirmation of his malicious low-value high-fee > HTLC-preimage transactions. > > > I'm not sure what you mean here, could you elaborate? > > See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022191.html > and my answer there. > I think "self-sustained" fees is one only part of the solution, the other > part being the sliding delay of the HTLC timelock based on block feerate. > Otherwise, a replacement cycling attacker can always benefit from network > mempools congestion spontaneously pushing out a malicious cycling transaction > out of block templates. > > > That sounds possible, but how would you deal with the exponential > > blowup in the number of combinations? > > In a taproot-world, "swallow the bullet" in terms of witness size growth in > case of non-cooperative closure. > I think this is where introducing an accumulator at the Script level to > efficiently
Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 convert SHA256 ASICS into CPU with the same hashrate for memory- and serial-work-hard hashes (therefore giving away hash hardness). That's because with such 'magic wand' many mining pools would, not only be capable of cracking 2^48 hashes far within the protocol's prescribed 48 hours, but also 2^64 within a block time, which would invalidate a lot of what is still in use today. Please, allow me a few days to think that through. YSVB Sent with Proton Mail secure email. On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris wrote: > On Tue, Dec 19, 2023 at 6:22 PM yuri...@pm.me 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 is > > 2*(14-12) = 4 bytes less. > > > I agree. It should have been 12. > > > 2) Thank you for pointing out that ECCPUB is necessary. That's exactly > > right and I failed to realize that. To lessen the exposure, and the risk of > > miner of LSIG, it can be left to be broadcast together with LAMPPRI. > > > > 3) I avail to advocate for economizing down the fingerprint to just 128 > > bits for the weakest-link-principle, since 128 bits is a nearly ubiquitous > > standard, employed even by the majority of seeds. Not an argument against > > plain Schnorr, because Schnorr keys could use it too, but, compared with > > current implementations, we have that would be 20-16=4 bytes less. > > > I think that the digest size for hash should be 2x key size for > symmetric encryption. To find a collision (= break) for a hash > function with digest size 128 bits one needs to calculate ~ 2^64 > hashes because of the birthday paradox. > > > 4) [Again, argument against plain, because it cuts for both sides:] To > > economize even further, there is also the entropy-derivation cost trade-off > > of N times costlier derivation for log2(N) less bits. If applied to the > > Address, we could shave away another byte. > > > > 5) T0 is just the block height of burying of LSIG doesn't need to be > > buried. T2 can perfectly be hard-coded to always be the block equivalent of > > T0 + 48 hours (a reasonable spam to prevent innocent defaulting on > > commitment due to network unavailability). T1 is any value such as T0 < T1 > > < T2, (typically T1 <= T0+6) of user's choosing, to compromise between, on > > one hand, the convenience of unfreezing UTXO and having TX mining completed > > ASAP and, on the other, avoiding the risk of blockchain forking causing > > LAMPPRI to be accidentally leaked in the same block height as LSIG, which > > allows for signatures to be forged. So this is 16 bytes less. > > > > Miners would keep record of unconfirmed BL's, because of the reward of > > mining either possible outcome of it (successful transaction or execution > > of commitment). Everything is paid for. > > > > So, unless I'm forgetting something else, all other variables kept equal, > > we have 20 bytes lighter than Schnorr; and up to 25 bytes less the current > > implementation of Schnorr, if items 3 and 4 are implemented too. Already we > > have a reduction of between 21% and 26%, while, so far, nobody in the > > mailing list has disputed how 'outrageously' conservative the 12 bytes > > figure is. > > > 26% reduction of block space utilization would be great, but the price > of relying on 12 bytes hashes (only need 2^48 hashes to find a > collision) is too much for that, IMHO. > > Another consideration is about 12 byte hashes. Let's try to figure out > if they are resistant to rainbow table attack by a large organization. > Let's assume that the rainbow table has a chain length of 1024^3 (billion). > What storage size is needed? 2^96 * 12 / 1024^3 = 900 exabytes. > Both chain length and storage size seems prohibitively high for today, > but tomorrow the hash function can be optimized, memory can be > optimized, storage can become cheaper etc. And this attack may be > affordable for state level attackers. > > > Any other objections? > > > > YSVB > > > > -- > Best regards, > Boris Nagaev publickey - yurisvb@pm.me - 0x535F445D.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital
Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation
Hi Peter, > Obviously a local replacement cache is a possibility. The whole point of my > email is to show that a local replacement cache isn't necessarily needed, as > any alturistic party can implement that cache for all nodes. Sure, note as soon as you start to introduce an altruistic party rebroadcasting for everyone in the network, we're talking about a different security model for time-sensitive second-layers. And unfortunately, one can expect the same dynamics we're seeing with BIP157 filter servers, a handful of altruistic nodes for a large swarm of clients. > 1) That is trivially avoided by only broadcasting txs that meet the local > mempool min fee, plus some buffer. There's no point to broadcasting txs that > aren't going to get mined any time soon. > > 2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the feefilter > P2P message to tell peers not to send transactions below a threshold fee rate. > > https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki I know we can introduce BIP-133 style of filtering here only the top % of the block template is altruistically rebroadcast. I still think this is an open question how a second-layer node would discover the "global" mempool min fee, and note an adversary might inflate the top % of block template to prevent rebroadcast of malicious HTLC-preimage. > Did you actually read my email? I worked out the budget required in a > reasonable worst case scenario: Yes. I think my uncertainty lies in the fact that an adversary can rebroadcast _multiple_ times the same UTXO amount under different txids, occupying all your altruistic bandwidth. Your economic estimation makes an assumption per-block (i.e 3.125 BTC / 10 minutes). Where it might be pernicious is that an adversary should be able to reuse those 3.125 BTC of value for each inter-block time. Of course, you can introduce an additional rate-limitation per-UTXO, though I think this is very unsure how this rate-limit would not introduce a new pinning vector for "honest" counterparty transaction. > Here, we're talking about an attacker that has financial resources high enough > to possibly do 51% attacks. And even in that scenario, storing the entire > replacement database in RAM costs under $1000 > The reality is such an attack would probably be limited by P2P bandwidth, not > financial resources, as 2MB/s of tx traffic would likely leave mempools in an > somewhat inconsistent state across the network due to bandwidth limitations. > And that is *regardless* of whether or not anyone implements alturistic tx > broadcasting. Sure, I think we considered bandwidth limitations in the design of the package relay. Though see my point above, the real difficulty in your proposed design sounds to me in the ability to reuse the same UTXO liquidity for an unbounded number of concurrent replacement transactions exhausting all the altruistic bandwidth. One can just use a 0.1 BTC UTXO and just fan-out 3.125 BTC of concurrent replacement transactions from then. So I don't think the assumed adversary financial resources are accurate. I think the best long-term way to fix replacement cycling is still more in the direction of things like: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022191.html With the additional constraint of removing package malleability, where all the feerate is coming from package self-contained fee-bumping reserves UTXOs. Best, Antoine Le dim. 17 déc. 2023 à 10:57, Peter Todd a écrit : > On Fri, Dec 15, 2023 at 10:29:22PM +, Antoine Riard wrote: > > Hi Peter, > > > > > Altruistic third parties can partially mitigate replacement cycling(1) > > attacks > > > by simply rebroadcasting the replaced transactions once the replacement > > cycle > > > completes. Since the replaced transaction is in fact fully valid, and > the > > > "cost" of broadcasting it has been paid by the replacement > transactions, > > it can > > > be rebroadcast by anyone at all, and will propagate in a similar way to > > when it > > > was initially propagated. Actually implementing this simply requires > code > > to be > > > written to keep track of all replaced transactions, and detect > > opportunities to > > > rebroadcast transactions that have since become valid again. Since any > > > interested third party can do this, the memory/disk space requirements > of > > > keeping track of these replacements aren't important; normal nodes can > > continue > > > to operate exactly as they have before. > > > > I think there is an alternative to altruistic and periodic rebroadcasting > > still solving replacement cycling at the transaction-relay level, namely > > introducing a local replacement cache. > > > > https://github.com/bitcoin/bitcoin/issues/28699 > > > > One would keep in bounded memory a list of all seen transactions, which > > have entered our mempool at least once at current mempool min fee. > > Obviously a local replacement cache is a possibility. The whole point of
[bitcoin-dev] libsecp256k1 v0.4.1 released
Hello, Today we'd like to announce the release of version 0.4.1 of libsecp256k1: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.1 This release slightly increases the speed of the ECDH operation and significantly enhances the performance of many library functions when using the default configuration on x86_64. For a list of changes, see the CHANGELOG.md: https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
Hi Peter, Thanks for spending time thinking about RBF pinning and v3. > Enter Mallory. His goal is to grief Alice by forcing her to spend more money than she intended... > ...Thus the total fee of Mallory's package would have > been 6.6 * 1/2.5 = 2.6x more than Alice's total fee, and to get her transaction > mined prior to her deadline, Alice would have had to pay a 2.6x higher fee than > expected. I think this is a good understanding of the goal of Rule #3, but I'm not sure how you're getting these numbers without specifying the size and fees of the commitment transaction. We should also quantify the severity of the "damage" of this pin in a meaningful way; the issue of "Alice may need to pay to replace descendant(s) she isn't aware of" is just a property of allowing unconfirmed descendants. Let's use some concrete numbers with your example. As you describe, we need 80-162sat/vB to get into the next block, and Alice can fund a CPFP with a 152vB CPFP. Let's say the commitment transaction has size N, and pays 0 fees. The lower number of 80sat/vB describes what Mallory needs to shoot below in order to "pay nothing" for the attack (i.e. otherwise it's a CPFP and gets the tx confirmed). Mallory can maximize the cost of replacement according to Rule #3 by keeping a low feerate while maximizing the size of the tx. The higher number of 162sat/vB describes the reasonable upper bound of what Alice should pay to get the transactions confirmed. As in: If Alice pays exactly 162sat/vB * (N + 152vB) satoshis to get her tx confirmed, nothing went wrong. She hopes to not pay more than that, but she'll keep broadcasting higher bumps until it confirms. The "damage" of the pin can quantified by the extra fees Alice has to pay. For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can increase the cost of replacement to 80,000sat. For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing out the descendant limit. Rule #4 is pretty negligible here, but since you've already specified Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a replacement. Let's say N is 1000vB. AFAIK commitment transactions aren't usually smaller than this: - Alice is happy to pay 162sat/vB * (1000 + 152vB) = 186,624sat - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + 152 = 80,152sat - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (100,000vB) + 152 = 8,000,152sat - Mallory does succeed, Alice would need to pay ~7 million sats extra Let's say N is 10,000vB: - Alice is happy to pay 162sat/vB * (10,000 + 152vB) = 1,644,624 - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + 152 = 80,152sat - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (91,000vB) + 152 = 7,280,152sat - Mallory does succeed Alice would need to pay ~5 million sats extra Let's say N is 50,000vB: - Alice is happy to pay 162sat/vB * (50,000 + 152vB) = 8,124,624 - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + 152 = 80,152sat - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (51,000vB) + 152 = 4,080,152sat - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement - The key idea here is that there isn't much room for descendants and the cost to CPFP is very high These numbers change if you tweak more variables - the fees paid by the commitment tx, the feerate range, etc. But the point here is to reduce the potential "damage" by 100x by restricting the allowed child size. > If V3 children are restricted to, say, 200vB, the attack is much less effective as the ratio of Alice vs Mallory size is so small. This is exactly the idea; note that we've come from 100KvB to 1000vB. > Mallory can improve the efficiency of his griefing attack by attacking multiple > targets at once. Assuming Mallory uses 1 taproot input and 1 taproot output for > his own funds, he can spend 21 ephemeral anchors in a single 1000vB > transaction. Note that v3 does not allow more than 1 unconfirmed parent per tx. Let me know if I've made an arithmetic error, but hopefully the general idea is clear. Best, Gloria On Wed, Dec 20, 2023 at 5:16 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > V3 transactions(1) is a set of transaction relay policies intended to aim > L2/contracting protocols, namely Lightning. The main aim of V3 > transactions is > to solve Rule 3 transaction pinning(2), allowing the use of ephemeral > anchors(3) that do not contain a signature check; anchor outputs that _do_ > contain a signature check are not vulnerable to pinning attacks, as only > the > intended party is able to spend them while unconfirmed. > > The main way that
Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 is > 2*(14-12) = 4 bytes less. I agree. It should have been 12. > 2) Thank you for pointing out that ECCPUB is necessary. That's exactly right > and I failed to realize that. To lessen the exposure, and the risk of miner > of LSIG, it can be left to be broadcast together with LAMPPRI. > > 3) I avail to advocate for economizing down the fingerprint to just 128 bits > for the weakest-link-principle, since 128 bits is a nearly ubiquitous > standard, employed even by the majority of seeds. Not an argument against > plain Schnorr, because Schnorr keys could use it too, but, compared with > current implementations, we have that would be 20-16=4 bytes less. I think that the digest size for hash should be 2x key size for symmetric encryption. To find a collision (= break) for a hash function with digest size 128 bits one needs to calculate ~ 2^64 hashes because of the birthday paradox. > 4) [Again, argument against plain, because it cuts for both sides:] To > economize even further, there is also the entropy-derivation cost trade-off > of N times costlier derivation for log2(N) less bits. If applied to the > Address, we could shave away another byte. > > 5) T0 is just the block height of burying of LSIG doesn't need to be buried. > T2 can perfectly be hard-coded to always be the block equivalent of T0 + 48 > hours (a reasonable spam to prevent innocent defaulting on commitment due to > network unavailability). T1 is any value such as T0 < T1 < T2, (typically T1 > <= T0+6) of user's choosing, to compromise between, on one hand, the > convenience of unfreezing UTXO and having TX mining completed ASAP and, on > the other, avoiding the risk of blockchain forking causing LAMPPRI to be > accidentally leaked in the same block height as LSIG, which allows for > signatures to be forged. So this is 16 bytes less. > > Miners would keep record of unconfirmed BL's, because of the reward of mining > either possible outcome of it (successful transaction or execution of > commitment). Everything is paid for. > > So, unless I'm forgetting something else, all other variables kept equal, we > have 20 bytes lighter than Schnorr; and up to 25 bytes less the current > implementation of Schnorr, if items 3 and 4 are implemented too. Already we > have a reduction of between 21% and 26%, while, so far, nobody in the mailing > list has disputed how 'outrageously' conservative the 12 bytes figure is. 26% reduction of block space utilization would be great, but the price of relying on 12 bytes hashes (only need 2^48 hashes to find a collision) is too much for that, IMHO. Another consideration is about 12 byte hashes. Let's try to figure out if they are resistant to rainbow table attack by a large organization. Let's assume that the rainbow table has a chain length of 1024^3 (billion). What storage size is needed? 2^96 * 12 / 1024^3 = 900 exabytes. Both chain length and storage size seems prohibitively high for today, but tomorrow the hash function can be optimized, memory can be optimized, storage can become cheaper etc. And this attack may be affordable for state level attackers. > Any other objections? > > YSVB > -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Swift Activation - CTV
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
