Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Good point, for the moving checkpoint a number of blocks (or maybe a timestamp) could be enough, but for the block limit of X blocks to decide if the moving checkpoint is ignored or not, as we have to compare two chains (main chain and fork) maybe is much better to measure the blockchain lengths as numberOfBlocks * averageBlockDifficulty, so if a difficulty adjustment happens in that time interval, it's taken into account. Regards From: LORD HIS EXCELLENCY JAMES HRMH Sent: Saturday, August 3, 2019 2:51 To: Ethan Heilman ; Bitcoin Dev ; Kenshiro [] Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol I have but one point to make in a brief catch-up read over. With the current protocol the fix to a network split is simple, the longest chain win. But with the moving checkpoint I'm proposing we have a problem if both chains began to differ more than N blocks ago, the forks are permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks: It is not to be considered the longest chain, it is to be considered the longest chain with the most proof of work. Regards, LORD HIS EXCELLENCY JAMES HRMH <https://earn.com/willtech> From: bitcoin-dev-boun...@lists.linuxfoundation.org on behalf of Kenshiro [] via bitcoin-dev Sent: Friday, 2 August 2019 11:08 PM To: Ethan Heilman ; Bitcoin Dev Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Hi all, Very good points. I did some clarifications in a private conversation, the new rule is making the moving checkpoint valid only if the difference in blocks between the main chain and the new fork is smaller than X blocks, like for example 3 days of blocks, so after a long network split everyone can finally follow the longest chain: With the current protocol the fix to a network split is simple, the longest chain win. But with the moving checkpoint I'm proposing we have a problem if both chains began to differ more than N blocks ago, the forks are permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks: If a node sees a fork longer than his main chain, and the fork has at least X blocks more than the main chain, then the node ignore the moving checkpoint rule, and it follows the fork, the longest chain. So as an example, the moving checkpoint could be 24 hours of blocks, and the limit of X blocks, the blocks of 3 days. So we have 2 possible situations to consider: - 51% attack: the blocks older than 24 hours are protected against a history rewrite during at least 3 days, in that time developers could release an emergency release with another mining algorithm to stop the attack. - Network split: if the network split is older than N blocks, we have 2 permanent forks (or chains), but in 3 days (or more) the blockchain heights will differ in more than X blocks (the blocks of 3 days) because there will be more miners in one chain than in the other so finally the loser chain will be abandoned and everyone will follow the longest chain. It could be even more conservative, like 48 hours for the moving checkpoint and a block limit of 7 days of blocks. Regards, From: Ethan Heilman Sent: Friday, August 2, 2019 14:19 To: Kenshiro [] ; Bitcoin Dev Cc: Alistair Mann Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Attack 1: I partition (i.e. eclipse) a bunch of nodes from the network this partition contains no mining power . I then mine 145 blocks for this partition. I don't even need 51% of the mining power because I'm not competing with any other miners. Under this rule this partition will hardfork from the network permanently. Under current rules this partition will be able to rejoin the network as the least weight chain will be orphaned. Attack 2: I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I feed it 145 blocks which fork off from the consensus chain. I have 24+24 hours to mine these 145 blocks so I should be able to do this with 25% of the current hash rate at the time the node went offline. Under your rule each of these offline-->online nodes I attack this way will hardfork themselves from the rest of the network. I believe a moving-checkpoint rule as describe above would make Bitcoin more vulnerable to 51% attacks. A safer rule would be if a node detects a fork with both sides of the split having length > 144 blocks, it halts and requests user intervention to determine which chain to follow. I don't think 144 blocks is a great number to use here as 24 hours is very short. I suspect you could improve the security of the rule by making the number of blocks a fork most reach to halt the network proportional to the difference in time between the timestamp in the block prior to the fork and the current
Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Hi all, Very good points. I did some clarifications in a private conversation, the new rule is making the moving checkpoint valid only if the difference in blocks between the main chain and the new fork is smaller than X blocks, like for example 3 days of blocks, so after a long network split everyone can finally follow the longest chain: With the current protocol the fix to a network split is simple, the longest chain win. But with the moving checkpoint I'm proposing we have a problem if both chains began to differ more than N blocks ago, the forks are permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks: If a node sees a fork longer than his main chain, and the fork has at least X blocks more than the main chain, then the node ignore the moving checkpoint rule, and it follows the fork, the longest chain. So as an example, the moving checkpoint could be 24 hours of blocks, and the limit of X blocks, the blocks of 3 days. So we have 2 possible situations to consider: - 51% attack: the blocks older than 24 hours are protected against a history rewrite during at least 3 days, in that time developers could release an emergency release with another mining algorithm to stop the attack. - Network split: if the network split is older than N blocks, we have 2 permanent forks (or chains), but in 3 days (or more) the blockchain heights will differ in more than X blocks (the blocks of 3 days) because there will be more miners in one chain than in the other so finally the loser chain will be abandoned and everyone will follow the longest chain. It could be even more conservative, like 48 hours for the moving checkpoint and a block limit of 7 days of blocks. Regards, From: Ethan Heilman Sent: Friday, August 2, 2019 14:19 To: Kenshiro [] ; Bitcoin Dev Cc: Alistair Mann Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Attack 1: I partition (i.e. eclipse) a bunch of nodes from the network this partition contains no mining power . I then mine 145 blocks for this partition. I don't even need 51% of the mining power because I'm not competing with any other miners. Under this rule this partition will hardfork from the network permanently. Under current rules this partition will be able to rejoin the network as the least weight chain will be orphaned. Attack 2: I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I feed it 145 blocks which fork off from the consensus chain. I have 24+24 hours to mine these 145 blocks so I should be able to do this with 25% of the current hash rate at the time the node went offline. Under your rule each of these offline-->online nodes I attack this way will hardfork themselves from the rest of the network. I believe a moving-checkpoint rule as describe above would make Bitcoin more vulnerable to 51% attacks. A safer rule would be if a node detects a fork with both sides of the split having length > 144 blocks, it halts and requests user intervention to determine which chain to follow. I don't think 144 blocks is a great number to use here as 24 hours is very short. I suspect you could improve the security of the rule by making the number of blocks a fork most reach to halt the network proportional to the difference in time between the timestamp in the block prior to the fork and the current time. I am **NOT** proposing Bitcoin adopt such a rule. NXT has a fundamentally different security model as it uses Proof-of-stake rather than Proof-of-Work. On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: P.S.: To be clearer, in this example I set an N value of 144 blocks, which is approximately 24 hours. From: Kenshiro [] mailto:tens...@hotmail.com>> Sent: Wednesday, July 31, 2019 16:40 To: Alistair Mann mailto:a...@pectw.net>>; Bitcoin Protocol Discussion mailto:bitcoin-dev@lists.linuxfoundation.org>> Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol >>> How would a (potentially, state-sponsored) netsplit lasting longer than N be handled? It would be detected by the community much before reaching the reorg limit of N blocks (it's 24 hours) so nodes could stop until the netsplit is fixed. In the extreme case no one notice the network split during more than N blocks (24 hours) and there are 2 permanent forks longer than N, nodes from one branch could delete their local history so they would join the other branch. Regards, From: Alistair Mann mailto:a...@pectw.net>> Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] mailto:tens...@hotmail.com>>; Bitcoin Protocol Discussion mailto:bitcoin-dev@lists.linuxfoundation.org>> Subject: Re: [bitcoin-dev] Add a moving checkpoint to t
Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
mm you are right, then the "moving checkpoint" rule needs to have some limits to allow the network self-heal instead of requiring humans detecting the splits or stopping nodes. Let's suppose than a 51% attack can be detected and the developers can release a new version of the software with a new mining protocol in about 3 days. Then the complementary rule could be something like this: - If 2 forks have a block height difference of 432 blocks (about 3 days) or more, then the moving checkpoint rule is ignored and everything works as with the current protocol. With this rule, the network can self-heal in a 100% automated way. This would prevent a history rewrite of more than 24 hours during a 51% attack during 3 days, which should give enough time to change the protocol. If instead of a 51% attack what happens is a network split, then nodes should converge to the longest chain in a few days. But maybe I'm missing something here, I'm still learning. Regards, From: Alistair Mann Sent: Thursday, August 1, 2019 1:28 To: Kenshiro [] Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol On Wednesday 31 Jul 2019 14:53:25 Kenshiro [] wrote: >> How would a (potentially, state-sponsored) netsplit lasting longer than >> N be handled? > > It would be detected by the community much before reaching the reorg limit > of N blocks (it's 24 hours) so nodes could stop until the netsplit is > fixed. A netsplit cannot be detected but merely be suspected where the p2p protocol does allow arbitrary connecting/disconnecting of any peer: there's no difference between a remote net being split off, that net having nothing to say, and that net choosing to disconnect. Detection then mandates manual, out- of-band communications, which is error prone and centralising. I also observe 'stopping nodes' during netsplits introduces several attack vectors. Among them: create a netsplit, which stops the nodes, turn off the netsplit, repeat. A sequence of 365 actors causing their own small netsplits could effectively stop Bitcoin at the cost (to them) of no Internet for one day a year as the rolling netsplit could never be fixed. > In the extreme case no one notice the network split during more than N > blocks (24 hours) and there are 2 permanent forks longer than N, nodes from > one branch could delete their local history so they would join the other > branch. > > P.S.: To be clearer, in this example I set an N value of 144 blocks, which > is approximately 24 hours. I've seen estimates of China hosting more than 51% of hashpower. Say they conduct a netsplit. Does your suggestion mean that it's the rest of the world that has to delete their local history because they lack the hashpower to assert themselves as the proper branch? If so, I think having to delete actual history everywhere across the globe but China is not a price worth paying to limit reorgs to 24 hours. I am unconvinced that the moving checkpoint you describe would improve Bitcoin. -- Alistair Mann ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
P.S.: To be clearer, in this example I set an N value of 144 blocks, which is approximately 24 hours. From: Kenshiro [] Sent: Wednesday, July 31, 2019 16:40 To: Alistair Mann ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol >>> How would a (potentially, state-sponsored) netsplit lasting longer than N be handled? It would be detected by the community much before reaching the reorg limit of N blocks (it's 24 hours) so nodes could stop until the netsplit is fixed. In the extreme case no one notice the network split during more than N blocks (24 hours) and there are 2 permanent forks longer than N, nodes from one branch could delete their local history so they would join the other branch. Regards, From: Alistair Mann Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote: > I would like to propose that a "moving checkpoint" is added to the Bitcoin > protocol. It's a very simple rule already implemented in NXT coin: > > - A node will ignore any new block under nodeBlockHeight - N, so the > blockchain becomes truly immutable after N blocks, even during a 51% attack > which thanks to the moving checkpoint can't rewrite history older than the > last N blocks. How would a (potentially, state-sponsored) netsplit lasting longer than N be handled? -- Alistair Mann ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
>>> How would a (potentially, state-sponsored) netsplit lasting longer than N be handled? It would be detected by the community much before reaching the reorg limit of N blocks (it's 24 hours) so nodes could stop until the netsplit is fixed. In the extreme case no one notice the network split during more than N blocks (24 hours) and there are 2 permanent forks longer than N, nodes from one branch could delete their local history so they would join the other branch. Regards, From: Alistair Mann Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote: > I would like to propose that a "moving checkpoint" is added to the Bitcoin > protocol. It's a very simple rule already implemented in NXT coin: > > - A node will ignore any new block under nodeBlockHeight - N, so the > blockchain becomes truly immutable after N blocks, even during a 51% attack > which thanks to the moving checkpoint can't rewrite history older than the > last N blocks. How would a (potentially, state-sponsored) netsplit lasting longer than N be handled? -- Alistair Mann ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Hi all, I would like to propose that a "moving checkpoint" is added to the Bitcoin protocol. It's a very simple rule already implemented in NXT coin: - A node will ignore any new block under nodeBlockHeight - N, so the blockchain becomes truly immutable after N blocks, even during a 51% attack which thanks to the moving checkpoint can't rewrite history older than the last N blocks. NXT coin has a N value of 720 blocks, like 12 hours of blocks. To be more conservative, Bitcoin could have a N value of 144 blocks (like 24 hours). So users and exchanges could plan their operations with big amounts of BTC knowing that only after 24 hours a transaction is truly immutable. Maybe a 51% attack never happens but if it does it would be nice to be 100% sure that history rewrite is limited to only 24 hours. Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Eco-friendly mining algorithms
Hi all, Here are some links to the best eco-friendly mining algorithms I have found: - Proof of Stake v3.0: http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version Used in several PoS coins like Bitcoin Confidential: https://bitcoinconfidential.cc/ - Proof of Capacity: https://coincentral.com/what-is-proof-of-capacity/?source=post_page--- A simple explanation from the web: Imagine you filled your hard drive with lottery tickets and then when a random number is generated, you check to see who has the most matching numbers.” If you have the most matching numbers, you win a reward. The best part is “you get to keep using these lottery tickets block after block.” It's implemented in BurstCoin: https://www.burst-coin.org/ Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi ZmnSCPxj, Thank you for your apologies. >>> Just to be clear, I do not think your additions to the base proof-of-stake >>> can fix the issues introduced by proof-of-stake. No problem. After thinking about my experimental idea to use a formula to give more weight to coins together in a single address I think it wouldn't work as I expected. But what I'm defending here is the standard PoS v3.0 which as far I know is something like a "gold standard" in PoS. There are also more "modern" techniques not included in PoS v3.0 that could be added like evaluating blockchain density to detect possible attacks which could also be used to improve security: i.e.: as far I know, a 51% history rewrite attack can't be done in PoS if the attacker doesn't stop creating his 51% of blocks in the main chain to make it shorter than his private fork, and that can be detected: If nodes detect a hard fork starting in block N (and N has a minimum depth like 10 blocks or whatever), and the main chain has a dangerous low block density between the tip of the blockchain and block N, instead of following the longest chain, the nodes could start some emergency protocol like ignoring the new fork. Regards, From: ZmnSCPxj Sent: Wednesday, July 24, 2019 6:14 To: Kenshiro [] Cc: Eric Voskuil ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro and list, I apologize for the unnecessarily toxic words I used in replies to you, Kenshiro. I also apologize to subscribers of the list for this behavior. Such behavior should not be tolerated and should be called out. Just to be clear, I do not think your additions to the base proof-of-stake can fix the issues introduced by proof-of-stake. A general heuristic in designing anything is that additional mechanisms cannot improve efficiency. However, it seems I cannot argue the point without becoming rude or introducing irrelevant arguments. Thus, I will no longer respond to this thread. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> Miners cannot feasibly take over 50% of energy sources in the world. As I said in other e-mail, you don't need 50% of energy sources of the world, you only need to hack the biggest mining pools to execute a 51% attack. >>> Thus it is immaterial that each tiny stake of the evil whale is tiny: only >>> the tiny stakes of the evil whale are in play during the time that the >>> singular big UTXO by the honest whale is banned. Sorry but you are wrong because there are always plenty of small stakers, and dividing your coins in 100.000 you suffer a strong penalty in your staking weight. Remember, the formula is this, or some improved version of it: utxoStakingWeight = numberOfCoins ^ 1000 To simplify the calculations, imagine there is a total supply like 200.000 coins (just a little more to include some small stakers), and you have 11 coins splitted in 11 addresses: stakingWeightPerAddress = 1 ^ 1000 = 1 stakingWeightPerAddress * numberOfAddresses = 1 * 11 = 11 (this is the total staking weight of the evil whale) Now we have a little, honest staker, with only TWO coins in one staking address: stakingWeightPerAddress = 2 ^ 1000 = 1,0715×10³⁰¹ So the evil whale, with 51% of the coins splitted one coin per address lose against the small stakers, even if they stake 2 coins each one. With this rule, you don't have other choice that put your coins together, and wait the wait time after creating a block. The rest of the blocks are created by many other stakers, the wait time enforce that big stakers have to wait a number of blocks, which are created by the little stakers. >>> Now again, consider that the situation indicates that there are in fact >>> only two actual stakers, each of whom have 50% of the staked funds, thus >>> there are no other stakers There is always plenty of little stakers. You only can have 2 stakers if the rest of the world is not interested in the coin. >>> I did indicate "each of them owns 50% of the total staked value", did I not? Sure, but I didn't understood that as exact numbers, because if its so then only few people are interested in the coin, and then it's not a problem for the rest of the world. Again, there is always plenty of little stakers. >>> You have demonstrated no such thing, merely demonstrated your own willful >>> incompetence in designing protocols. I'm sorry but it's you who don't understand the protocol I'm proposing. Of course I could be wrong but I didn't saw any numbers that demonstrate that. Just do the math and forget extreme situations where there are only 2 stakers, because there is always plenty of little stakers, even if all the small stakers together have only 1% of coins or less. Regards, From: ZmnSCPxj Sent: Saturday, July 20, 2019 13:07 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, > > >>> For example, if you are capable of disrupting a coin such that its value > >>> is very likely to drop, you can buy short options as leverage. > Suppose you hold a large stake of coins and know you control a significant > fraction, enough that a censorship attack by you will be so disruptive that > the coin price will drop. > You take out a short contract with the contract price at the "hopium" level > others have (say 10% higher), buying enough options that you can cover the > current price of your owned stake, plus some more options. > Suppose you buy, a number of options equal to twice your stake. > > Thank you for the explanation, I understand it now. But what percent of BTC > trades are short options? If everyone is doing short options, the attack is > very dangerous as you say, but if only a small percent of trades is done in > short options, then it's not a big problem. It is immaterial, because this is just *one* possible economic attack. Further leverage can always be had as Bitcoin does not exist in isolation. > > And this type of attack could also be done in PoW by evil miners. It's only > one step more, they have to purchase a lot of BTC before the attack, buy many > short options and execute the attack. Purchasing 50% of BTC is a problem > because of the price, but that's the same for PoW or PoS. Miners cannot feasibly take over 50% of energy sources in the world. > > >>> Let's suppose there are two big whales in your coin. > Each of them owns 50% of the total staked value. > Let's say "wait many blocks" parameter is 100 blocks. > > >>>One whale puts all his coin in a single UTXO. > The other has distributed his stake in 100,000 different UTXOs. > > I think there is a misunderstanding here, you forgot to divide the 50% > staking weight of the evil whale by 100.000. No, you have a misunderstanding of your ***own*** system. You forgot that you indicated that a staking UTXO is banned from adding a new block for "wait many blocks",
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> For example, if you are capable of disrupting a coin such that its value is >>> very likely to drop, you can buy short options as leverage. Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. Suppose you buy, a number of options equal to twice your stake. Thank you for the explanation, I understand it now. But what percent of BTC trades are short options? If everyone is doing short options, the attack is very dangerous as you say, but if only a small percent of trades is done in short options, then it's not a big problem. And this type of attack could also be done in PoW by evil miners. It's only one step more, they have to purchase a lot of BTC before the attack, buy many short options and execute the attack. Purchasing 50% of BTC is a problem because of the price, but that's the same for PoW or PoS. >>> Let's suppose there are two big whales in your coin. Each of them owns 50% of the total staked value. Let's say "wait many blocks" parameter is 100 blocks. >>>One whale puts all his coin in a single UTXO. The other has distributed his stake in 100,000 different UTXOs. I think there is a misunderstanding here, you forgot to divide the 50% staking weight of the evil whale by 100.000. Yes, 50% of coins splitted in 100.000 addresses gives you the same staking weight per address as an small honest staker with 0,0005% of the coins, all together in a single address. Yes, you still have 100.000 addresses, so you win against the honest staker with 0,0005% of the coins, but you lose against the honest staker with 0,0006% of the coins. Splitting the coins in many addresses transform the whales in little fishes, that's the greatness of this method. >>> Now suppose the one with the 99% control performs a censorship attack. After a week (1008 blocks) the community rallies and hardforks, burning the UTXOs that performed censorship. However, only about 998 UTXOs of the censoring staker is known (from the 99% of blocks it generated in that period), which is less than 1% of the 100,000 UTXOs he actually owns, and thus still controls a significant stake even past the hardfork, letting it perform further censorship attacks. It's the same as above, you can't split your coins in many addresses without becoming a little fish, so this is not a problem. Even so it's true that having 99% of the coins he could do several consecutive attacks, using 51% of the total number of coins in each attack, but they are burned again and again and the rest of the people become very happy as their coins multiply his value in each hard fork. The price could temporarily go down during the attacks, but in the end it will recover. >>> We already know that miners are setting up mines at locations where energy >>> is being wasted (e.g. oil well gas flares, putting up solar panels instead >>> of just letting sunshine pointlessly heat up their roofs, etc.), and >>> channeling the wasted energy into productive activity. I'm sure a big percent of mining will be done in this way, but if there is still dirty energy like nuclear energy or others is because we can't get all the energy we need from clean sources (and that's excluding bitcoin mining). So even being very optimistic about bitcoin mining, it will steal clean energy sources from other human needs which will make us keep using dirty energy. So PoW makes use dirty energy sources in a direct or indirect way. >>> Thus, adding more rules is rarely the optimal thing to do. Proof of Stake is more complex than PoW, so you need to add a few more rules. Of course the rules must be well designed and tested, but as I explained above there is no problem with the extra rule of giving a great increase in staking weight to coins together in a single UTXO, because there is wait time for each staking deposit. Regards, From: ZmnSCPxj Sent: Saturday, July 20, 2019 2:45 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, > >>> I already told you that it is always possible to get around this: > >>> leverage by use of short options. > Short the coin to attack, then perform your attack by censorship. > Coin value will drop due to reduced utility of the coin, then you reap the > rewards of the short option you prepared beforehand. > By this, you can steal the entire marketcap of the coin. > > >>>Then you still have the economic power (plus what you managed to steal), > >>>which you can then use to take over another proof-of-stake coin, > >>>regardless of whether it uses the same pro
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> I already told you that it is always possible to get around this: leverage >>> by use of short options. Short the coin to attack, then perform your attack by censorship. Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand. By this, you can steal the entire marketcap of the coin. >>> Yes, and of course stealing the value in the chain is not the only way to >>> profit from the destruction of its usefulness. PoS offers no defense >>> against the primary threat to permissionless money. As I told in my other mail, my trading level is very basic and I don't understand this type of attack. >>> In PoS, once a miner achieves necessary stake (also profitably) it can >>> censor indefinitely. It’s a big difference. Imagine you have 90% of coins, there 2 possible situations: 1 - You keep creating blocks in the main chain: then you can censor only in your 90% of blocks. Censored transactions are included in the other 10% of blocks. 2 - You stop creating blocks in the main chain to force others to follow your evil chain (which is longer) and then you can censor everything: that's a clear 51% attack that can be easily detected and your funds are burned in a hard fork. Even for the first case, with time the accumulation of old transactions in the mempool will be very evident for all nodes and I bet its possible to analyze the blocks and the mempool during some time until it's evident who is censoring transactions. >>> It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on >>> steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly >>> something to minimize. I copy the explanation of my other e-mail: "Not at all, I forgot to tell you that in modern PoS protocols like PoS v3.0 staking deposits have to wait many blocks after creating a block to be able to create another block. With my additional rule every staker is incentivized to put their staking deposit in a single address to avoid a strong penalty in their staking weight, and having their coins together they can't avoid the wait time with the "stake in many addresses" trick 🙂" Regards, From: Eric Voskuil Sent: Friday, July 19, 2019 7:10 To: ZmnSCPxj Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin On Jul 18, 2019, at 20:45, ZmnSCPxj mailto:zmnsc...@protonmail.com>> wrote: Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] mailto:tens...@hotmail.com>> wrote: Hi all, A 51% attack under proof-of-work is only possible, in general, if some singular entity were able to have physical control of almost 50%, or some such close number, of the globe, simply due to the fact that energy availability is somewhat distributed over the globe. Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest. If you look at this graph you will see that controlling 4 mining pools could be enough: https://www.blockchain.com/en/pools Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave. But also long term economic power, since leaving implies a lower proportional hash power, until another comparably-sized pool exists, but this is not the case when there is a majority hash power pool, which is economically inevitable until the majority miner starts censoring. https://github.com/libbitcoin/libbitcoin-system/wiki/Pooling-Pressure-Risk Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered). The invisible hand abides. This is why PoW is necessary, and why fee-based confirmation is necessary. It’s the only economically-rational way that the censor can be overpowered. But keep in mind the only net cost to the censor is the *premium* on censored transactions. https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash. So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically. While this proposal may introduce engineering improvements, it does not change any of the economic forces at work and therefore does not mitigate this issue. The pool controls the payout, and therefore retains power over tx selection re
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>>Pools only have short-term power in that they can only temporarily attack >>>the coin until miners notice and then voluntarily leave. I agree >>>GPUs still require electricity to run, and are far easier to source. Hash change simply means that those with control of energy sources can easily purchase the needed hardware from many sources (as opposed to ASICs which are only sourced from a few places). So a hash change will only affect things temporarily, and it will still settle to the existing distribution of mining hashpower. I agree >>> I already told you that it is always possible to get around this: leverage >>> by use of short options. Short the coin to attack, then perform your attack by censorship. Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand. By this, you can steal the entire marketcap of the coin. >>>Then you still have the economic power (plus what you managed to steal), >>>which you can then use to take over another proof-of-stake coin, regardless >>>of whether it uses the same proof-of-stake algorithm or not. My trading level is very basic and I don't understand this attack >>> this happens every day in Bitcoin, and nobody particularly cares. You just wait for confirmations that in practice are impossible for some orphaned chain to persist. But is very different. In a normal situation you only have to wait a few blocks and you know your transaction is final, but a network split of 24 hours is another thing: could happen that you sent a big amount to btc to an exchange, the exchange waited 5-6 blocks to be sure and then you use your balance in that exchange to buy a big amount of other coin. Then this network split happens and the losing chain is yours, so you send back to yourself your bitcoins with a high fee, this could cause strong loses to exchanges or normal people that received a big payment for something. I prefer the community driven merge of both chains in my PoS protocol >>> But your proposal of being non-linear on the size of the stake means that >>> if you have 51% of the coins, if you put them in a single stake UTXO you >>> potentially get 99.999% of the blocks, which is ***much worse***. Not at all, I forgot to tell you that in modern PoS protocols like PoS v3.0 staking deposits have to wait many blocks after creating a block to be able to create another block. With my additional rule every staker is incentivized to put their staking deposit in a single address to avoid a strong penalty in their staking weight, and having their coins together they can't avoid the wait time with the "stake in many addresses" trick 🙂 >>> We hope to see you back soon after having learned your lesson. Thx 🙂 Just an additional question: do you have an estimation of the energy waste of PoW if Bitcoin price rises a lot, like one million dollars or more? Because if it's proportional to the price, it could be like 100 times the current energy waste. Regards, From: ZmnSCPxj Sent: Friday, July 19, 2019 5:45 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote: > Hi all, > > >>> A 51% attack under proof-of-work is only possible, in general, if some > >>> singular entity were able to have physical control of almost 50%, or some > >>> such close number, of the globe, simply due to the fact that energy > >>> availability is somewhat distributed over the globe. > > Mining is not only about the energy sources, individual miners spread around > the globe can join big mining pools, and these mining pools could be hacked > to participate in a 51% attack. Some governments (or other groups) could plan > this type of attack if it's in their interest. > > If you look at this graph you will see that controlling 4 mining pools could > be enough: > > https://www.blockchain.com/en/pools Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave. Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered). The invisible hand abides. Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash. So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically. > > >>> Secondly: change of hashing algorithm is pointless in the highly unlikely > >>> case of a 51% attack, because what matters is control of energy sources.
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> A 51% attack under proof-of-work is only possible, in general, if some >>> singular entity were able to have physical control of almost 50%, or some >>> such close number, of the globe, simply due to the fact that energy >>> availability is somewhat distributed over the globe. Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest. If you look at this graph you will see that controlling 4 mining pools could be enough: https://www.blockchain.com/en/pools >>> Secondly: change of hashing algorithm is pointless in the highly unlikely >>> case of a 51% attack, because what matters is control of energy sources. As far as I know, if the PoW algorithm changes to an ASIC resistant algorithm that can only run in GPUs or CPUs, the hashing power would be much more distributed at least until someone creates a new ASIC for that algorithm. There are many GPUs around the globe, but not so many ASIC miners right? >>> Nothing can be more efficient than proof-of-work, and the proof-of-stake >>> delusion is simply a perpetual motion machine that attempts to get >>> something from nothing. As time passes and more PoS coins appears, including big projects like Ethereum, we will see if it's delusional or not 🙂 I forgot one, if you do a 51% attack to a PoS coin you know that all your staking funds will be burned. In a PoW coin you don't lose your miners and can use them to mine or attack another coin with the same algorithm. >>> You must understand that removing the chain tip puts the transactions in >>> that block back in the mempool, before we ever start following the longer >>> chain. Yep but it could make double spend attacks very easy. People would know what is happening and could send the money to themselves with a higher fee to recover it. Many people would lose money with that. To fix that problem with a PoS algorithm, some community-guided initiative could get all transactions of both chains and create a merged chain with a hard fork so double spends attacks would not be possible. This could be somewhat slow, maybe the network is stopped a few days, but in the end no one will see money disappear from their wallet, much better than pray that your payer doesn't send the money back ato himself. >>> Hard forks are very difficult to coordinate as the user set increases in >>> size. I don't think many people will vote against a hard fork if the network is clearly under a 51% attack or the blockchain has 2 branches longer than N due to an internet split. >>> This solution is worse than the problem, and speeds up the dominance of >>> large stakers over the coin, trivially letting someone with the largest >>> stake in the coin grow their stake even faster. I think it's very evident that the rich guy earn coins faster in both algorithms. In PoS if you have 51% of the coins and use them to stake, you make 51% of the blocks, I don't see any problem with that. If you decide to do a 51% attack, stopping doing blocks in the main chain to force the others to follow your "private" chain, well, you know for sure your funds will be burned in the next hard fork. >>> No, I think it will be very successful in ensuring that smart individuals >>> will spend their time actually doing things that benefit the economy and >>> technology instead of wasting their time being distracted with Ethereum and >>> proof-of-stake. Ok, we the PoS advocates will let the smart people to work in more difficult issues like finding reasons to justify the energy waste and heat generation of PoW when Bitcoin price reaches 1 million dollars 😉 Regards, From: ZmnSCPxj Sent: Thursday, July 18, 2019 16:15 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning, > I think there is some misunderstanding here. A single node can be isolated > from the rest of the network any time and when it reconnects it only has to > follow the longest chain as always. Checking with a block-explorer or a > friend's node is only required under the extreme situation of being under a > 51% attack, but that is also a problem for Proof Of Work. Both protocols > require manual intervention: > > -PoS: Burn the funds of the attacker with a hard fork > -PoW: Change the PoW algorithm with a hard fork Again: under proof-of-work, 51% attacks are a lot less feasible than under proof-of-stake. You really should have researched this by this point, but in any case. The primary source of energy on Earth is the formation of the solar system. Some areas were seeded with radioactive materials. Later on, some areas were seeded with carbohydrates from dying biological processes. Regardl
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>>1. A network split (maybe better term is "network partition"?) wherein some >>>number of nodes are temporarily unable to contact the rest of the network. This has the degenerate but very common case where a single node is temporarily unable to communicate with the rest of the network. I think there is some misunderstanding here. A single node can be isolated from the rest of the network any time and when it reconnects it only has to follow the longest chain as always. Checking with a block-explorer or a friend's node is only required under the extreme situation of being under a 51% attack, but that is also a problem for Proof Of Work. Both protocols require manual intervention: -PoS: Burn the funds of the attacker with a hard fork -PoW: Change the PoW algorithm with a hard fork The other extreme situation would be if the network or internet itself is splitted more than N blocks. If that happens, it should require manual intervention to merge both chains. But in PoW it's much worse because the longest chain wins and it erases all history of the losing chain. Are you sure that's better? All transactions of one day (or more) could be erased forever. >>> 2. A node being shut down, then brought back online again. It's the same as above. >>>To expand on this: by censoring ***all*** transactions one is able to >>>prevent spending of all funds. This will crash the value of the staked funds also, but note that the staker could use techniques like short options to leverage this and potentially earn more than the value of their staked funds, effectively stealing the entire marketcap of the attacked coin. Yes but I think this can be solved in PoS, because there should be only 2 possible cases: 1 - The attacker doesn't stop making blocks in the main chain an he only censors transactions in his blocks: in this case, there is always some honest block so he can only slow the network 2 - The attacker does a 51% attack stopping doing blocks in the main chain, so the longest chain is his "private" chain which only has his blocks: then he can censor every transaction, but that attack is very evident and a hard fork could burn his funds. >>> Aside from that, this is possible to evade by running 1 masternodes and >>> splitting your staking funds among them. It's possible to give more staking weight to coins together in a single address than splitted coins like with this formula (or some improved version) stakingWeight = numberOfCoins ^ 1000 So imagine Bitcoin has only 100 coins in 2 wallets, the honest wallet has 2 coins in a single address, and the attacker wallet splits his 98 coins in 98 addresses: honestValidatorStakingWeight = 2 ^ 1000 = Very big number attackerStakingWeightPerAddress = 1 ^ 1000 = 1 totalAttackerWeight = 1 * 98 = 98 So X coins together always have more weight than any bigger amount of coins splitted in amounts smaller than X. The attacker needs to have at least one address with X coins. >>> Basically: "never base consensus rules on mempool state" is a good rule of >>> thumb for ensuring that consensus can be maintained. Yep it's only an idea, if a big number of transactions is being censored it should be possible to detect it. After some time an increasing number of nodes will see that they have very old transactions in their mempools even if blocks are not full. >>> Another thing is that Ethereum itself is going to PoS next year, but with a >>> different implementation that I'm proposing here. >>>Just another nail in the coffin. Do you think Ethereum PoS will fail? Regards, From: ZmnSCPxj Sent: Thursday, July 18, 2019 3:13 To: Eric Voskuil Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning all, > > >>>Under the trust-minimization requirement of Bitcoin this is simply not > > >>>acceptable. > > As there is no way to trust-minimally heal from a network split (and every > > time a node is shut down, that is indistinguishable from a network split > > that isolates that particular node), this is not a trust-minimizing > > consensus algorithm. > > That’s nonsense, one is a feature (systemic trust), the other is a bug (code > accident). But there is a way to minimize actual forks - try not to change > the consensus rules in the code you ship. I am uncertain what you mean here. What I am attempting to compare are: 1. A network split (maybe better term is "network partition"?) wherein some number of nodes are temporarily unable to contact the rest of the network. This has the degenerate but very common case where a single node is temporarily unable to communicate with the rest of the network. AND 2. A node being shut down, then brought back online again. Neither seems to match "feature" or "bug", as both are simply accidents of deployment. The point (as I understand it) of a consensus algorithm is to
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi ZmnSCPxj, I'm based on the more evolved implementation of PoS that I know, which is PoS v3.0 and it's currently implemented in several coins: http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version As far as I know the grinding attack is and old issue that is fixed in PoS v3.0. >>>At least the proposed `assumeutxo` requires the operator to explicitly >>>enable it, but I believe your "hardcoded checkpoints" cannot be disabled, >>>much less disabled-by-default. We don't trust the developers, the source code is public and anyone can check it. With the hardcoded checkpoints is exactly the same, they are in the source code repository and everyone can check them. The checkpoints are the easiest part to check. A user doesn't have any reason to remove the checkpoints, but as with anything in the source code, they could modify it to avoid the checkpoints (and become vulnerable to Long Range attacks doing it) >>>Under the trust-minimization requirement of Bitcoin this is simply not >>>acceptable. As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. The block explorer or other additional source of trust like a friend would only be required in the extreme situation that the network is under a 51% attack, and only by the nodes that are updating blocks in that moment. Updated nodes are fully protected, and under normal circumstances new nodes can just follow the longest chain as always. The other extreme situation that could cause a hard fork is that the network is splitted more than N blocks, which should require some social consensus to fix it. So N should be long enough, like a few hours of blocks or even 1 day. >>> History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people. In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator. >>> Worse, under proof-of-stake it is often the case that stakers are awarded >>> even more coin with which they can stake. Sure, but in PoW the miners with more hash power earn more coins that can be used to purchase more miners. There is always the privilege of the rich guy, no matter if its PoW or PoS. The point is to design a protocol that don't allow the rich to destroy the network. Let me put it in this way: NXT is a PoS coin that uses moving checkpoints with a market cap of 21 million dollars. If the current PoS protocols are so flawed, how can you explain that a coin with this market cap is not being attacked? https://www.coingecko.com/en/coins/nxt Another thing is that Ethereum itself is going to PoS next year, but with a different implementation that I'm proposing here. Regards, From: ZmnSCPxj Sent: Wednesday, July 17, 2019 1:00 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev wrote: > Hi, > > After studying several Proof of Stake implementations I think it's not only > an eco-friendly (and more ethical) alternative to Proof of Work, but > correctly implemented could be 100% secure against all 51% history rewrite > attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra > improvements are required: Under the trust-minimization and uncensorability requirements that Bitcoin has, nothing is more efficient than proof-of-work. The very idea of proof-of-stake labors under the assumption that unencumbered free-market payment for the consumption of energy is somehow not market-efficient despite the well-known phenomenon of the invisible hand, and believes that it is possible to get something for nothing. Please re-examine your assumptions. > - Hardcoded checkpoints:each Bitcoin Core release (each few months) should > include a hardcoded checkpoint with the hash of the current block height in > that moment. This simple measure protects the blockchain up to the last > checkpoint, and prevents any Long-Range attack. While this is a developer list and made up of developers who would be quite incentivized to agree to such a setup, note that
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi Oscar, Thank you for your answer. Just to clarify my proposal: 1 - It's a full change to Proof of Stake protocol to avoid the energy waste and to prevent a 51% history rewrite attack, even if the attacker has 99% of coins. 2 - The hardcoded checkpoints could be set by each bitcoin node client, not only Bitcoin Core. No matter if the checkpoints are different, only that they are frequent. They are there to prevent Long Range attacks. Checkpoints are public just like the rest of the software, they don't require any trust. A bad checkpoint would be detected by the community. 3 - There are several PoS coins working just now and as far as I know they don't have any problem. NXT coin implements the moving checkpoint system and others the hardcoded checkpoints. 4 - In any given block, only one staker gets the authorization to create that block, so other stakers can't spam the network with many different blocks as they are illegal. 5 - The block explorer is only required during a 51% attack, and only for nodes that are updating blocks during the attack. Updated nodes are protected thanks to the moving checkpoints. Regards, From: Oscar Lafarga Sent: Tuesday, July 16, 2019 22:35 To: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Hi Kenshiro, I don't think your proposal would require any changes to the Bitcoin Core implementation. This system you describe seems like it would operate as an independent addition, rather than an alternative to the Proof of Work consensus code that runs within Bitcoin now. It introduces security risk in the selection of block explorer and to the Bitcoin Core release dispatch system, reducing the trustlessness of the current network. Also, without the constraints that PoW places on block creation, you increase the vector space for attacks since it is trivial to spam blocks to node on the network (see Sybil attack<https://en.wikipedia.org/wiki/Sybil_attack#>). I believe many other software projects have tried similar checkpointing schemes that have resulted in hard forks or overall weakened consensus. I haven't dug too deeply, but I'm not aware of any cases where these schemes accomplish anything useful to improve the bitcoin network. Best, On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: Hi, After studying several Proof of Stake implementations I think it's not only an eco-friendly (and more ethical) alternative to Proof of Work, but correctly implemented could be 100% secure against all 51% history rewrite attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required: - Hardcoded checkpoints: each Bitcoin Core release (each few months) should include a hardcoded checkpoint with the hash of the current block height in that moment. This simple measure protects the blockchain up to the last checkpoint, and prevents any Long-Range attack. - Moving checkpoints: the nodes only allow chain reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at any block under nodeBlockHeight - N. This fully protects nodes that are online and updated. Nodes that are not fully updated need some extra rule to be protected between the last hardcoded checkpoint and the current blockchain height. This extra rule could be connecting to a block explorer to download the hash of the current block height, or ask some trusted source like a friend and enter the hash manually. After being fully updated, the user can always check that he is in the correct chain checking with a block explorer. Someone could have 99% of the coins and still would be unable to use the coins to do any history rewrite attack. The attacker could only slow down the network not creating his blocks, or censor transactions in his blocks. What do you think? :) Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Oscar Lafarga https://www.setlife.network <https://www.setdev.io/> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi, After studying several Proof of Stake implementations I think it's not only an eco-friendly (and more ethical) alternative to Proof of Work, but correctly implemented could be 100% secure against all 51% history rewrite attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required: - Hardcoded checkpoints: each Bitcoin Core release (each few months) should include a hardcoded checkpoint with the hash of the current block height in that moment. This simple measure protects the blockchain up to the last checkpoint, and prevents any Long-Range attack. - Moving checkpoints: the nodes only allow chain reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at any block under nodeBlockHeight - N. This fully protects nodes that are online and updated. Nodes that are not fully updated need some extra rule to be protected between the last hardcoded checkpoint and the current blockchain height. This extra rule could be connecting to a block explorer to download the hash of the current block height, or ask some trusted source like a friend and enter the hash manually. After being fully updated, the user can always check that he is in the correct chain checking with a block explorer. Someone could have 99% of the coins and still would be unable to use the coins to do any history rewrite attack. The attacker could only slow down the network not creating his blocks, or censor transactions in his blocks. What do you think? :) Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
They Payjoin protocol could include the possibility of receive "safe" amounts (i.e.: 0.025 btc) to several addresses so every user using Payjoin already have a splitted balance. Only people receiving a regular public transaction should need the extra splitting transaction. Regards From: Kenshiro [] Sent: Friday, March 22, 2019 11:23 To: Bitcoin Protocol Discussion; rha...@protonmail.com Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction >I'm not really sure the problem you're describing, but it sounds like >something that affects normal bitcoin transactions as well. Yeah, it affects normal transactions too. But I'm focused in Payjoin because it should allow private transactions. The problem I see is that Payjoin shouldn't allow that the sender or the receiver of the transaction can get information about the bitcoin balance of each other. A person could have his savings in btc in a single address, use Payjoin to send/receive a payment thinking it's private and leaking to the receptor he has a high amount of btc. But an automatic splitting to itself in the background could solve the problem (maybe 100$ amounts) or so. >There's certainly some interesting about the idea of "pre-fragmenting" your >wallet utxo so you can make (or in payjoin: receive) payments with better >privacy aspects.However, it's pretty unlikely to be practical for normal >users, as it'll generally result in pretty big and cost-ineffective >transactions. For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature. i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each. I would prefer wait some time and have privacy than the opposite. Regards From: rha...@protonmail.com Sent: Thursday, March 21, 2019 17:52 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well. There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions. In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet. -Ryan ‐‐‐ Original Message ‐‐‐ On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev wrote: Hi, I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it: - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount. What do you think? Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
>I'm not really sure the problem you're describing, but it sounds like >something that affects normal bitcoin transactions as well. Yeah, it affects normal transactions too. But I'm focused in Payjoin because it should allow private transactions. The problem I see is that Payjoin shouldn't allow that the sender or the receiver of the transaction can get information about the bitcoin balance of each other. A person could have his savings in btc in a single address, use Payjoin to send/receive a payment thinking it's private and leaking to the receptor he has a high amount of btc. But an automatic splitting to itself in the background could solve the problem (maybe 100$ amounts) or so. >There's certainly some interesting about the idea of "pre-fragmenting" your >wallet utxo so you can make (or in payjoin: receive) payments with better >privacy aspects.However, it's pretty unlikely to be practical for normal >users, as it'll generally result in pretty big and cost-ineffective >transactions. For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature. i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each. I would prefer wait some time and have privacy than the opposite. Regards From: rha...@protonmail.com Sent: Thursday, March 21, 2019 17:52 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well. There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions. In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet. -Ryan ‐‐‐ Original Message ‐‐‐ On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev wrote: Hi, I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it: - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount. What do you think? Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Payjoin privacy with the receiver of the transaction
Hi, I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it: - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount. What do you think? Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Greetings, I think extension blocks could be optional, and it could be many different extension blocks with different functionalities like Confidential Transactions or smart contracts. Only the interested nodes would enable this extension blocks, the rest would see only the classic blockchain without extension blocks. So it's not a matter of "old" and "new" nodes, all are updated nodes with extension blocks enabled or not. The only ones that need to understand the protocols of all existing extension blocks are the miners, which must verify that transactions from "anyone-can-spend" to a "classic" address are legal. So this is what a node with all extension blocks disabled would see in the blockchain: * Classic address to classic address: as always * Classic address to extension block address: transaction to "anyone-can-spend" * Extension block address to classic address: transaction from "anyone-can-spend" * Extension block address to extension block address: it doesn't see it because it doesn't download the extension blocks, only the main blocks. All coins that are in extension blocks are also in the "anyone-can-spend" address of the main blocks, so basic nodes are aware of the total number of coins. It's totally safe. So for the particular case of Confidential Transactions, it would work as explained. The CT transaction details would be in the extension block which could have the same size as the main block so the total size of the blockchain (main blocks + extension blocks) would be double. With this method bitcoin could add new features without losing the "store of value" property, as the base protocol never changes. Again, maybe I'm missing some technical detail here, I'm still learning 😊 Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Good morning ZmnSCPxj, Thank you for your answer. There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. I think old nodes don't need to know the CT part of the UTXO set. It would be possible to move coins from normal address to CT address and the opposite, it would be written as "anyone-can-spend" transactions in the main block so old nodes are fully aware of these transactions. Miners would enforce that "anyone-can-spend" transactions are true. The full details of the transactions involving CT would be in the extension block. CT to CT transactions don't need to be written in the main block. Maybe I'm missing some technical detail here but it looks good for me. > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Yes, there is an increase in block size and network usage but I think it would still be possible for people with regular computers to run a full node, an people in developing countries could use light wallets. Regards From: ZmnSCPxj Sent: Monday, February 11, 2019 5:29 To: Kenshiro \[\]; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set. SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend. Under this point-of-view, then, extension block is "not" soft fork. It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible. In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working. > - Safe: if there is a software bug in CT it's impossible to create new coins > because the coins move from normal block to normal block as public > transactions I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality. I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs. Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value. (do note that a non-extension-block approach is a definite hardfork) > - Capacity increase: the CT signature is stored in the extension block, so CT > transactions increase the maximum number of transactions per block This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Implementing Confidential Transactions in extension blocks
Greetings, What do you think about implementing Confidential Transactions in extension blocks? CT transactions go from extension block to extension block passing through normal blocks. It looks the perfect solution: - Soft fork: old nodes see CT transactions as "sendtoany" transactions - Safe: if there is a software bug in CT it's impossible to create new coins because the coins move from normal block to normal block as public transactions - Legal: Exchanges can use public transactions so regulators can monitor their activity - Capacity increase: the CT signature is stored in the extension block, so CT transactions increase the maximum number of transactions per block Regards ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
I understand, thank you! :) From: SomberNight Sent: Friday, December 28, 2018 22:41 To: bitcoin-dev@lists.linuxfoundation.org; tens...@hotmail.com Subject: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core Hi Kenshiro, That is not how the BIP process works. Instead of requesting the creation of a BIP, you just create one. :) Re CT in Bitcoin, I have my doubts whether you can get consensus for that. >From section 4.6 of the Bulletproofs paper [0]: "Bulletproofs ... are computationally binding. An adversary that could break the discrete logarithm assumption could generate acceptable range proofs for a value outside the correct range. ... An adversary that can break the binding property of the commitment scheme or the soundness of the proof system can generate coins out of thin air and thus create uncontrolled but undetectable inflation rendering the currency useless" I don't have the domain knowledge to debate whether quantum computers will ever exist but AFAICT their emergence would easily kill a currency that uses these kind of range proofs for confidential transactions. [0]: https://eprint.iacr.org/2017/1066.pdf > From: "Kenshiro []" tens...@hotmail.com > > Hi, > > I think Confidential Transactions (CT) are a great idea to provide enough > privacy for normal users (hidden amounts) and fungibility. > > I would like to request the creation of a BIP to implement CT in Bitcoin > Core. I read that CT are already implemented in Grin and Monero so it looks > that CT are enough mature to be implemented in Bitcoin. > > If the CT transaction size is 3x the size of a normal transaction the block > size could be increased by 3x too, or just keep the current block size and > make CT transactions optional. > > Thank you! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core
Hi, I think Confidential Transactions (CT) are a great idea to provide enough privacy for normal users (hidden amounts) and fungibility. I would like to request the creation of a BIP to implement CT in Bitcoin Core. I read that CT are already implemented in Grin and Monero so it looks that CT are enough mature to be implemented in Bitcoin. If the CT transaction size is 3x the size of a normal transaction the block size could be increased by 3x too, or just keep the current block size and make CT transactions optional. Thank you! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
