Topic: please delete (Read 333 times)

Miners validate each other's blocks all the time.
A chain is valid as long as it's blocks are valid.
A block is valid as long as it's txs are valid.
A tx is valid as long as it's inputs reference previously validated utxos- or the 2nd coinbase tx in a genesis block.

That would be true if the process of creating a new genesis block required
you to immediately destroy all of your tx history without validation.
But that's the opposite of what I stated in my OP.

Any time a user lacks the tx history necessary to validate txs,
their best option is to accept the chain with the most work. It's
based on the assumption that the honest network will always have
a superior hash rate.

Of course there's always a risk that the hashrate could go down or an
attacker could gain more power than the network so, that's why we
(the market) want to encourage mining. Bitcoin is nothing
without security and the security scales directly with the hashrate.
So the best way to encourage mining is to deriving the price from
the hashrate (current hash rate ehs) / $0.01.

According to https://www.coinwarz.com/network-hashrate-charts/bitcoin-network-hashrate-chart,
the current hash rate is 79.9471 ehs and the price is $9,149.06.

79.9471 / $0.01 = $7,994.71 so it's about %14 over-priced atm.
We really need to get this hashrate up!

Checkout "importprunedfunds".

You have no clue about what is called "rational" ... I get it now.
An attacker is not a mindless, irrational body. Costs should be justified and there should be incentives ways higher than costs. Is it that hard to understand?
Your "sabotage" argument is void and useless in the context of any discussion about bitcoin. People attack bitcoin to steal funds, not for fun!

This seems to be naive, I'm done reading such "paper"s. Bitcoin core is already immune to such an attack with its checkpoints and the limitation put on the fork length and prevention of forks beyond the checkpoint.

Recently I've provided a strong mathematical base for mitigating this class of attacks:
How far can possibly bitcoin blockchain height diverge from the ideal one- block-per-10-minutes measure?

I did it because of a similar DoS vulnerability proposed by somebody (and fixed later) regarding the bitcoin core getHeaders message. I've mathematically proven that the length of the blockchain regardless of what happens to the network hash rate and difficulty has upper bound and nodes can easily calculate it by looking at their local time and being aware of Jan-3-2009, the Genesis.

It is also possible to establish more sophisticated mathematical measures that compare the claimed chain height with the target difficulty because for a longer chain you need a higher difficulty, as a general trend.

Are you sure? but it is what shills do, they are guardians who try to save bitcoin from aliens  

Report me as a bad employee to the boss, they'll fire me  

anyone wanting to attack the network doesn't care about participating in it rationally, you appear to be have some kind of carpal tunnel syndrome affecting your focus (along with the crohns disease or whatever your latest story is).

this is also not the only possible attack, a recently discussed DoS vector would be so much easier under this "phoenix blocks" idea you are endorsing: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017354.html

tl;dr, it's cheap to create low work headers chains longer than the current ("real") chain. By flooding low work long chains, an attacker can force node to store the chains (which need to be evaluated) to exhaust their memory. Fixing this means re-writing the headers syncing code in the p2p rather significantly, not a small undertaking.



i don't claim to be "here to save bitcoin"

publish your code. remember, the code you've spent months and years working on, and talkng about? you've got nothing, haven't you? zero lines of code.

What's the difference between the two? Nothing! Absolutely nothing as far as we are talking about less than 250 Million dollars of assets. Do you need more security? Set the threshold to be higher, go for 10,000 blocks it gives you 1+ billion dollars security.

As of "sabotage" attacks: Bitcoin is not about sabotage, it is absolutely out of context. Bitcoin is about the rational behavior of players, not a crazy person/organization who is willing/allowed to waste one billion dollars to create panic and stress in bitcoin (it recovers eventually). Such an attack is never going to happen. Full nodes are not installed and run by people to resist against "sabotage" attacks. You need to review the game theory behind the bitcoin original design, we don't think or talk about irrational behaviors too much, it would be just a distraction.

