Bitcoin Forum
May 06, 2024, 06:34:33 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: Creating an "official" protocol specification for the Bitcoin internet currency  (Read 4635 times)
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1150


View Profile
April 09, 2013, 08:15:22 PM
 #61

What is the core problem that bitcoin solves?  The distributed consensus problem.

There have been chains of hashes and chains of digital signatures before. What makes bitcoin different is that it is timestamping these digital messages, and protecting those timestamps against being reversed.  The currency aspect of bitcoin is simply a layer on top of the distributed timestamping service.  namecoin is an example of a non-currency use of distributed timestamping.

Actually I think you are oversimplifying a bit... just timestamping isn't enough. If all Bitcoin did was timestamp SHA256 hashes of transactions, it'd be useless because there would be still no consensus about double spends. The actual data itself must be public.

Better is to describe Bitcoin as an data store with inherently difficult to change order. Now it happens to be that Bitcoin is implemented in such a way that it will never store conflicting data twice, but if it wasn't, it would still work just fine - the second transaction would be useless garbage and ignored. Similarly actually having the time attached to the data is only an artifact of the PoW implementation. Again, the order is what matters, not the time. If the difficulty was fixed at the current value, rather than adjusting every two weeks, Bitcoin would work just fine strictly speaking, though you would have to wait months to get a block.(1)

I'm being a bit pedantic... but it's an important distinction in the case of alt-chains that try to bootstrap off the Bitcoin PoW function. For instance you could try to define an alt-chain where ordering was determined by getting the block header hash timestamped into Bitcoin - I've proposed the idea before on the bitcoin-dev email list - but solving the actual consensus problem of being sure everyone knows about all transactions is very tricky with such "pseudo-mining"

1) You know, Bitcoin could have been usefully implemented via telegraph and semaphores back in the late 1800's had the block interval been set to, say, 1 month or so. A small team of human calculators could probably calculate a SHA256 hash for a transaction in a few hours, especially with purpose built mechanical aids, and back then they could have used a much weaker hash function and gotten away with it. Though they'd have eventually had a rousing debate about Sir. Charles Babbage's "mechanical work engines", not to mention allowing more than a few dozen transactions per month...

1714977273
Hero Member
*
Offline Offline

Posts: 1714977273

View Profile Personal Message (Offline)

Ignore
1714977273
Reply with quote  #2

1714977273
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714977273
Hero Member
*
Offline Offline

Posts: 1714977273

View Profile Personal Message (Offline)

Ignore
1714977273
Reply with quote  #2

1714977273
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
April 09, 2013, 10:03:10 PM
 #62

What is the core problem that bitcoin solves?  The distributed consensus problem.

Forks are caused by 2 or more client implementations disagreeing about whether a block is valid or not.

This is the part that needs to be exactly right to prevent forking.

Slight differences in the protocol implementation are not as fatal.

Quote
The currency aspect of bitcoin is simply a layer on top of the distributed timestamping service.  namecoin is an example of a non-currency use of distributed timestamping.

The timestamping requires header verification.

The spec could have 2 parts, net protocol and validation rules.

The validation rules are more critical to get exactly right.  A full node requires 100% support for the validation system and all clients need to be the same.

An alt client which implements the 95% of the network rules would probably be functional.  Maybe it wouldn't protect against spam quite so well etc.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1150


View Profile
April 10, 2013, 02:11:13 AM
 #63

An alt client which implements the 95% of the network rules would probably be functional.  Maybe it wouldn't protect against spam quite so well etc.

You're totally right, but we've known this for a long time; fundamentally my objections to large blocks on the basis that they can be used to flood miners on low bandwidth connections is an example of consensus failure due to network rules. It's just the "rules" in that case happen to be laws of physics rather than software.

My blockheaders over Twitter thing, while at one level an April Fools joke, is at another level not a joke at all. We do need alternate methods of block and transaction propagation on the network, and unlike validation having as much variety as possible is only a good thing. It's the fundamental security principle of Bitcoin: information is easy to spread and hard to stifle.

TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
April 10, 2013, 10:49:04 AM
 #64

You're totally right, but we've known this for a long time; fundamentally my objections to large blocks on the basis that they can be used to flood miners on low bandwidth connections is an example of consensus failure due to network rules. It's just the "rules" in that case happen to be laws of physics rather than software.

What are your views on having nodes validate only 1% of the block-chain?

The system needs basically a distributed hash table.  The hash becomes the key.  It could resolve to children on the merkle tree and transactions.

If you ask for a merkle root, it will resolve to the 2 child hashes.  You can then resolve one of those hashes to follow the chain downwards.

The big problem is how to handle missing (or intentionally withheld) data.

Quote
My blockheaders over Twitter thing, while at one level an April Fools joke, is at another level not a joke at all. We do need alternate methods of block and transaction propagation on the network, and unlike validation having as much variety as possible is only a good thing. It's the fundamental security principle of Bitcoin: information is easy to spread and hard to stifle.

Cool, and yeah that is exactly the point.  The network is just a means to an end.

The big benefit of the exactness of a spec is validation of a block chain.

Having said that, the network spec should be relatively easy to define exactly too.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!