Gold collapsing. Bitcoin UP.

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
- Regarding the UTXO block and 'necessity of validating since the genesis block'. I have heard that argument from various people that this is the only way to stay trustless, but I disagree there on the trustlessness. Because there is (in theory, and this whole 'validating since genesis' idea is purely due to theoretical concerns!) no reason at all that I am not interacting with a made up world where a man-in-the middle handed me the wrong Genesis block. There is no trustlessness. Everyone is trusting the Genesis block. The difference with UTXO commitments and TXN data for a year would be that no-one invented another blockchain within that year and got all that piled-up hashpower as visible in the blockheaders. So they'd also need to do that in secret and then suddenly convince everyone around the planet that they are the good guys. So I think that scenario of running from UTXO-commitments plus partial history is like today's full node security minus an arbitrarily small epsilon (with the epsilon depending on your willingness to validate old history).
More than that even, almost no one who uses Bitcoin has - nor will ever have - the combination of expertise, time, and inclination to examine the code they are running to be 100% sure that it is properly validating everything anyway (not to mention their OS, hardware, etc.). Practically everyone relies on community vetting and time-tested solutions based on known incentives for blackhats to find bugs.

I think if even a month (probably even a day) of Bitcoin history were falsified without it being obvious to a user who is staying abreast of news through a wide variety of channels, things are probably already so screwed up with the world or their country that they would know they have a special emergency need to validate the chain fully on their own.
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
@awemany, absolutely I think it is important to keep technical discussion going. I just think timing and venue are important. Core benefits from not only inertia but also the impression of stability. I think our cause is not helped if people get the impression that we're out here throwing things against the wall until something sticks. If we can keep a steady hand on the rudder (which BU's governance processes are set up to do), we look like a reasonable alternative.