An attacker with such a huge hash power could easily commit sophisticated double-spend attacks by short-range rewrites against exchanges and individuals instead of wasting his resources to fool some noebs who are setting up new full nodes to keep track of their few thousand dollars worth of bitcoins instead of going SPV! What I'm proposing eliminates SPVs from the ecosystem and allows mobile wallets to be a true full node taking a real part in the consensus and you are worried about "sabotage"? Kidding?

It is pure trolling. I'm absolutely not surprised, you are a known shill  
Otherwise, I'm bad    you need to be good, don't you?
Be a good person and commit to a good idea, instead of bragging with few lines of code other people write. Behind any good code is mathematics and algorithms discussed to death, don't be naive.

and there's the problem

right now, an attacker needs to recompute block header hashes for the current chain all the way back from Jan 3rd 2009 until the current tip to create an alternative valid blockchain with more work than the current chain. So not much then!

This "solution" brings that threshold forward to 2000 blocks previous to the latest "phoenix" block (calling it the "new" or "latest" genesis block is plainly bizarre), which would be a rational attack if the objective is sabotage. And it would take a comparatively trivial amount of hash power to do it.


We've heard your posturing about rolling UTXO set security models, but actual developers who have actually released production code that's being used in the real world still haven't done anything that's become relevant. I'm not ruling out the possibility, but considering they're usually coding and releasing code, and you're usually talking and never releasing any code, well, let's just allow people to draw their own conclusions from that

Obstacles that are very easy to overcome but let's make it crystal clear before proceeding any more: There is a decent version of op's proposal called UTXO commitment (as @ETFbitcoin reminded it above) with a very old history in bitcoin discussions and IMO, a delayed_for_no_reason one as well.
Now back to your arguments:
Suppose we ask nodes to commit to the hash of the UTXO they have been using before the fresh block they are working on. This hash is practically representing the state of the blockchain as of the latest confirmed block. Such a commitment could be easily done in the coinbase transaction like what op suggests or segwit is using now.
In such a situation:
1- Upgraded full nodes can trivially verify this state to be the same as theirs, rejecting false claims while legacy nodes remain indifferent regarding this item, hence, it would be a soft-fork.

2- Pruning works better as nodes can confidentially remove larger parts of the blockchain history.

3- Bootstrapping is done in a more sophisticated but efficient way:

• a) A Fresh uninitialized node asks peers to announce their latest block headers, thereafter it continues starting from the heaviest chain claimed:
• b)It calculates the height of the chain by which it can be convinced about its security.
  Suppose the user has chosen 100,000 Zetta hash as its security assurance threshold (an attacker with total hash power of the current bitcoin network being busy for like a week to defraud the user), each block with current bitcoin difficulty represents 60 Zetta hash and if difficulty was fixed this user would need 1,667 blocks long blockchain to be convinced about its security, with a heuristic assumption about possible difficulty change the node chooses 2,000 blocks as being safe.
