Bitcoin Forum
December 10, 2019, 08:10:37 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Segmentation?  (Read 238 times)
SapphireSpire
Member
**
Offline Offline

Activity: 123
Merit: 20


View Profile
October 29, 2019, 11:01:56 PM
Last edit: October 30, 2019, 07:20:52 AM by SapphireSpire
 #1

Bitcoin needs to significantly reduce blockchain bloat by having miners
generate new genesis blocks every once in a while- say every 1,000
blocks, about once a week.

A new genesis block needs to contain a 2nd coinbase tx that
consolidates all previous coinbase txs since the previous genesis
block and copies of all previously validated utxos that are changed
to reference the 2nd coinbase tx instead of previous tx outputs.

This would not require anyone to delete old transaction data but it
would permit it. It would segment the blockchain and end the endless
growth. With regular blocks limited to 1MB, each segment would be
limited to 1GB- small enough for any smart phone.

Hey, I'm not a programmer so, if anyone creates a new SHA256 coin
(not a token) based on this or something similar, please let me know!
1575965437
Hero Member
*
Offline Offline

Posts: 1575965437

View Profile Personal Message (Offline)

Ignore
1575965437
Reply with quote  #2

1575965437
Report to moderator
1575965437
Hero Member
*
Offline Offline

Posts: 1575965437

View Profile Personal Message (Offline)

Ignore
1575965437
Reply with quote  #2

1575965437
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jackg
Copper Member
Legendary
*
Offline Offline

Activity: 1582
Merit: 1358


https://bit.ly/2FR9nyn - free python tutorials


View Profile
October 29, 2019, 11:18:10 PM
 #2

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

aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 726

always remember, remember the cause


View Profile WWW
October 30, 2019, 06:32:32 AM
 #3

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.
Pruning is good but not enough. Syncing transactions is a nightmare and what makes pruning almost useless.
HeRetiK
Legendary
*
Offline Offline

Activity: 1316
Merit: 1187


the forkings will continue until morale improves


View Profile
October 30, 2019, 05:34:17 PM
 #4

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


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 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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1848
Merit: 2123

Use SegWit and enjoy lower fees.


View Profile WWW
October 30, 2019, 05:43:21 PM
 #5

Personally i don't like the idea because Bitcoin would lost it's immutability property, since older transactions/blocks are gone.

IMO you better use SPV/light client wallet if you use smartphone.

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.

I think it's called UTXO commitment and different compared with OP's idea since older transaction/block isn't permanently moved, but simply not downloaded.

DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1583



View Profile
October 30, 2019, 06:00:26 PM
Merited by gmaxwell (1), LoyceV (1), hugeblack (1)
 #6

A new genesis block needs to contain a 2nd coinbase tx that
consolidates all previous coinbase txs since the previous genesis
block and copies of all previously validated utxos that are changed
to reference the 2nd coinbase tx instead of previous tx outputs.

This would not require anyone to delete old transaction data but it
would permit it. It would segment the blockchain and end the endless
growth.

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?

Hey, I'm not a programmer

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.

LoyceV
Legendary
*
Offline Offline

Activity: 1694
Merit: 5317


ArtIst > AI rtst


View Profile WWW
October 30, 2019, 06:25:25 PM
 #7

Pruning is good but not enough. Syncing transactions is a nightmare and what makes pruning almost useless.
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?

SapphireSpire
Member
**
Offline Offline

Activity: 123
Merit: 20


View Profile
October 31, 2019, 01:45:35 AM
 #8

And when you receive such a block, how can you tell if the transactions in the block are valid?
If you receive multiple different new genesis blocks, how do you know which one is the right one?
I follow the usual rules; I go with the longest chain mined at the hardest difficulty.
This is why the real price of Bitcoin is (current hash rate ehs) / $0.01.
nc50lc
Hero Member
*****
Offline Offline

Activity: 798
Merit: 825


Self-proclaimed Genius ㊙️


View Profile WWW
October 31, 2019, 04:57:24 AM
 #9

And when you receive such a block, how can you tell if the transactions in the block are valid?
If you receive multiple different new genesis blocks, how do you know which one is the right one?
I follow the usual rules; I go with the longest chain mined at the hardest difficulty.
This is why the real price of Bitcoin is (current hash rate ehs) / $0.01.
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?

SapphireSpire
Member
**
Offline Offline

Activity: 123
Merit: 20


View Profile
October 31, 2019, 05:29:28 AM
Last edit: October 31, 2019, 05:48:59 AM by SapphireSpire
 #10

And when you receive such a block, how can you tell if the transactions in the block are valid?
If you receive multiple different new genesis blocks, how do you know which one is the right one?
I follow the usual rules; I go with the longest chain mined at the hardest difficulty.
This is why the real price of Bitcoin is (current hash rate ehs) / $0.01.
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?
Miners would create new genesis blocks and they would compete
just like regular blocks. As soon as these blocks are created, miners
will validate them and pick one to mine on top of.

