Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/2017 04:27 PM, Emin Gün Sirer wrote: > Because there's no consensus on the contents of the mempool, this approach > is unsafe and will lead to forks. It also opens a new attack vector where > people can time the flood of new transactions with the discovery of a block > by a competitor, to orphan the block and to fork the chain. > I know this is a delayed reply. Without intending to revive an older thread, my intentions are to clarify what I have meant in my original post just in case anyone misinterprets where I said "For example would be something like this: If block = (empty OR <%75 of mempool) THEN discard This threshold just an example." I should have clarified that with this idea blocks would not be rejected if does not match what that nodes have in their mempool, because as you have said, there is no consensus on the contents of mempool and the mempool will vary from node to node. Instead what I have meant is that with this idea, nodes would only reject blocks if they are empty or less than a determined percentage when compared to what is in mempool. While this specific defense proposal I posted may or may not be a good idea, was only throwing this idea out there to create discussion on possible defenses against an empty or near empty block attack. - -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: can...@cannon-ciota.info NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. If this matters to you, use PGP. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY8DIZAAoJEAYDai9lH2mwZKYP/jNJjyTeE09+IlsGolPV3Vp+ suJmUK26y8IbEzGxa8eVoX3w7407VNzqeT0jF8vK7oy97EPgszoiutbzYanKYH27 Rpck+FdW/Q5o6jqw59swX+KEvVao52ETPX3kV8ae5uA2txOBnn6C0qZbM5OxPVLN IHr7E0+bn9BQVuTzhep1wNWi4cDzyeIjYfRGArBTkuSBKxFtbPmTMLa67qsBGKVu JcGYm6rdDO0iVAR9od/Is9b+3gTW49x/3jBEdg7iCHc8KuGOilZaHfyU6xjt3fPo L2lxXxUuobFD68/f4ervFVMpAPpmPaS/MEkHMIhJex3szdlSe/WZsQm+2/j799Rg Ba62pMOYvSR43WwlwX8eySUlVsPtJNtObKnRvDBOmOICgsZ3T9tHKjI+9IPVi9Ib s7yBBA1LFw4+c8wirzu1aaeDroJ3icqfU+tRe+nadQN1PMepk6sBUMu13bm8B3E3 R8oo+jFZRRvJmx7HDDlJX9GHri8hktCNm/gtt0ksWwEgAQHixukmKoDVssAmsiZ4 BbiWIA3ULciSKM782zDH7/GvDBbOurtV8TeubnV7DDARIA86COwuGjjk30Ltf3ia 5gnFIicLkmdRMh4AU0jvvEpxrHWFFJmreoR+jnAXHMBGoA6ExVaqR2VQzcpb5SIb sqe/5499BqvJqS4ZFn7f =q+nx -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
I think it is better not to use the coinbase, because it might collide with other proposals, and because coinbase is not part of the block header. I agree that a small set of standard threshold may be sufficient; a one percent resolution is probably not needed. If we use 4 bits we can encode 15 different thresholds + zero (meaning no support). For example we can have all thresholds between 25% and 95% separated by 5%. Using 4 bits per soft-fork proposal leaves enough room to fit 7 simultaneous proposals in version bits. That should be plenty. > > I still like the coinbase idea though - more than using up the BIP9 > versionbits range for verbose signaling. > > BIP9 (and other proposals which use those 29 versionbits) currently assume > that the participants on the network will coordinate in some form or other, > to agree on what the bits mean (in terms of change deployments). > > It would be very easy to also agree on a set of "standard" threshold levels > and map those onto e.g. 1 byte. > > Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. > "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are > standardized deployment schedules that people find useful. > So a BIP9 conformant schedule could be A = 95% / 2016 window, > while B = 75%/2016, etc. > > This would be quite a compact yet still readable signaling. The space of > values is large enough that I doubt we'd see much contention. > > Regards > Sancho > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
> However, my point is that the threshold should be [...] not fixed in the > soft-fork proposal My proposal makes it configurable (as well as window size, grace period etc.) > I agree that coinbase space might be a limitation. I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling. BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments). It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte. Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful. So a BIP9 conformant schedule could be A = 95% / 2016 window, while B = 75%/2016, etc. This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention. Regards Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
Hi Sancho, I saw your proposal. However, my point is that the threshold should be part of the signaling, and not fixed in the soft-fork proposal. I agree that coinbase space might be a limitation. To avoid this, I realize that the threshold could be encoded in the version bits. We have 32 version bits, and the top 3 bits must be set to 001 in BIP9. In order to extend BIP9 in a backward compatible way, we could set these 3 top bits to 010, and use the 29 remaining bits for soft fork signaling. If we use 7 bits per soft-fork proposal, we have enough space to encode four simultaneous soft-fork proposals, and sub-percent granularity for the threshold (2^7=128). Le 13/04/2017 à 16:17, Sancho Panza a écrit : > Thomas, > > I wonder if you've seen my proposal on how to make BIP9 more configurable: > https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki > > This could be extended with a coinbase signaling feature as you suggest. > This could include parameter information for forks which a miner is > signaling, for coordination. > > Currently I've not included something like this, but it might make a nice > addition. > One problem is the limited space in coinbase for embedding data on the large > number of possible independent deployments. > > Regards, > Sancho > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling
Thomas, I wonder if you've seen my proposal on how to make BIP9 more configurable: https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki This could be extended with a coinbase signaling feature as you suggest. This could include parameter information for forks which a miner is signaling, for coordination. Currently I've not included something like this, but it might make a nice addition. One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments. Regards, Sancho___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal: Soft Fork Threshold Signaling
Disclaimer: I am fully supportive of Segregated Witness and its activation by users through BIP148. However, I also believe that a soft fork would be less risky if it was initially activated by miners, before the date set in BIP148. This proposal is not intended to replace UASF, but to mitigate the risks. The following idea might already have been proposed and discussed elsewhere. If that is the case, I am sorry for the noise. Background == BIP9 requires 95% of miner hashrate support in order to activate a soft-fork. So far, the lack of miner consensus about Segwit has been frustrating both users and developers. This had led some users to propose a soft fork activation regardless of the expressed level of miner support (UASF, BIP148). There are many risks associated with UASF. If the fork is activated with less than 50% of the hashing power, the blockchain will have two competing branches. In addition, if the hashrate on the forking branch is very low, that branch will be exposed to attacks, where non-empty blocks are systematically orphaned by adverse miners. This threat may be a strong deterrent for miners willing to support the fork. The main argument in favor of UASF is that users, not miners, give its value to Bitcoin. Therefore, users and markets should have the power to decide which branch of the fork has the most value, and profit-driven miners should follow. If the soft-forking branch is valued more than the non-forking branch, it will end up attracting a majority of the hashing power, and the non-forking branch will eventually be orphaned. Feedback through markets, however, will only work if the forking branch can effectively be used. If the forking branch is rendered unusable by adverse miners, there is little chance the new coins will ever reach markets. To make things worse, profit-driven miners might adopt a passive attitude and decide to mine on the forking branch only once a proper price has been set by markets, or only once they see that it has enough hashing power to be usable. Thus, the lack of hashrate information prior to the soft fork increases the risk. On the other hand, if a soft fork was initiated with more than 33% of the hashing power, then it would probably be viable, because the remaining two thirds of the hashing power cannot successfully be allocated to mine blocks on the non-forking branch and to orphan blocks on the forking branch. Therefore, users will be able to move coins on the forking branch, and markets will be able to set a price on these coins, thus creating the feedback needed by profit-driven miners. Today about 30% of the hashing power are signaling their intention to activate Segwit using BIP9. This hashrate is very close to the 33% threshold, and it would probably be enough to initiate a viable soft fork; indeed we can expect additional hashing power to be gained from miners mining on both branches of the fork. However, nothing suggests that a soft fork triggered with 30% of the hashrate would be followed by the miners who are currently signaling Segwit using BIP9. BIP9 signaling means that these miners are willing to soft fork if support reaches 95%; it does not say anything about their intentions if support is as low as 30%. In other words, BIP9 signaling does allow miners to properly signal their intentions. BIP9 signaling == The activation threshold is part of the semantics of BIP9. Miners who use BIP9 do not only signal their support for a soft fork; they also signal to other miners that they will activate the soft fork if and only if support reaches 95%. Some of these miners might actually be willing to activate a soft fork with a lower support, even at the cost of creating two chains. Other miners might not be supportive of that idea, because they consider that the danger of their blocks being orphaned is too high. The problem is that this information, at which level of support miners are willing to initiate a soft fork, is not available. Thus, miners who are willing to initiate a soft fork at a lower hashrate cannot coordinate their action. Proposal: Soft Fork Threshold Signaling === Miners signal the threshold at which they are willing to activate a soft fork. The value of the threshold is published in the coinbase transaction of the block, with the corresponding version bit. Miners activate a soft fork if their threshold has been reached over the last retargeting period. For example, if 504 of 2016 blocks signal a soft fork with a threshold equal or lower to 25%, then the soft fork is activated by these miners. If no activation threshold is reached, the current BIP9 signaling rate indicator is replaced by a distribution of signaling rates per threshold. The public availability of threshold information allows miners to adjust their own threshold, and to optimize their chances of activating the soft fork. UASF Even if the soft fork is not activated by miners, this