Bear in mind that /r/btc is not a technical forum (though we do get into the weeds sometimes. Perhaps we should have one?) and info-dumping "cool new ideas" from influential people may not be the best way to proceed.
[doublepost=1482337482][/doublepost]
Everyone is trusting the Genesis block.
I think the theory would be that the genesis block is easily verifiable (though I don't think anyone actually does that). Though it would be very clear quite quickly if one were not operating on the blockchain.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@awemany, absolutely I think it is important to keep technical discussion going. I just think timing and venue are important. Core benefits from not only inertia but also the impression of stability. I think our cause is not helped if people get the impression that we're out here throwing things against the wall until something sticks. If we can keep a steady hand on the rudder (which BU's governance processes are set up to do), we look like a reasonable alternative.
Absolutely. I wonder whether I should have been more careful in the discussion on reddit, and clearly marked it as brainstorming(?) Rereading it, I think you won't get the wrong impression, unless you are quote-mining as a Core minion.

I think the theory would be that the genesis block is easily verifiable (though I don't think anyone actually does that). Though it would be very clear quite quickly if one were not operating on the blockchain.
Yeah, but these are all theoretical concerns anyway, and this concern is swept under the rug by people who should know better. If you are a brain in a vat and someone feeds you what they say is 'Bitcoin with the genesis block', you have no chance to discern it from the 'real' Genesis block. Similarly if your internet connection is hijacked and everyone around you is an agent of the false-genesis-mafia :D

My point is simply that the theoretical concerns regarding running from year-long UTXO commitments are in a similar realm to 'I got the wrong genesis block due to a huge conspiracy targeting me'.

But due to this theoretical attack on given the wrong Genesis block, I simply assert that Bitcoin is not perfectly trustless.

Of course, it is good enough, by far. But it will also be so with just a year of transactions + UTXO commitments.

@Zangelbert Bingledack : Right. I just have this pet peeve with 'trustlessness' and people dismissing not validating everything since Genesis for that reason. Many people in Bitcoin are narrow black-and-white thinkers, and these 'theoretical security concerns' are used to woo them. And with the brain-in-a-vat scenario, you can show that trustlessness is strictly false if you get really, really philosophical/theoretical.
 
Last edited:

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
@zanglebert Yet another reason why competing implementations are so important and why a written spec would be a good idea.
[doublepost=1482339312][/doublepost]@awemany perhaps if you ran bitcoind in UTXO mode, it could ask you to verify a hash of the set which could (perhaps) be obtained from multiple public sources.

I think it would also be good to see a version which quick-starts in UTXO mode but downloads and verifies the complete blockchain in the background. This would allow the best of both worlds somewhat.
 
Last edited:

jbreher

Active Member
Dec 31, 2015
166
526
I think that scenario of running from UTXO-commitments plus partial history is like today's full node security minus an arbitrarily small epsilon (with the epsilon depending on your willingness to validate old history).
According to a discussion I had with GMax, Core does not validate from the genesis block, but rather from some much more recent checkpoint. He asserts that all the main variants (e.g., Classic, BU, ...) are the same in this regard.
[doublepost=1482343450,1482342439][/doublepost]
I think if even a month (probably even a day) of Bitcoin history were falsified without it being obvious to a user who is staying abreast of news through a wide variety of channels, things are probably already so screwed up with the world or their country that they would know they have a special emergency need to validate the chain fully on their own.
I'm a bit more circumspect. If more than several nodes do not have a complete history, how do we restart the system after a mass coronal ejection or other event that kills the internet?
[doublepost=1482344243][/doublepost]
I just have this pet peeve with 'trustlessness' and people dismissing not validating everything since Genesis for that reason. Many people in Bitcoin are narrow black-and-white thinkers, and these 'theoretical security concerns' are used to woo them.
Planned nefarious attack is not the only vector.
https://en.wikipedia.org/wiki/List_of_major_power_outages
If regional outages are this common....
https://en.wikipedia.org/wiki/Power_outage#Blackout_inevitability_and_electric_sustainability
...and the grid is so intertwined...
http://news.nationalgeographic.com/news/2011/03/110302-solar-flares-sun-storms-earth-danger-carrington-event-science/
...how do we restart the system after nature destroys the electrical grid, unless we have a complete record from genesis?
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
It is entirely too early to talk about committed UTXO sets.

Getting distracted by things we won't need for years instead of strictly focusing on what's needed today is a good way to lose everything.
I disagree. Look at what Core is doing with LN. They are selling some super-duper future happy utopia, but it is essentially vaporware/a religion, with Core (no pun) questions unsolved. And they are having (moderate) success.

In comparison, committed UTXO sets are very workable (though admittedly also vaporware, with some technical questions to be determined). I think it is good to discuss them and point them out to easen the worries on on-chain scalability.

I would even go as far as saying that having an implementation of UTXO commitments, even if it is trusted, and even if it is partial (no miner agreement to enforce it) would still help get alternative clients to Core off the ground.

However, I also think we should do first things first.
 

satoshis_sockpuppet

Active Member
Feb 22, 2016
776
3,312
According to a discussion I had with GMax, Core does not validate from the genesis block, but rather from some much more recent checkpoint. He asserts that all the main variants (e.g., Classic, BU, ...) are the same in this regard.
Hm, maybe I'm confusing something but I remember them talking about removing these checkpoints. Don't know if they did or still plan to do it or not.

syncing a node is a bitch.
if BU had a "use committed UTXO set" mode, its node count would double overnight, and all new nodes from that point on would be BU nodes.
I agree. Having the option for fast syncing, pruned nodes would be a massive plus imho.
Secondly, I think (IIRC @theZerg discussed this on reddit) implementing an option for SPV<->node fees model would be the next important thing to give people another reason to run an Unlimited node.

And in the end the only thing, that really counts, is hashpower. If node count* really meant anything, we could spare us these expensive miners..

(*I'm still not sure, how decentralized the core node count really is today..)

Lately I browsed ebay for used servers.. 128 GB RAM and 24 CPU cores for 500 $.. There's a lot of room for Bitcoin to grow. 16 MB blocks today and I guess the BTC/$ price would allow a lot of bitcoin users to run such a node from their spare money.. (And maybe we would see more small miners too...)
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
I'm a bit more circumspect. If more than several nodes do not have a complete history, how do we restart the system after a mass coronal ejection or other event that kills the internet?
It seems this only requires that there be quite a few nodes, not that everyone run a node before the event. Because after a major Internet shutdown people will know at that time to obtain full node software and re-validate from genesis, for the obvious reasons. Am I missing something?
 
  • Like
Reactions: Norway and awemany

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
I'm a bit more circumspect. If more than several nodes do not have a complete history, how do we restart the system after a mass coronal ejection or other event that kills the internet?
...how do we restart the system after nature destroys the electrical grid, unless we have a complete record from genesis?
we dont need a complete record, simply knowing who had what is enough!

if we all agree that the UTXO set representing "the state" after block #1023993 hashes out to "hs2dafo832h3214j12jk4hjk2490faksmf9023nFuckYa"
then we can throw away the history, because we all know that "hs2 ... nFuckYa" correctly encapsulates all the previous history. ( each node can verify this independently )

I'd go all in on this idea and have nodes keep only 10days of full history and every 1440 blocks a new UTXO's hash is added to a block. and MOFO CLEAR THE HISTORY! ( do it like this, minners include the hash, full nodes compute the UTXO themselves, and check if the miner got it right, if not reject his block! )

this has the added bonus of extra privacy!

this is probably a soft fork, old nodes would just keep recording every single block like nothing ever happend, only it would find it odd no other node is asking for this data anymore.

sorry i used all caps, and bolded stuff, and typos, these things get me all excited sometimes.:whistle:
 
Last edited:

sickpig

Active Member
Aug 28, 2015
926
2,541
For what is worth Alex B (aka brg444 on reddit and btctalk) has been officially hired by BlockStream.

"For that, and many other reasons, I am absolutely grateful to announce that, starting today, I have been contracted by Blockstream to help communicate the essence of some of the technologies they are developing and hopefully generate interest around their potential and enable more people to build on them in the spirit of permissionless innovation."

source: https://medium.com/@bergealex4/in-bitcoin-wonderland-dfe9de03ed11

/cc @cypherdoc
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
I agree first things first. But there's no harm having early discussions about these things. Especially so we don't get blindsided (Imagine if Core had been able to serve up Segwit with no chance for review). Also, this would potentially allow for a big improvement in the user experience and thus adoption. There are also several other items in this category that I think are worthy of discussion.

I think Adam's model is inevitable in the very long run. The network will be able to handle the bandwidth required but (some/many) people will be less willing to accept the long startup times and the storage costs. This is what leads to decreasing node count and less decentralization and the solution is not to strangle the network but to look for other solutions. There will be plenty enough people willing to store the complete blockchain for research and informational purposes and it will always be possible to validate from the genesis block. Just as there is a use case for 0 conf, there is also a case for accepting the security of validating from a checkpoint.

The other primary change I would like to see would be running bitcoind as a service on windows and having the wallet be a separate piece of software. This would allow for the blockchain to be kept up to date without having to start the bitcoin client every time. If I recall, the RPC interface is not currently suitable for this. Bringing this up to date, if done properly, would allow multiple wallets to use the same bitcoind. Something that is long overdue and which several companies have implemented their own versions of. The bonus side effect would be a proliferation of much better wallet alternatives (though that may have its own drawbacks)
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
I agree first things first. But there's no harm having early discussions about these things. Especially so we don't get blindsided (Imagine if Core had been able to serve up Segwit with no chance for review). Also, this would potentially allow for a big improvement in the user experience and thus adoption. There are also several other items in this category that I think are worthy of discussion.

I think Adam's model is inevitable in the very long run. The network will be able to handle the bandwidth required but (some/many) people will be less willing to accept the long startup times and the storage costs. This is what leads to decreasing node count and less decentralization and the solution is not to strangle the network but to look for other solutions. There will be plenty enough people willing to store the complete blockchain for research and informational purposes and it will always be possible to validate from the genesis block. Just as there is a use case for 0 conf, there is also a case for accepting the security of validating from a checkpoint.

The other primary change I would like to see would be running bitcoind as a service on windows and having the wallet be a separate piece of software. This would allow for the blockchain to be kept up to date without having to start the bitcoin client every time. If I recall, the RPC interface is not currently suitable for this. Bringing this up to date, if done properly, would allow multiple wallets to use the same bitcoind. Something that is long overdue and which several companies have implemented their own versions of. The bonus side effect would be a proliferation of much better wallet alternatives (though that may have its own drawbacks)
maybe next year BU could tackle this thing. *fingers crossed*

at least its nice to know there's probably a workable solution to the " OMG the bitcoin DB is growing exponentially :eek:" problem. which is a big problem... its not just download and CPU when syncing, i'm currently syncing and the thing holding me back is the extreme disk usage! part of building the blockchain is creating index files and such, all of these disk operations are done with some kind of "safe_write()" avoiding all this would be fun...

I'm sure it would be challenging to get a working implementation that does this kind of thing and does it well. but well worth the effort i'm sure.

but if BU does starts working on this, it should probably do so in phases.
phases 1 being, simply having a Beta version of BU which has a UTXO checkpoint hardcored in the build. see how that goes expand on it, etc etc. untill its ready to have miners onboard and softfork this UTXO checkpoint every 1440blocks "thingy" into the protocol.
 

albin

Active Member
Nov 8, 2015
931
4,008
I'm becoming more and more convinced that there is a VC proxy war going on here over the Bitcoin blocksize, at least from the one side of it. There are way too many milquetoast people out there on twitter with totally mundane jobs in Bitcoin companies and organizations linked to the usual suspect small-block VC's who cheerlead segwit activating for no apparent reason. Like almost none of these companies will ever have any hope of making any money, so there must be some utility to the VC's as far as pay-for-play to be in the space.