Any full node that has been connected to the network long enough
to be synced can validate new genesis blocks by referencing
all utxo in the previous segment before deleting them.

Any node that only recently connected and isn't synced can rely
on the PoW consensus mechanism to help distinguish genuine
genesis blocks from fakes, just as we do now with regular blocks.
That means trusting the longest chain representing the greatest
amount of work.
HeRetiK
Legendary
*
Offline Offline

Activity: 1316
Merit: 1187


the forkings will continue until morale improves


View Profile
October 31, 2019, 10:18:39 AM
 #11

Any node that only recently connected and isn't synced can rely
on the PoW consensus mechanism to help distinguish genuine
genesis blocks from fakes, just as we do now with regular blocks.
That means trusting the longest chain representing the greatest
amount of work.

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.

DannyHamilton
Legendary
*
Offline Offline

Activity: 2282
Merit: 1583



View Profile
October 31, 2019, 04:18:15 PM
Last edit: October 31, 2019, 04:34:29 PM by DannyHamilton
Merited by Foxpup (4), Carlton Banks (2), ETFbitcoin (1), hugeblack (1)
 #12

And when you receive such a block, how can you tell if the transactions in the block are valid?
If you receive multiple different new genesis blocks, how do you know which one is the right one?
I follow the usual rules; I go with the longest chain mined at the hardest difficulty.

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."

. . . That means trusting . . .

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.

Carlton Banks
Legendary
*
Offline Offline

Activity: 2576
Merit: 2114



View Profile
October 31, 2019, 04:59:24 PM
 #13

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.  

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? Grin

Vires in numeris
aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 726

always remember, remember the cause


View Profile WWW
October 31, 2019, 05:06:07 PM
Last edit: October 31, 2019, 05:40:32 PM by aliashraf
Merited by Welsh (6), d5000 (1), hugeblack (1)
 #14

Any node that only recently connected and isn't synced can rely
on the PoW consensus mechanism to help distinguish genuine
genesis blocks from fakes, just as we do now with regular blocks.
That means trusting the longest chain representing the greatest
amount of work.

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.
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


Carlton Banks
Legendary
*
Offline Offline

Activity: 2576
Merit: 2114



View Profile
October 31, 2019, 06:17:18 PM
Last edit: October 31, 2019, 11:54:07 PM by Carlton Banks
Merited by Welsh (3)
 #15

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:

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

Vires in numeris
aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 726

always remember, remember the cause


View Profile WWW
October 31, 2019, 07:51:03 PM
Last edit: October 31, 2019, 08:57:49 PM by aliashraf
 #16

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:

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 hash power to do it.
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?

Quote

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
It is pure trolling. I'm absolutely not surprised, you are a known shill  Wink
Otherwise, I'm bad  Cheesy  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.
Carlton Banks
Legendary
*
Offline Offline

Activity: 2576
Merit: 2114



View Profile
October 31, 2019, 11:51:24 PM
Merited by Welsh (8), Foxpup (3), gmaxwell (2), hugeblack (1)
 #17

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?

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.


Quote

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
It is pure trolling. I'm absolutely not surprised, you are a known shill  Wink
Otherwise, I'm bad  Cheesy  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.

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.

Vires in numeris
aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 726

always remember, remember the cause


View Profile WWW
November 01, 2019, 02:47:34 AM
Last edit: November 01, 2019, 05:16:09 AM by aliashraf
 #18

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 ecds and not to have funosystem and allows mobile wallets to be a true full node taking a real part in the consensus and you are worried about "sabotage"? Kidding?

anyone wanting to attack the network doesn't care about participating in it rationally
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!

Quote
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.
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.

Quote
i don't claim to be "here to save bitcoin"
Are you sure? but it is what shills do, they are guardians who try to save bitcoin from aliens  Cheesy

Quote
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.
Report me as a bad employee to the boss, they'll fire me  Cheesy
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2898
Merit: 2862



View Profile
November 01, 2019, 02:53:52 AM
 #19

The main problem with pruning is that you can't import a pre-funded address anymore.
Checkout "importprunedfunds".
SapphireSpire
Member
**
Offline Offline

Activity: 123
Merit: 20


View Profile
November 01, 2019, 04:53:19 PM
Last edit: November 01, 2019, 05:14:15 PM by SapphireSpire
Merited by Welsh (2), hugeblack (1)
 #20

I follow the usual rules; I go with the longest chain mined at the hardest difficulty.
The usual rules require you to follow the VALID chain with the largest difficulty sum.
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.

By creating a new genesis block, you completely destroy the ability for any node to determine the validity of the UTXO set.
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.

You FORCE the users to accept the chain with the largest difficulty sum instead of the VALID chain with the largest difficulty sum.
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!
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!