• c)The fresh node downloads headers from the pear in reverse order from the latest block #N down to earliest, block #(N-2000)
• d) it verifies the integrity of headers just like an SPV wallet.
• e) After downloading block #(N-2000), the node queries the peer for the coinbase it commits to,  extracting the UTXO hash it has committed to afterward.
• f) It downloads the UTXO as it was committed to at block #(N-2000) from the peer. This reflects the state of the blockchain as of block #(N-2001) as long as it is consistent with its committed hash.
• g) Being convinced about the state of the database at block (#N-2000), our bootstrapping node now starts full validation of all 2000 blocks one by one up to block#N.
  

As of efficiency considerations, there are good algorithms and techniques proposed. Check this one for instance:
https://github.com/tomasvdw/bitcoin-abc/blob/utxoflat/src/secp256k1/src/modules/multiset/README.md

but if you download all the genesis blocks (and the blocks in between), that problem goes away! Then you would know the provenance of every UTXO! You could even dispense with having multiple genesis blocks, wouldn't having just one genesis block work better? Where could we put that block in the history... it'd help if the word "genesis" even meant something! btw has anyone seen my glasses?

The usual rules require you to follow the VALID chain with the largest difficulty sum.

By creating a new genesis block, you completely destroy the ability for any node to determine the validity of the UTXO set.  You FORCE the users to accept the chain with the largest difficulty sum instead of the VALID chain with the largest difficulty sum.  This creates a disaster every time there is a new Genesis block.  Any transaction that had MANY confirmations, suddenly has only 1 confirmation.  There is no way to know if that genesis block you just received is the ONLY genesis block out there, or if there are dozens of competing genesis blocks all being worked on by different miners.  You have to wait for multiple blocks all over again to be confident of which funds are actually in the blockchain.  Furthermore, this gives an attacker an opportunity every week to solve just one block and completely re-write whatever funds they want to.  They can create a completely fraudulent block that gives themselves control over most of the funds, and get it broadcast quickly so that it gets built upon.  Once it has a few blocks on top of it, it becomes truth, regardless of what happened before the Genesis block.

Like I already pointed out...

You need to "put a bit more thought into what the current blockchain concept actually accomplishes and how it accomplishes it before trying to replace it without knowing what you need to protect against."


No thanks.  If I plan on trusting, I'll just use the efficient and existing banking infrastructure as provided by governments and private institutions.

If I'm using a blockchain solution, it's specifically so that trusting isn't necessary.

That's the thing though, a node won't know what the longest chain following a checkpoint-genesis-block is until they have downloaded and validated all subsequent blocks.

Worse still, they have to do this check for each checkpoint-genesis-block they receive, every time. Even without someone actively trying to attack the network this would put you in a situation where each checkpoint-genesis-block would be followed by an increased orphan rate, making it a very risky and unreliable time frame to accept payments.

Not about that, it's about the data inside the "new genesis block(s)" which enables some users to delete the older blocks.
How can a node verify the previous unspent transactions that were deleted with the previous deleted blocks?

The main problem with pruning is that you can't import a pre-funded address anymore. Syncing isn't that much of a problem, I recently did something stupid which forced my pruned Bitcoin Core to re-download everything. My laptop is approximately 5 years old and it wasn't state of the art when I bought it, but running Linux with enough RAM, the chainstate directory on SSD and an increased dbcache, it took just 1 full day to sync again.
If you're limited on bandwidth or hardware it can still be problematic, but instead of trusting someone else with some arbitrary starting point, why don't use you a wallet that doesn't require downloading the full blockchain?

And when you receive such a block, how can you tell if the transactions in the block are valid?  What do you compare them to? If you receive multiple different new genesis blocks, how do you know which one is the right one?


Clearly.  If you were, you'd have put a bit more thought into what the current blockchain concept actually accomplishes and how it accomplishes it before trying to replace it without knowing what you need to protect against.

I might be wrong but that sounds like you'd get a really huge checkpoint block every N blocks which would make an especially critical block especially likely to be orphaned.

Have you looked into MimbleWimble? It's cut-through approach for getting rid of blockchain bloat may be of interest to you:
https://github.com/mimblewimble/grin/blob/master/doc/intro.md



The smallest recommended prune setting is 550, ie. 550 blocks. So that's worst case maybe 2gb, assuming blocks full of the most bloated possible SegWit transactions. In practice that's currently probably closer to 0.4 - 0.7 gigs.

Pruning is good but not enough. Syncing transactions is a nightmare and what makes pruning almost useless.

Ahhh are you yet to find the prune option which means you only have to store a small amount of the chain (I think it's 4gb min or it used to be). This means you can sync transactions and keep the mempool avaliable but also allow for lara data you don't need to be deleted.

The last 100000 blocks also are the ones bloated the most. When we were in the early 500000s we were at about half the size we are now.

This might give more information if you're interested in running a pruned node: https://bitcoin.stackexchange.com/questions/37496/how-can-i-run-bitcoind-in-pruning-mode

nothing to see