Kenshiro [] [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-12-27 to 2019-08-03
💬 Posted a total of 25 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1pnn79vddxfx38glw3fa3cslhnw5vmfjaq80mchjaxrdwef7r5kvqz9cs5z

Profile Code

nprofile1qqsqeelzkxknyngn50hg57cug0meh2xd5ewsrhautewnpkhv5lp6txqqj6dnz

Author Public Key

npub1pnn79vddxfx38glw3fa3cslhnw5vmfjaq80mchjaxrdwef7r5kvqz9cs5z

Show more details

Last Notes

2023-06-07 18:19:50

- reply

📅 Original date posted:2019-08-03
📝 Original message: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 <willtech at live.com.au>
Sent: Saturday, August 3, 2019 2:51
To: Ethan Heilman <eth3rs at gmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>; Kenshiro [] <tensiam at hotmail.com>
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-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Kenshiro [] via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Friday, 2 August 2019 11:08 PM
To: Ethan Heilman <eth3rs at gmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
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 <eth3rs at gmail.com>
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] <tensiam at hotmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Cc: Alistair Mann <al at pectw.net>
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 <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at 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 [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al at pectw.net<mailto:al at pectw.net>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at 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 <al at pectw.net<mailto:al at pectw.net>>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
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 at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190803/954f387d/attachment-0001.html>

2023-06-07 18:19:49

- reply

📅 Original date posted:2019-08-02
📝 Original message: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 <eth3rs at gmail.com>
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] <tensiam at hotmail.com>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Cc: Alistair Mann <al at pectw.net>
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 <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at 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 [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al at pectw.net<mailto:al at pectw.net>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at 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 <al at pectw.net<mailto:al at pectw.net>>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam at hotmail.com<mailto:tensiam at hotmail.com>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
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 at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/98a6f15e/attachment.html>

2023-06-07 18:19:49

- reply

📅 Original date posted:2019-08-01
📝 Original message: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 <al at pectw.net>
Sent: Thursday, August 1, 2019 1:28
To: Kenshiro [] <tensiam at hotmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190801/c201578b/attachment.html>

2023-06-07 18:19:47

- reply

📅 Original date posted:2019-07-31
📝 Original message:P.S.: To be clearer, in this example I set an N value of 144 blocks, which is approximately 24 hours.
________________________________
From: Kenshiro [] <tensiam at hotmail.com>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al at pectw.net>; Bitcoin Protocol Discussion <bitcoin-dev at 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 <al at pectw.net>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam at hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190731/17039920/attachment-0001.html>

2023-06-07 18:19:47

- reply

📅 Original date posted:2019-07-31
📝 Original message: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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190731/15e4161f/attachment.html>

2023-06-07 18:19:47

- reply

📅 Original date posted:2019-07-31
📝 Original message:>>> 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 <al at pectw.net>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam at hotmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190731/e2c2346a/attachment-0001.html>

2023-06-07 18:19:41

- reply

📅 Original date posted:2019-07-23
📝 Original message: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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190723/4b8e8d3b/attachment-0001.html>

2023-06-07 18:19:27

- reply

📅 Original date posted:2019-07-24
📝 Original message: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 <ZmnSCPxj at protonmail.com>
Sent: Wednesday, July 24, 2019 6:14
To: Kenshiro [] <tensiam at hotmail.com>
Cc: Eric Voskuil <eric at voskuil.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190724/15bd1a1b/attachment.html>

2023-06-07 18:19:26

- reply

📅 Original date posted:2019-07-20
📝 Original message: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 100001 coins splitted in 100001 addresses:
stakingWeightPerAddress = 1 ^ 1000 = 1
stakingWeightPerAddress * numberOfAddresses = 1 * 100001 = 100001 (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 <ZmnSCPxj at protonmail.com>
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", as you indicated.
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.
Thus it has 100% of the stake during those 100 blocks.
The honest whale gets 1 block (with very high probability) and then the evil whale gets the rest of the blocks for 100 blocks.
?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 (even though the evil whale appears to be multiple separate stakers) because 50% + 50% = 100%.
I did indicate "each of them owns 50% of the total staked value", did I not?
The rest of your counterargument ***completely forgets*** this, so I will ignore it.
A whale composed of many tiny fishes is still a whale.
It is immaterial that there may exist many small stakers who individually can overpower a tiny stake of the evil whale: the evil whale will still dominate during those times that the honest whale is banned because of your additional rule that "a staker who creates a block is banned from creating another block for many blocks": the evil whale simply dominates from having many tiny stakes, each of which can be banned with little effect on the actual power of the evil whale over the coin.
> >>> 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.
It is immaterial: what matters is the economics.
Dirty energy is dirty because it causes damage to the economy by creating sickness and preventing people from surviving long lives and producing for the economy, destroys ecology and reduces biodiversity (and many products are derived from the variety of lifeforms available) and so on.
Thus, all energy uses will inevitably move towards cleaner energy sources as competition arises.
>
> >>> 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.
You have demonstrated no such thing, merely demonstrated your own willful incompetence in designing protocols.
I will no longer respond.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190720/e3748e47/attachment-0001.html>

2023-06-07 18:19:25

- reply

📅 Original date posted:2019-07-20
📝 Original message: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 <ZmnSCPxj at protonmail.com>
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 proof-of-stake algorithm or not.
>
> My trading level is very basic and I don't understand this attack
A short option is an option to force another party to buy an asset at a set price (the contract price) on a future date.
In order to get that option, you first pay that party today, a fee called "premium" (usually a small fraction of the contract price).
The effect is that, at that future date, if the asset is ***lower*** in price than the contract price, you earn by buying it at the market price, then force the party to buy it at the contract price, earning the difference.
The other party, in order to mitigate its loss, then sells the asset back to the market at market price.
(in practice, nobody goes through the rigmarole of buying, forcing the trade, then selling, instead the other party just outright gives you the difference in contract price vs market price).
However, if at that future date, the asset is ***higher*** in price than the contract price, there is no rational reason for you to buy it at market price, then force the other party to buy at the contract price, as you would lose money.
As this is an option for you, not an obligation, you can simply ignore the option and not take it.
However, do note that you did pay the premium when you bought the option, so you lose out on that.
Short options are often used by producers of a good in order to hedge their losses, i.e. insurance against changes in market price.
For example, a farmer might purchase such an option, with a maturity date at the harvest season, for the price of wheat.
The farmer would buy an option whose contract price is the price at the threshold of profitability, i.e. if the price falls below the contract price the farmer would lose money relative to their investment.
If the price of wheat drops below the contract price, the farmer earns from the short option, reducing the impact of the low price.
If the price of wheat is above the contract price, the farmer still earns from sale of the wheat, and only loses on the (comparatively small) premium of the option.
A short option can be leveraged by those with inside knowledge as an economic attack.
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.
Then you attack the coin, dropping its price by 90% instead of the expected 10% price increase, earning the difference from the short option, about equal to the price of the coin.
Since you bought twice the number of options as your stake, you get about twice the value of your stake in earnings from the short option.
You have recouped the cost of your stake and would not care if it was burned, and now are holding twice the value of your original stake in a different asset, probably fiat.
You then move on and attack the next coin.
The only protection against this is to make sure that block generators cannot feasibly attack the coin, such as by proof-of-work.
Short options are much too useful otherwise to the block generators, as it allows them to hedge against drops in market price, and keeps them operating rather than reducing the security of the coin, thus short options will inevitably arise.
> >>> 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 🙂
*facepalm*
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.
The honest single-UTXO whale gets a block, because his stake dominates over all others.
Then he gets banned from signing blocks for 100 blocks.
During this ban, the other whale gets every block, as his only competitor is banned.
In addition, banning one of its 100,000 UTXOs is not much reducing his effective stake-weight.
So the honest single-UTXO whale gets 1 block (and its rewards) while the one who distributed his coins to 100,000 different UTXOs gets 100 blocks.
You have just let someone who could *just barely* 51% attack without those rules, 99% attack *with* those rules.
If you had added neither of the two new rules "non-linear stake weights" and "ban for many blocks", you would have gotten both of them at 50% control only, which while concerning, is not as bad as a 99% attack.
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.
You should stop adding even more rules at this point.
An experienced engineer will stop at this point, delete all his or her files related to the current design (or move them to some archive space, some engineers are compulsive archivists), then regenerate the design from principles up.
A rule-of-thumb in any security design is that, when you add something to protect against some attack, you probably just added an attack vector that is the inverse of the attack you were protecting against.
Thus, adding more rules is rarely the optimal thing to do.
You added two rules, one fixing the original attack (splitting your stake) but inviting the opposite attack (merging your stake), then added another rule to fix the second attack (merging your stake), bringing back the original attack (splitting your stake), except worse.
This is the other rule-of-thumb in any design: adding more things usually just makes things worse.
>
> >>> We hope to see you back soon after having learned your lesson.
>
> Thx 🙂
You are welcome.
>
> 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.
Yes.
0.
This is because we expect market forces to move miners towards efficiency, thus they will not waste energy, only spend exactly enough to maintain the security of the coin.
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.
This is the opposite of becoming more energy-wasteful.
Thus does the invisible hand of the free market abide.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190720/cdc354ef/attachment-0001.html>

2023-06-07 18:19:24

- reply

📅 Original date posted:2019-07-19
📝 Original message: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 <ZmnSCPxj at protonmail.com>
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 [] <tensiam at 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.
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.
>
> 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?
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.
>
> >>> 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.
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.
At least mining hardware are physical hardware and subject to deprecation over time.
>
> >>> 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.
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.
>
> >>> 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.
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***.
Just admit that you have no real solution to knowing how much every entity controls of your coin.
>
> >>> 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 😉
We hope to see you back soon after having learned your lesson.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190719/80cab126/attachment-0001.html>

2023-06-07 18:19:23

- reply

📅 Original date posted:2019-07-19
📝 Original message: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 <eric at voskuil.org>
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 <ZmnSCPxj at protonmail.com<mailto:ZmnSCPxj at protonmail.com>> wrote:
Good morning Kenshiro,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 18, 2019 11:50 PM, Kenshiro [] <tensiam at hotmail.com<mailto:tensiam at 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 regardless of who selects and grinds on them.
https://github.com/libbitcoin/libbitcoin-system/wiki/Decoupled-Mining-Fallacy
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?
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.
Yes
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy
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.
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.
https://github.com/libbitcoin/libbitcoin-system/wiki/Fedcoin-Objectives
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.
At least mining hardware are physical hardware and subject to deprecation over time.
Capital cost isn’t the source of this defense, it’s the ability to introduce as much power as necessary to evict the censor, paid for by the rising premium on censored txs. Without this the majority miner can mine indefinitely and be the most profitable. This is of no consequence to confirmation until censorship begins.
In PoS, once a miner achieves necessary stake (also profitably) it can censor indefinitely. It’s a big difference.
https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles
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.
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.
Yes, and of course the same scenario as described above can also occur with PoW. Gather up the victims, invest in mining a stronger chain, get the profit from the mining investment, and get your money back.
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.
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***.
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.
Just admit that you have no real solution to knowing how much every entity controls of your coin.
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 😉
We hope to see you back soon after having learned your lesson.
Let’s all be nice. But WRT energy waste... see last paragraph for a consideration of waste in relation to any other monetary options.
https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy
e
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190719/549cfa18/attachment-0001.html>

2023-06-07 18:19:22

- reply

📅 Original date posted:2019-07-18
📝 Original message: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 <ZmnSCPxj at protonmail.com>
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.
Regardless, continuously the sun shines upon the just and unjust alike.
Thus, while there is significant variance in energy availability, it is still reasonably spread out.
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.
Looking into latest human political maps, I cannot find any singular entity that can claim this.
Secondly: change of hashing algorithm is pointless in the highly unlikely case of a 51% attack, because what matters is control of energy sources.
In case of hashing algorithm change, the exact same sources of energy can be utilized with whatever hardware is most efficient, and distribution of hashpower will still be the same.
The fact that proof-of-work is strongly bound to physical limitations is a feature, not a bug.
Economic incentives imply simply that market forces will move hashpower towards efficient usage.
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.
>
> 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.
Yes, that is better.
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.
Thus, transactions on the shorter chain will simply find themselves in the mempool waiting to be confirmed again.
Of course, they are still subject to replacement since they become unconfirmed, and there is still some risk involved.
> >>>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.
Do note the comment of "political money".
Hard forks are very difficult to coordinate as the user set increases in size.
>
> >>> Aside from that, this is possible to evade by running 10000 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
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.
> >>> 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?
>
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190718/f7a580da/attachment-0001.html>

2023-06-07 18:19:20

- reply

📅 Original date posted:2019-07-18
📝 Original message: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 10000 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 <ZmnSCPxj at protonmail.com>
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 be able to get all nodes into agreement about the global state, even after a network partition.
Ideally, such an algorithm would place as little trust as possible on some other node, and would work even in adversarial conditions.
To my understanding, the proposal from Kenshiro is not able to get all nodes into agreement about global state after a network partition, without trust in some node, when in adversarial conditions.
> > >>> 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.
>
> Censorship can steal everybody’s money.
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.
>
> > 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.
>
> Political money.
Aside from that, this is possible to evade by running 10000 masternodes and splitting your staking funds among them.
Rent from a botnet, and it appears the masternodes are geographically diverse.
Then it becomes hard to accuse the network of actually being controlled strongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might already be strongly controlled, but appear "healthy" because masternodes *appear* geographically diverse, but in actuality are controlled by a single entity)
Further, "detect if some transaction in the mempool" cannot provide a proof, as no construct ever precommits to the state of the mempool at a particular time (if it did, the mempool would cease to be a mempool and would be part of the block).
I can generate a completely new transaction, then accuse the masternodes of censoring it.
Other nodes may not believe me, as they have not seen my transaction on their mempool, but note that the mempools of nodes are ***not*** strongly synchronized.
By careful timing and control of the connectivity of the network, it becomes possible to effectively split the consensus algorithm by showing my transaction to some non-masternode nodes but keeping my transaction away from masternodes, then have the non-masternode nodes accuse the masternodes of censoring my transaction and hereby penalizing them.
But the masternodes would not agree, not having seen my transaction in their mempool, and thus is the network consensus destroyed.
Basically: "never base consensus rules on mempool state" is a good rule of thumb for ensuring that consensus can be maintained.
Consensus rules should consider only data that is committed to some block, and the mempool is not intended to be committed to in every block.
> > 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.
>
> Just another nail in the coffin.
I agree.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190718/209f7b8b/attachment.html>

2023-06-07 18:19:19

- reply

📅 Original date posted:2019-07-17
📝 Original message: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 <ZmnSCPxj at protonmail.com>
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 <bitcoin-dev at 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:
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 this effectively trusts the developers.
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.
> 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.
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.
>
> 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.
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.
Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction *does* get into the blockchain from the efforts of another block producer.
This is trivial under proof-of-work, and is the cost we accept in order to achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some single entity controls >51% of stakeable coins, and thus has no way to protect against censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake.
Depending on the PoS implementation, stake-grinding may allow a 49% staker to achieve 51% and thereby the ability to censor transactions.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190717/95445798/attachment.html>

2023-06-07 18:19:18

- reply

📅 Original date posted:2019-07-16
📝 Original message: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 <otech47 at gmail.com>
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 <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at 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 at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190716/6da2a50e/attachment.html>

2023-06-07 18:19:17

- reply

📅 Original date posted:2019-07-11
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190711/84c5080e/attachment.html>

2023-06-07 18:17:09

- reply

📅 Original date posted:2019-03-22
📝 Original message: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; rhavar at 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: rhavar at protonmail.com <rhavar at 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 <bitcoin-dev at lists.linuxfoundation.org> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190322/05f9ab2b/attachment.html>

2023-06-07 18:17:09

- reply

📅 Original date posted:2019-03-22
📝 Original message:>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: rhavar at protonmail.com <rhavar at 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 <bitcoin-dev at lists.linuxfoundation.org> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190322/4684a924/attachment-0001.html>

2023-06-07 18:17:08

- reply

📅 Original date posted:2019-03-18
📝 Original message: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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190318/e1d97bdb/attachment.html>

2023-06-07 18:16:27

- reply

📅 Original date posted:2019-02-14
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190214/7c4436b2/attachment.html>

2023-06-07 18:16:26

- reply

📅 Original date posted:2019-02-11
📝 Original message: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 <ZmnSCPxj at protonmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190211/ab2f22c4/attachment-0001.html>

2023-06-07 18:16:26

- reply

📅 Original date posted:2019-02-08
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190208/76fc982c/attachment-0001.html>

2023-06-07 18:15:55

- reply

📅 Original date posted:2018-12-29
📝 Original message:I understand, thank you! :)
From: SomberNight <somber.night at protonmail.com>
Sent: Friday, December 28, 2018 22:41
To: bitcoin-dev at lists.linuxfoundation.org; tensiam at 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 []" tensiam at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181229/71457bb6/attachment.html>

2023-06-07 18:15:54

- reply

📅 Original date posted:2018-12-27
📝 Original message: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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181227/06d06157/attachment.html>