Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Sun, Jan 14, 2024 at 10:21 AM Greg Tonoski via bitcoin-dev wrote: > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > irrespectively of location inside or outside of witness), e.g. 205/205 > > and 767/767 bytes in the examples above. > > > > "Should" ... to what end? > > "Should" in order to avoid hazard of centralization. A single bidder > who takes advantage of "buy 1 get 3 megabytes free" may outcompete a > number of individuals whose simple transactions recieve > anti-preferential treatment - "buy 1 get 0.33 megabytes free" in > aggregate. There is the illustration at: > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf";. It is not sufficient to be a centralized sender to utilize this advanage. The sender has to store data in the blockchain which itself is not the best utilization of money, even given the discount. Also what is the danger of centralization of such senders? The dangerous centralization is the centralization of real bitcoin sending, which has already happened - exchanges utilize batch transaction sending, saving on fees over a regular bitcoin sender, because they avoid change creation. This has nothing to do with witness discount, though. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Sat, Jan 13, 2024 at 12:03 PM Greg Tonoski wrote: > > On Wed, Dec 27, 2023 at 8:06 PM Nagaev Boris wrote: > > > > On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev > > wrote: > > > As a result, there are incentives structure distorted and critical > > > inefficiencies/vulnerabilities (e.g. misallocation of block space, > > > blockspace value destruction, disincentivized simple transaction, > > > centralization around complex transactions originators). > > > > > > Price of blockspace should be the same for any data (1 byte = 1 byte, > > > irrespectively of location inside or outside of witness), e.g. 205/205 > > > and 767/767 bytes in the examples above. > > > > Witness data does not contribute to utxo set. The discount on storing > > data in witness creates an incentive to store data exactly in the > > witness and not in the parts contributing to utxo set. > > > > $ du -sh blocks/ chainstate/ > > 569Gblocks/ > > 9.3Gchainstate/ > > > > Witness data is part of the "blocks" directory which is not > > latency-critical and can be stored on a slow and cheap storage device. > > Directory "chainstate" contains the data needed to validate new > > transactions and should fit into a fast storage device otherwise > > initial block download takes weeks. It is important to maintain the > > incentives structure, resulting in a small chainstate. > > I think that the argument "discount on storing data in witness creates > an incentive to store data exactly in the witness (...)" is > fallacious. The "witness discount" does not affect the cost of data > storage in a Bitcoin node. What the "witness discount" affects is the > priority of a transaction pending confirmation only. For example, a > SegWit type of transaction of size of 1MB is prioritized (by miners) > over a non-SegWit transaction of the same size and fee. "Segwit > discount" benefits bloated transactions and puts simple transactions > at disadvantage (demonstrated at > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/comparison-of-costs.html"; > and > "https://gregtonoski.github.io/bitcoin/segwit-mispricing/Comparison_of_4MB_and_1.33MB_blocks_in_Bitcoin.pdf";). > > The Bitcoin fee is not charged per UTXO set size. It is not charged > from a node operator. Nodes are up and running independently of > Bitcoin fees. > > Any relation between UTXO set size and discount would be artificial > and inefficient, wouldn't it? Node operators are likely to put UTXO set to SSD and blocks to HDD. SSD is more expensive than HDD. It is aligned with the fact that people putting data into blockchain are financially motivated to put it into witness data, i.e. into HDD. If miners charge the same per 1 byte in a transaction output and 1 byte in witness, then people putting data into blockchain could put it into transaction outputs (why not, if the price is the same), inflating the UTXO set and making node operators buy bigger SSD (more costs for node operators). As a node operator, I prefer the current structure. -- Best regards, Boris Nagaev ___ 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
On Sat, Dec 30, 2023 at 12:11 AM David A. Harding wrote: > > On 2023-12-29 15:17, Nagaev Boris wrote: > > Feerate-Dependent Timelocks do create incentives to accept out-of-band > > fees to decrease in-band fees and speed up mining of transactions > > using FDT! Miners can make a 5% discount on fees paid out-of-band and > > many people will use it. Observed fees decrease and FDT transactions > > mature faster. It is beneficial for both parties involved: senders of > > transactions save 5% on fees, miners get FDT transactions mined faster > > and get more profits (for the sake of example more than 5%). > > Hi Nagaev, > > That's an interesting idea, but I don't think that it works due to the > free rider problem: miner Alice offers a 5% discount on fees paid out of > band now in the hopes of collecting more than 5% in extra fees later due > to increased urgency from users that depended on FDTs. However, > sometimes the person who actually collects extra fees is miner Bob who > never offered a 5% discount. By not offering a discount, Bob earns more > money on average per block than Alice (all other things being equal), > eventually forcing her to stop offering the discount or to leave the > market. > > Additionally, if nearly everyone was paying discounted fees out of band, > participants in contract protocols using FDTs would know to use > proportionally higher FDT amounts (e.g. 5% over their actual desired > fee), negating the benefit to miners of offering discounted fees. > > -Dave Good points. It makes sense! -- Best regards, Boris Nagaev ___ 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
Hey David! On Fri, Dec 29, 2023 at 9:37 PM David A. Harding via bitcoin-dev wrote: > We can't prevent people from paying out of band, but we can ensure that > the easiest and most effective way to pay for a transaction is through > in-band fees and transactions that are relayed to every miner who is > interested in them. If we fail at that, I think Bitcoin losing its > censorship resistance will be inevitable. LN, coinpools, and channel > factories all strongly depend on Bitcoin transactions not being > censored, so I don't think any security is lost by redesigning them to > additionally depend on reasonably accurate in-band fee statistics. Feerate-Dependent Timelocks do create incentives to accept out-of-band fees to decrease in-band fees and speed up mining of transactions using FDT! Miners can make a 5% discount on fees paid out-of-band and many people will use it. Observed fees decrease and FDT transactions mature faster. It is beneficial for both parties involved: senders of transactions save 5% on fees, miners get FDT transactions mined faster and get more profits (for the sake of example more than 5%). -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
On Fri, Dec 29, 2023 at 1:34 PM Greg Tonoski via bitcoin-dev wrote: > There is significant difference when storing data as dummy signatures > (or OP_RETURN) which is much more expensive than (discounted) witness. > Witness would not have been chosen as the storage of arbitrary data if > it cost as much as alternatives, e.g. OP_RETURN. Hi Greg! How about storing data in multisig signatures? Make a 1/n multisig and store the data in (n-1) dummy public keys. It is stored in witness and is quite efficient and hard to filter out only if together with legitimate multisigs. Another smart place for hidden data is Merkle proof in Taproot. The depth is limited to 128 levels, so put 1 valid leaf and add data to 127 fake elements to calculate the Merkle root. I think there are more ways like this. If the current place is banned, they can always waste money in other parts of bitcoin transactions. It is impossible to stop someone who can afford to waste money from doing it. (Well, it is, but not in a decentralized voluntary way of Bitcoin.) My approach is just to wait for them to run out of money and use Lightning Network for payments meanwhile. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BUG]: Bitcoin blockspace price discrimination put simple transactions at disadvantage
On Wed, Dec 27, 2023 at 2:26 PM Greg Tonoski via bitcoin-dev wrote: > As a result, there are incentives structure distorted and critical > inefficiencies/vulnerabilities (e.g. misallocation of block space, > blockspace value destruction, disincentivized simple transaction, > centralization around complex transactions originators). > > Price of blockspace should be the same for any data (1 byte = 1 byte, > irrespectively of location inside or outside of witness), e.g. 205/205 > and 767/767 bytes in the examples above. Witness data does not contribute to utxo set. The discount on storing data in witness creates an incentive to store data exactly in the witness and not in the parts contributing to utxo set. $ du -sh blocks/ chainstate/ 569Gblocks/ 9.3Gchainstate/ Witness data is part of the "blocks" directory which is not latency-critical and can be stored on a slow and cheap storage device. Directory "chainstate" contains the data needed to validate new transactions and should fit into a fast storage device otherwise initial block download takes weeks. It is important to maintain the incentives structure, resulting in a small chainstate. -- Best regards, Boris Nagaev ___ 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 ful
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
Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 clarity: > > HL(.) = serial-work- and memory-*hard* hash with *short* digest (ex.: Argon2 > with ~ 12 bytes output. "L" for "Lamport"); > HC(.) = nonspecific representation of conventional, serial-work- and > memory-*easy* hashes with *long* (brute-force-resistant) digest length. "C" > for "Conventional"; > KDF(.) = conventional key deriving function > ECCPUB = public key correspondent to ECCPRI > ECCPRI = KDF(seed, tag) //conventional BTC signing key (could be Schnorr > instead) > LAMPPUB = HL(LAMPPRIi) > LAMPPRI = HL(seed, tag) //Though it is (more) feasible to crack a seed S that > works as pre-image to LAMPRI, such seed can only be deemed valid if the > public key correspondent to KDF(s) = ECCPUB, so ultimately, cracking seed is > still as hard as cracking a conventional seed. > ADDR = H(ECCPUB, LAMPPUB) //Conventional BTC key fingerprinting with > conventionally used hashes and their respective brute-force-resistant digest > lengths > TX = plaintext transaction > LSIG = HL(TX, LAMPPRI) > COMMITMENT = Smart contract stating "This UTXO is frozen until one of the > following happens: A) publishing of a L such that HL(TX,L) = LSIG before T2 > in which case TX is deemed valid and executed, or B) T2 blocks from now, when > miner of LSIG has gets F1+FF1, and the miner of COMMITMENT gets FC, both from > UTXO" > BL = "Bundle of Lamport scheme" = (TX, LSIG) > BC = "Bundle of Commitment and Conventional Signing" = (COMMITMENT, > ECCPRI(COMMITMENT), ECCPUB, LAMPPUB)//LAMPPUB is added here to allow > easy verification that ECCPUB corresponds to ADDR > BT = "Total Bundle" = (BL, BC) > F1 = fee offered to mine BL > FF1 = fine offered to miner of BL to compensate for delay > FC = fee offered to mine BC in case of default > T0 = Block height of broadcasting of BT > T1 = Block height owner should aim at broadcasting LAMPPRI block ~ T0+1 to > T0+6 blocks. This is to protect owner from dissensus (revealing LAMPPRI in a > block and have it utilized to forge transaction in a competing block of same > height). > T2 = Block height of expiration of commitment ~ T0+24 hours to T0+ a few days > to protect user from execution of commitment being triggered by innocent > unavailability. > > From ADDR alone, Miners, cannot forge a valid LSIG, nor try to ascertain > LAMPPUB or LAMPPRI, because of pre-image-resistance of H(.) and brute-force > resistance of ECCPUB before being published. The saving happens because, safe > from T2 passing without LAMPRI being broadcasted, only BL and LAMPPR, and not > BC, end up in Blockchain. > > The proposed scheme, therefore allows for only 1 instance of Lamport > schemed-based economic transaction, which has to be the first transaction of > ADDR (because of publishing of ECCPUB). After this first transaction, ADDR is > stil valid, just no longer able to issue transactions. > > The proposed scheme, therefore, favors the good practice of non-address reuse. > > YSVB > Thank you for the great explanation, Yuri! Let's make sure we are on the same page. I calculated the on-chain footprint of signatures of the proposed scheme and compared it with schnorr keys as are used in taproot. Lamport scheme, the case no ECC signature is published: - output: 20 bytes. ADDR = H(ECCPUB, LAMPPUB) - input 1: LSIG (14 bytes) - input 2: ECCPUB, LAMPPRI (32+14=46). (ECCPUB is needed to verify hashing to ADDR; LAMPPUB is not needed onchain, because it is a hash of LAMPPRI.) Total onchain footprint: 20+14+46=80 (bytes) Is this correct? Taproot: - output: 32 bytes (schnorr public key) - input: 64 bytes (schnorr signature) Total: 32+64 = 96 (bytes) Some additional space is needed in the lamport scheme case to address T0 from T1 and to have T1 in the first place. Tx overhead is around 10 bytes and say 6 bytes for the reference. It looks, the footprint will be the same. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 next block. What if an attacker broadcasts the first bundle? He spent a lot of time cracking the hash which is the part of the address in the proposed scheme. Then he cracked the second layer of hashing to have both hashes ready. If the utxo has enough sats, the attack is economically viable. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
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 > is, in fact, successfully broadcasted before maturity, commitment, the only > ECC signature in this protocol is discarded, and only two Lamport hashes end > up being buried at L1. Two SHA256 hashes are 64 bytes in total, the same as one schnorr signature. > To push economy even further, we could implement a memory-hard hash like > Argon2 to do the same entropy-processing trade-off already utilized for > passwords, so we could have hashes of, say 12 bytes, making it 24 in total 12 bytes security for spending bitcoins is not enough, is it? -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks
On Sun, Dec 17, 2023 at 1:47 PM ArmchairCryptologist via bitcoin-dev wrote: > Critically, this means that the higher the ratio of the hashrate is > participating, the lower the cost of the attack. If 100% of miners > participate with a ratio of transactions equal to their hashrate, the cost of > the attack is zero, since every participating miner will get back on average > 100% of the fees they contributed, and 0% of the fees will be lost to honest > miners (of which there are none). It would not be an equilibrium, because each of them can increase his profit by not participating. He can still collect fees from fee-stuffing transactions of others and high fees from transactions of normal users. > Observe also that miners would not have to actively coordinate or share funds > in any way to participate. If a miner with 10% of the participating hashrate > contributes 10% of the fee-stuffing transactions, they would also get back on > average 10% of the total fees paid by transactions that are included in > blocks mined by participating miners, giving them 10% of the profits. As > such, each participating miner would simply have to watch the mempool to > verify that the other participating miners are still broadcasting their > agreed rate/ratio of transactions, the rest should average out over time. He can pretend to have less hashrate and mine some blocks under the table. For example, a miner who has 10% real hash rate could say to other colluding miners that he only has 5%. Another 5% are secretly allocated to a new pool. So his share of costs of fee-stuffing transactions decreases, while he actually collects the same amount of fees using both public and secret parts of his hash rate. Eventually every rational participant of this collusion will do this and the ratio of participating miners will decrease. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
