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
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello Mike, > > Mike Brooks via bitcoin-dev > writes: > > > Motivation > > > > Giving scripts the ability to refer to data on the blockchain will reduce > > transaction sizes because key material does not have to be repeated in > > every Script. Users of the network are rewarded with smaller transaction > > sizes, and miners are able to fit more transactions into new blocks. > > Pointers are a common feature and it felt like this was missing from > > Bitcoin Script. > > This would incentivize address re-use which would be bad for > fungibility. It appears you're trying to optimize a use case which is > already discouraged :( > Furthermore, right now block validation does not require access to the whole historical chain (only to the set of unspent outputs), so a change like this would massively increase storage requirements for validation. Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Hi,
On Fri, 19 Jul 2019 at 17:49, Mike Brooks wrote:
> Users will adopt whatever the client accepts - this feature would be
> transparent.
>
My skepticism was based in an assumption on my part that most such data is
produced by actors with a track record of neglecting transaction
efficiency. I'd be happy to be proven wrong, but considering say usage
rates of native witness outputs, or the fraction of transactions with more
than 2 outputs so far I see little evidence in support of widespread
adoption of cost saving measures. Assuming this is intended as a new script
version, all fully validating nodes need to commit to keeping all data
indefinitely before they can enforce the rules that make transactions
benefiting from this opcode safe to broadcast.
That said, if successful, the main concern is still that of address reuse -
currently there is no incentive in the protocol to do that, and with BIP32
wallets fewer reasons to do it as well, but this proposal introduces such
an incentive for users which would otherwise generate new addresses
(disregarding the ones that already reuse addresses anyway), and this is
problematic for privacy and fungibility.
Since address reuse has privacy concerns, I think it's important to draw a
distinction between clients accepting and producing such transactions, if
the latter were done transparently that would be very concerning IMO, and
even the former would not be transparent for users who run currently
pruning nodes.
I'm not sure how an O(1) time complexity leads to DoS, that seems like a
> very creative jump.
>
For what it's worth, that was in reference to hypothetical deduplication
only at the p2p layer, similar to compact blocks, but on further reflection
I'd like to retract that, as since both scenarios which I had in mind seem
easily mitigated.
Based on this response, it makes me want to calculate the savings, what
> if it was a staggering reduction in the tree size?
>
Assuming past address reuse rates are predictive this only places an upper
bound on the potential size savings, so personally I would not find that
very compelling. Even if the realized size savings would be substantial,
I'm not convinced the benefits outweigh the downsides (increased validation
costs, monotonically growing unprunable data, and direct incentive for
address reuse), especially when compared to other methods/proposals that
can reduce on chain footprint generally improve privacy while reducing
validation costs for others (e.g. batching, lightning, MAST for
sufficiently large scripts, Schnorr signatures (musig, adaptor signatures),
{tap,graft}root, ).
Regards,
Yuval
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Hi, On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: Giving scripts the ability to refer to data on the blockchain will reduce > transaction sizes because key material does not have to be repeated in > every Script. > Given that address reuse is discouraged, and as far as I know is predominantly utilized for customer deposit addresses by exchanges, many of which have not invested resources in batching withdrawals or consolidating small UTXOs, I am skeptical that such a feature would actually be utilized by users for whom a potential use exists, especially as mining fees are usually pushed onto customers anyway. Unless extensively utilized such that costs outweigh benefits, this change would impose an externality on validating nodes: With this list a newly created script can refer to a specific PUSHDATA that > was used in any previously confirmed block. > This would make pruning impossible, and also relaxes the bounds on validation costs since it would allow random reads on all historical data as opposed to just the UTXO set. Although it would do nothing for block capacity, perhaps this redundancy might be better addressed as opt-in functionality in the p2p layer? It might help with IBD, though at least in my experience peer latency (as opposed to throughput) is the limiting factor, and as far as I can tell this would increase it. Somewhat relatedly, transaction IDs are another type of pointer which might benefit from being encoded as a (block height, offset). However, here too it seems to me like the complexity is substantial, potentially introducing new DoS vectors, while saving several bytes per input at most. Regards, Yuval ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Good morning Mike, > PubRef is not susceptible to malleability attacks because the blockchain is > immutable. This is not quite accurate. While very old blocks are indeed immutable-in-practice, chain tips are not, and are often replaced. At least specify that such data can only be referred to if buried under 100 blocks. -- There are a number of other issues: * It strongly encourages pubkey reuse, reducing privacy. * There is a design-decision wherein a SCRIPT can only access data in the transaction that triggers its execution. In particular, it cannot access data in the block the transaction is in, or in past blocks. For example, `OP_CHECKLOCKTIMEVERIFY` does not check the blockheight of the block that the transaction is confirmed in, but instead checks only `nLockTime`, a field in the transaction. * This lets us run SCRIPT in isolation on a transaction, exactly one time, when the transaction is about to be put into our mempool. When a new block arrives, transactions in our mempool that are in the block do not need to have their SCRIPTs re-executed or re-validated. > In order for a client to make use of the PUBREF operations they’ll need > access to a database that look up public-keys and resolve their PUBREF index. > A value can be resolved to an index with a hash-table lookup in O(1) > constant time. Additionally, all instances of PUSHDATA can be indexed as an > ordered list, resolution of a PUBREF index to the intended value would be an > O(1) array lookup. Although the data needed to build and resolve public > references is already included with every full node, additional computational > effort is needed to build and maintain these indices - a tradeoff which > provides smaller transaction sizes and relieving the need to store repetitive > data on the blockchain. This is not only necessary at the creator of the transaction --- it is also necessary at every validator. In particular, consider existing pruning nodes, which cannot refer to previous block data. We would need to have another new database containing every `PUSHDATA` in existence. And existing pruning nodes would need to restart from genesis, as this database would not exist yet. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
Hello Mike, Mike Brooks via bitcoin-dev writes: > Motivation > > Giving scripts the ability to refer to data on the blockchain will reduce > transaction sizes because key material does not have to be repeated in > every Script. Users of the network are rewarded with smaller transaction > sizes, and miners are able to fit more transactions into new blocks. > Pointers are a common feature and it felt like this was missing from > Bitcoin Script. This would incentivize address re-use which would be bad for fungibility. It appears you're trying to optimize a use case which is already discouraged :( Cheers, Will -- https://jb55.com ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] PubRef - Script OP Code For Public Data References
I noticed that this Merkle tree we are building is made more expensive by including repetitive data. So, this proposal draws inspiration from LZ78, an algorithm which constructs a dictionary of repetitive strings which are then referred to by their index. What if the blockchain already built a dictionary for us, and now we just need to index it? --- Abstract This BIP describes how a new OP code can be used to construct smaller, more compact transactions. With a public reference (PubRef), a newly created transaction can reuse elements of a previously confirmed transaction by representing this information with a smaller numeric offset or “pointer”. Motivation Giving scripts the ability to refer to data on the blockchain will reduce transaction sizes because key material does not have to be repeated in every Script. Users of the network are rewarded with smaller transaction sizes, and miners are able to fit more transactions into new blocks. Pointers are a common feature and it felt like this was missing from Bitcoin Script. Specification This BIP defines a new Script opcode that can be introduced with BIP-0141 (Segregated Witness (Consensus layer)). This new opcode is as follows: Word Opcode Hex Input Output Description OP_PUBREF4 TBD TBD uint4 data The next four bytes is an integer reference to a previously defined PUSHDATA Let there be an ordered list of all invocations of PUSHDATA (OP codes; 0x4c,0x4d,0x4e) across all scripts starting from the genesis block: [t0,t2,...,tn]. With this list a newly created script can refer to a specific PUSHDATA that was used in any previously confirmed block. The values referenced by this list are immutable and uniform to all observers. Lets assume there is some transaction containing a ScriptSig and outputScript pair, here is what an input and an output script would look like: ScriptSig PUSHDATA(72)[30450221008f906b9fe728cb17c81deccd6704f664ed1ac920223bb2eca918f066269c703302203b1c496fd4c3fa5071262b98447fbca5e3ed7a52efe3da26aa58f738bd342d3101] PUSHDATA (65)[04bca69c59dc7a6d8ef4d3043bdcb626e9e29837b9beb143168938ae8165848bfc788d6ff4cdf1ef843e6a9ccda988b323d12a367dd758261dd27a63f18f56ce77] outputScript DUP HASH160 PUSHDATA(20)[dd6cce9f255a8cc17bda8ba0373df8e861cb866e] EQUALVERIFY CHECKSIG The ScriptSig of an input typically contains the full public key which is ~65 bytes. Outputs will typically contain a hash of the public key which is 20 bytes. Using PubRef, the public-key material shown above no longer need to be repeated, instead the needed values can be resolved from previously confirmed transaction. The signature of the input must still be unique, however, the public key can be replaced with a call to PUBREF, as shown below: ScriptSig PUSHDATA(72)[30450221008f906b9fe728cb17c81deccd6704f664ed1ac920223bb2eca918f066269c703302203b1c496fd4c3fa5071262b98447fbca5e3ed7a52efe3da26aa58f738bd342d3101] PUBREF[43123] outputScript DUP HASH160 PUBREF[12123] EQUALVERIFY CHECKSIG The above call to PUBREF removed the need to include the full public-key, or hash of the public key in a given transaction. This is only possible because these values where used previously in a confirmed block. If for example a user was sending Bitcoins to a newly formed address, then no PUBREF can be created in this case - and a outputScript using PUSHDATA would need to be used at least once. If a newly created wallet has never been used on the Bitcoin network, then the full public-key will need to be included in the ScriptSig. Once these transactions have been confirmed, then these values will be indexed and any future script can refer to these public-key values with a PUBREF operation. PubRef is not susceptible to malleability attacks because the blockchain is immutable. The PUSHDATA operation can store at most 520 bytes on the stack, therefore a single PUBREF operation can never obtain more than 520 bytes. In order for a client to make use of the PUBREF operations they’ll need access to a database that look up public-keys and resolve their PUBREF index. A value can be resolved to an index with a hash-table lookup in O(1) constant time. Additionally, all instances of PUSHDATA can be indexed as an ordered list, resolution of a PUBREF index to the intended value would be an O(1) array lookup. Although the data needed to build and resolve public references is already included with every full node, additional computational effort is needed to build and maintain these indices - a tradeoff which provides smaller transaction sizes and relieving the need to store repetitive data on the blockchain. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> I already told you that it is always possible to get around this: leverage >>> by use of short options. Short the coin to attack, then perform your attack by censorship. Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand. By this, you can steal the entire marketcap of the coin. >>> Yes, and of course stealing the value in the chain is not the only way to >>> profit from the destruction of its usefulness. PoS offers no defense >>> against the primary threat to permissionless money. As I told in my other mail, my trading level is very basic and I don't understand this type of attack. >>> In PoS, once a miner achieves necessary stake (also profitably) it can >>> censor indefinitely. It’s a big difference. Imagine you have 90% of coins, there 2 possible situations: 1 - You keep creating blocks in the main chain: then you can censor only in your 90% of blocks. Censored transactions are included in the other 10% of blocks. 2 - You stop creating blocks in the main chain to force others to follow your evil chain (which is longer) and then you can censor everything: that's a clear 51% attack that can be easily detected and your funds are burned in a hard fork. Even for the first case, with time the accumulation of old transactions in the mempool will be very evident for all nodes and I bet its possible to analyze the blocks and the mempool during some time until it's evident who is censoring transactions. >>> It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on >>> steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly >>> something to minimize. I copy the explanation of my other e-mail: "Not at all, I forgot to tell you that in modern PoS protocols like PoS v3.0 staking deposits have to wait many blocks after creating a block to be able to create another block. With my additional rule every staker is incentivized to put their staking deposit in a single address to avoid a strong penalty in their staking weight, and having their coins together they can't avoid the wait time with the "stake in many addresses" trick " Regards, From: Eric Voskuil Sent: Friday, July 19, 2019 7:10 To: ZmnSCPxj Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin On Jul 18, 2019, at 20:45, ZmnSCPxj mailto:zmnsc...@protonmail.com>> wrote: Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] mailto:tens...@hotmail.com>> wrote: Hi all, A 51% attack under proof-of-work is only possible, in general, if some singular entity were able to have physical control of almost 50%, or some such close number, of the globe, simply due to the fact that energy availability is somewhat distributed over the globe. Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest. If you look at this graph you will see that controlling 4 mining pools could be enough: https://www.blockchain.com/en/pools Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave. But also long term economic power, since leaving implies a lower proportional hash power, until another comparably-sized pool exists, but this is not the case when there is a majority hash power pool, which is economically inevitable until the majority miner starts censoring. https://github.com/libbitcoin/libbitcoin-system/wiki/Pooling-Pressure-Risk Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered). The invisible hand abides. This is why PoW is necessary, and why fee-based confirmation is necessary. It’s the only economically-rational way that the censor can be overpowered. But keep in mind the only net cost to the censor is the *premium* on censored transactions. https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash. So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically. While this proposal may introduce engineering improvements, it does not change any of the economic forces at work and therefore does not mitigate this issue. The pool controls the payout, and therefore retains power over tx selection
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>>Pools only have short-term power in that they can only temporarily attack >>>the coin until miners notice and then voluntarily leave. I agree >>>GPUs still require electricity to run, and are far easier to source. Hash change simply means that those with control of energy sources can easily purchase the needed hardware from many sources (as opposed to ASICs which are only sourced from a few places). So a hash change will only affect things temporarily, and it will still settle to the existing distribution of mining hashpower. I agree >>> I already told you that it is always possible to get around this: leverage >>> by use of short options. Short the coin to attack, then perform your attack by censorship. Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand. By this, you can steal the entire marketcap of the coin. >>>Then you still have the economic power (plus what you managed to steal), >>>which you can then use to take over another proof-of-stake coin, regardless >>>of whether it uses the same proof-of-stake algorithm or not. My trading level is very basic and I don't understand this attack >>> this happens every day in Bitcoin, and nobody particularly cares. You just wait for confirmations that in practice are impossible for some orphaned chain to persist. But is very different. In a normal situation you only have to wait a few blocks and you know your transaction is final, but a network split of 24 hours is another thing: could happen that you sent a big amount to btc to an exchange, the exchange waited 5-6 blocks to be sure and then you use your balance in that exchange to buy a big amount of other coin. Then this network split happens and the losing chain is yours, so you send back to yourself your bitcoins with a high fee, this could cause strong loses to exchanges or normal people that received a big payment for something. I prefer the community driven merge of both chains in my PoS protocol >>> But your proposal of being non-linear on the size of the stake means that >>> if you have 51% of the coins, if you put them in a single stake UTXO you >>> potentially get 99.999% of the blocks, which is ***much worse***. Not at all, I forgot to tell you that in modern PoS protocols like PoS v3.0 staking deposits have to wait many blocks after creating a block to be able to create another block. With my additional rule every staker is incentivized to put their staking deposit in a single address to avoid a strong penalty in their staking weight, and having their coins together they can't avoid the wait time with the "stake in many addresses" trick >>> We hope to see you back soon after having learned your lesson. Thx Just an additional question: do you have an estimation of the energy waste of PoW if Bitcoin price rises a lot, like one million dollars or more? Because if it's proportional to the price, it could be like 100 times the current energy waste. Regards, From: ZmnSCPxj Sent: Friday, July 19, 2019 5:45 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote: > Hi all, > > >>> A 51% attack under proof-of-work is only possible, in general, if some > >>> singular entity were able to have physical control of almost 50%, or some > >>> such close number, of the globe, simply due to the fact that energy > >>> availability is somewhat distributed over the globe. > > Mining is not only about the energy sources, individual miners spread around > the globe can join big mining pools, and these mining pools could be hacked > to participate in a 51% attack. Some governments (or other groups) could plan > this type of attack if it's in their interest. > > If you look at this graph you will see that controlling 4 mining pools could > be enough: > > https://www.blockchain.com/en/pools Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave. Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered). The invisible hand abides. Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash. So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically. > > >>> Secondly: change of hashing algorithm is pointless in the highly unlikely > >>> case of a 51% attack, because what matters is control of energy sources.
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi all, >>> A 51% attack under proof-of-work is only possible, in general, if some >>> singular entity were able to have physical control of almost 50%, or some >>> such close number, of the globe, simply due to the fact that energy >>> availability is somewhat distributed over the globe. Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest. If you look at this graph you will see that controlling 4 mining pools could be enough: https://www.blockchain.com/en/pools >>> Secondly: change of hashing algorithm is pointless in the highly unlikely >>> case of a 51% attack, because what matters is control of energy sources. As far as I know, if the PoW algorithm changes to an ASIC resistant algorithm that can only run in GPUs or CPUs, the hashing power would be much more distributed at least until someone creates a new ASIC for that algorithm. There are many GPUs around the globe, but not so many ASIC miners right? >>> Nothing can be more efficient than proof-of-work, and the proof-of-stake >>> delusion is simply a perpetual motion machine that attempts to get >>> something from nothing. As time passes and more PoS coins appears, including big projects like Ethereum, we will see if it's delusional or not I forgot one, if you do a 51% attack to a PoS coin you know that all your staking funds will be burned. In a PoW coin you don't lose your miners and can use them to mine or attack another coin with the same algorithm. >>> You must understand that removing the chain tip puts the transactions in >>> that block back in the mempool, before we ever start following the longer >>> chain. Yep but it could make double spend attacks very easy. People would know what is happening and could send the money to themselves with a higher fee to recover it. Many people would lose money with that. To fix that problem with a PoS algorithm, some community-guided initiative could get all transactions of both chains and create a merged chain with a hard fork so double spends attacks would not be possible. This could be somewhat slow, maybe the network is stopped a few days, but in the end no one will see money disappear from their wallet, much better than pray that your payer doesn't send the money back ato himself. >>> Hard forks are very difficult to coordinate as the user set increases in >>> size. I don't think many people will vote against a hard fork if the network is clearly under a 51% attack or the blockchain has 2 branches longer than N due to an internet split. >>> This solution is worse than the problem, and speeds up the dominance of >>> large stakers over the coin, trivially letting someone with the largest >>> stake in the coin grow their stake even faster. I think it's very evident that the rich guy earn coins faster in both algorithms. In PoS if you have 51% of the coins and use them to stake, you make 51% of the blocks, I don't see any problem with that. If you decide to do a 51% attack, stopping doing blocks in the main chain to force the others to follow your "private" chain, well, you know for sure your funds will be burned in the next hard fork. >>> No, I think it will be very successful in ensuring that smart individuals >>> will spend their time actually doing things that benefit the economy and >>> technology instead of wasting their time being distracted with Ethereum and >>> proof-of-stake. Ok, we the PoS advocates will let the smart people to work in more difficult issues like finding reasons to justify the energy waste and heat generation of PoW when Bitcoin price reaches 1 million dollars Regards, From: ZmnSCPxj Sent: Thursday, July 18, 2019 16:15 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning, > I think there is some misunderstanding here. A single node can be isolated > from the rest of the network any time and when it reconnects it only has to > follow the longest chain as always. Checking with a block-explorer or a > friend's node is only required under the extreme situation of being under a > 51% attack, but that is also a problem for Proof Of Work. Both protocols > require manual intervention: > > -PoS: Burn the funds of the attacker with a hard fork > -PoW: Change the PoW algorithm with a hard fork Again: under proof-of-work, 51% attacks are a lot less feasible than under proof-of-stake. You really should have researched this by this point, but in any case. The primary source of energy on Earth is the formation of the solar system. Some areas were seeded with radioactive materials. Later on, some areas were seeded with carbohydrates from dying biological processes.
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
> On Jul 18, 2019, at 20:45, ZmnSCPxj wrote: > > Good morning Kenshiro, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ >> On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote: >> >> Hi all, >> > A 51% attack under proof-of-work is only possible, in general, if some > singular entity were able to have physical control of almost 50%, or some > such close number, of the globe, simply due to the fact that energy > availability is somewhat distributed over the globe. >> >> Mining is not only about the energy sources, individual miners spread around >> the globe can join big mining pools, and these mining pools could be hacked >> to participate in a 51% attack. Some governments (or other groups) could >> plan this type of attack if it's in their interest. >> >> If you look at this graph you will see that controlling 4 mining pools could >> be enough: >> >> https://www.blockchain.com/en/pools > > Pools only have short-term power in that they can only temporarily attack the > coin until miners notice and then voluntarily leave. 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
Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote: > Hi all, > > >>> A 51% attack under proof-of-work is only possible, in general, if some > >>>singular entity were able to have physical control of almost 50%, or some > >>>such close number, of the globe, simply due to the fact that energy > >>>availability is somewhat distributed over the globe. > > Mining is not only about the energy sources, individual miners spread around > the globe can join big mining pools, and these mining pools could be hacked > to participate in a 51% attack. Some governments (or other groups) could plan > this type of attack if it's in their interest. > > If you look at this graph you will see that controlling 4 mining pools could > be enough: > > https://www.blockchain.com/en/pools Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave. Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered). The invisible hand abides. Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash. So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically. > > >>> Secondly: change of hashing algorithm is pointless in the highly unlikely > >>>case of a 51% attack, because what matters is control of energy sources. > > 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
