Bitcoin Forum
June 21, 2018, 08:48:37 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: 1 2 [All]
  Print  
Author Topic: Blockchain weaknesses, how does bitcoin solve/protect against it ?  (Read 4102 times)
Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 22, 2011, 01:52:28 PM
 #1

Hello,

I have some questions about potential weaknesses in the blockchain idea and how bitcoin potentially solves it ?

First question:

1. Suppose the attackers manage to outrun the defenders with a blockchain of +1 for the attackers.

Are the attackers capable of replacing the entire blockchain with bullshit transactions ?

If not how does bitcoin protect against replacing/invalidating the entire blockchain ? (Perhaps it uses some kind of timestamp/datestamping to prevent this from happening ? For example after X days the transactions/blockchain cannot be replaced ?)

2. How does bitcoin protect against the "no work to do" situation ? For example: there are no transactions being broadcasted, miners have no work to do. But an attacker could make a bullshit transaction and start working on the next block, while the miners have nothing to do... (More or less related to question 1 as well).

Bye,
  Skybuck.

1529614117
Hero Member
*
Offline Offline

Posts: 1529614117

View Profile Personal Message (Offline)

Ignore
1529614117
Reply with quote  #2

1529614117
Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1529614117
Hero Member
*
Offline Offline

Posts: 1529614117

View Profile Personal Message (Offline)

Ignore
1529614117
Reply with quote  #2

1529614117
Report to moderator
1529614117
Hero Member
*
Offline Offline

Posts: 1529614117

View Profile Personal Message (Offline)

Ignore
1529614117
Reply with quote  #2

1529614117
Report to moderator
1529614117
Hero Member
*
Offline Offline

Posts: 1529614117

View Profile Personal Message (Offline)

Ignore
1529614117
Reply with quote  #2

1529614117
Report to moderator
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 22, 2011, 02:10:05 PM
 #2

Note: I am using alternate terminology, better suited to explain bitcoin to new people, as discussed here. I'm trying to get this terminology used more, not implying you are new. The old terms are bracketed.

1. A ledger (blockchain) is a book with pages (chain of blocks). Every time 1 page (block) is written (added), it doesn't change all the previous pages in the ledger (blocks in the blockchain).
This basically means that to get your scenario of "replacing the entire blockchain with bullshit transactions" they would need to do all the calculations the recorders (miners) did since the start of bitcoin, doing a calculation for every page of this completely new book. This is practically impossible.

2. The recorders (miners) can record "empty" pages (blocks) without any transactions. This is no problem.

Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 22, 2011, 02:21:44 PM
 #3

I found some partially answers to parts of my questions on this wikipedia link:

https://en.bitcoin.it/wiki/Weaknesses

Which I will quote here:

"
Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.

"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most CPU usage will win.
"

My thoughts on it:

The hardcoded block hash, assuming it is just a hash, offers some protection, but not absolute protection, a block hash collision might still be found by an attacker, which could still allow him to change the history of the blockchain.

This is pretty much the same thing as "bitcoin mining" where a hash needs to be find with zeros in it, except this time, the entire hash must match.

So it can probably be considered "maximum difficulty" for the attacker.

Which is a good question: Is there such a thing as "maximum difficulty" ?

If not, how is maximum difficulty extended to infinity ?

If no, then bitcoin might fail in the future when maximum difficulty is easily processed.

(Let's call this: "Super computer in your pocket which does maximum difficulty attack in 1 second Wink" Smiley)

The block chain length is kinda interesting, this requires the attacker to examine the real blockchain, and make sure his fake blockhain is longer...
Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 22, 2011, 02:29:12 PM
 #4

Note: I am using alternate terminology, better suited to explain bitcoin to new people, as discussed here. I'm trying to get this terminology used more, not implying you are new. The old terms are bracketed.

1. A ledger (blockchain) is a book with pages (chain of blocks). Every time 1 page (block) is written (added), it doesn't change all the previous pages in the ledger (blocks in the blockchain).
This basically means that to get your scenario of "replacing the entire blockchain with bullshit transactions" they would need to do all the calculations the recorders (miners) did since the start of bitcoin, doing a calculation for every page of this completely new book. This is practically impossible.

2. The recorders (miners) can record "empty" pages (blocks) without any transactions. This is no problem.

Ok, I get what you are saying.

This would require bitcoin to first examine the entire blockchain to make sure that all hashes are indeed valid and correct, and that all work was done.

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.

Impossible is a dangerous statement to make, but I will accept it for now, but the impossibility will surely go down as computers become much more powerfull.

All processing power in the world today, might be in somebody's pocket in 10 years or so... perhaps the difficult will have risen or perhaps not, see my question about maximum difficulty.

So bottom line:

1. Large parts of processing power might be ignored because of merkle tree hash pruning.

2. Large parts of processing power might be easily reproducible because of super computers in the future.

3. Leaving only recent work done, which leads to the question of "maximum difficulty".

If maximum difficulty is achieved in 1 second times, then perhaps switching to a different hashing technique might be possible to increase it... so this probably answers my own question about difficulty.

However getting the whole world to switch to a new standard is difficult as ipv4 to ipv6 has proven to be Wink


Considering your point 2: miners can do empty transactions, is this actually done in practice to work when there is nothing real to work on ?
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 22, 2011, 02:49:38 PM
 #5

Ah, I didn't understand you were talking about cutting away part of the blockchain.

So: Hash collisions. If hashes are 160 bits long, every new hash you generate has a 1 in 2^160 chance of being the same. If an attacker could generate new hashes at, say, 1 Ghash/sec (4 high end videocards) times, say, a million people (it's a well-connected attacker, I'm being generous here Smiley), then it would take them on average 460 000 000 000 000 000 000 000 centuries to find the same hash. Or, in one century, they would have a chance of 0.0000000000000000000002% chance of finding it in one century.

But let's say the processing power doubles every year. Then after ten years the chance would be 0.00000000000000000004% (That's 2 zeroes less than that century chance up there).

In 100 years we would have a problem, if processing power doubles every year. In 100 years things will be rather different anyway. Let them figure that out Smiley

I'm not too familiar with the exact idea for cutting away the blockchain, but this seems possible, for at least the coming tens of years.

Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 22, 2011, 03:19:07 PM
 #6

Ah, I didn't understand you were talking about cutting away part of the blockchain.

So: Hash collisions. If hashes are 160 bits long, every new hash you generate has a 1 in 2^160 chance of being the same. If an attacker could generate new hashes at, say, 1 Ghash/sec (4 high end videocards) times, say, a million people (it's a well-connected attacker, I'm being generous here Smiley), then it would take them on average 460 000 000 000 000 000 000 000 centuries to find the same hash. Or, in one century, they would have a chance of 0.0000000000000000000002% chance of finding it in one century.

But let's say the processing power doubles every year. Then after ten years the chance would be 0.00000000000000000004% (That's 2 zeroes less than that century chance up there).

In 100 years we would have a problem, if processing power doubles every year. In 100 years things will be rather different anyway. Let them figure that out Smiley

I'm not too familiar with the exact idea for cutting away the blockchain, but this seems possible, for at least the coming tens of years.

Originally I was indeed considering replacing the entire blockchain... however if only a hash is stored then that's pretty much the equivalent... so I am just exploring both options.

Anyway hashes are broken all the time, and I think sha-1 was already broken, then there are also rainbow table attacks, birthday attacks, and so forth... I am not expert in that... but I know attack methods exist.

Did you include algorithm attacks in your chances calculations ? I don't think so... so sha-2 might be broken much more quickly... and hash collisions could become pretty real.. ?! Wink
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 22, 2011, 03:56:24 PM
 #7

Algorithm attacks is weaknesses in the algorithm? I did not take those into account, no. Using two different hash algorithms reduces this chance greatly (ripemd-160 and sha160 for example. This is already done for bitcoin addresses, as far as I know).

birthday attacks is pertaining to the birthday paradox? That will account for an increased chance equal to the number of hashes you are considering as a 'success'. Won't be a lot.

SHA-1 is not really broken, but rather weaker than originally thought. A collision can theoretically be found in about 2^51 processing steps. This is still a pretty significant number.

Rainbow tables can't be used, since we need to make an actual blockchain. Rainbow tables are only generated for short strings. Generating them for a blockchain-type message would take longer than just doing the attack.

So to sum it up, it may be true that at some point this could pose a problem. However, I don't expect this to be in at least 5 years, more likely 20.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1004


Gerald Davis


View Profile
November 22, 2011, 04:23:36 PM
 #8

Anyway hashes are broken all the time, and I think sha-1 was already broken, then there are also rainbow table attacks, birthday attacks, and so forth... I am not expert in that... but I know attack methods exist.

rainbow tables = only work because one can search a tiny % of possible hashes due to fact that most passwords have only small amount of entropy
birthday attacks = only work when the chance is small relative to the number of trials (checking 1 day vs only 31 possible chances and 20 kids in the class)

SHA-1 isn't already broken.  Flaws have been found which reduce its strength.  Its strength currently is still more than adequate but it is a good idea to move to more secure algorithms in case deeper attacks are found in the future.  This highlights how attacks which completely break an algorithm tend to not just appear out of nowhere.  The first attack on SHA-1 was published in 2005, 8 years later it still requires 2^51 operations to find a collision in SHA-1 (vs 2^80 by brute force).  So while SHA-1 is 8 million times weaker it is still computationally intensive to find collision.  Far too computationally intensive to be of any practical value. 

Still companies are urged to move away from SHA-1 to stronger algorithms.  SHA-1 may be broken eventually but it likely will be decades after the first flaws were published.  Bitcoin is capable of changing algorithms if a flaw was found in SHA-256 there would be litterally years (maybe decades) to plan for a migration.

Quote
Did you include algorithm attacks in your chances calculations ? I don't think so... so sha-2 might be broken much more quickly... and hash collisions could become pretty real.. ?! Wink

I don't think you realize how large 2^256 is.  Hey it is only 256 it doesn't sound that much bigger than 32 bit or 64 bit right?

Lets assume:
Someday Bitcoin has 10 billion users and they on average have 1 million active addresses or 1 quadrillion known addresses/hashes. 

Lets also assume that computers are so powerful they could instantly find collision in a 56bit hash (DES) in 1 second.  For the record today it takes roughly 24 hours to find a collision in DES using special built hashing array so that would be on the order of  100,000x increase in computing power.

Lets also assume you used 1 billion computing nodes nonstop 24/7 to look for collisions.  The have a 0.01% chance of finding a collision would on average take  5,095,567,111.43 quadrillion years.   

Now lets say an attack similar to the one found on SHA-1 reduced the number of rounds from 2^80 to 2^51 in that case it would "only" take you 607 quadrillion years .... to have a 0.01% chance of finding a collision against a random existing hash.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1003


Democracy is vulnerable to a 51% attack.


View Profile WWW
November 22, 2011, 05:15:15 PM
 #9

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.
If the pruned away part of the blockchain is replaced with just a hash, replacing that part of the blockchain will go from difficult to impossible. The client could not possibly accept a different view of those blocks because it would have no way to undo their transactions and replace them with transactions in different blocks. A client can only reorganize the block chain for blocks it has. Any pruning of the block chain would only be possible for blocks that had been permanently locked in.

Pruning a block means forever accepting the version of that block you pruned. Without the old contents of that block, there's no way you can replace them with new contents.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 23, 2011, 12:49:50 PM
 #10

However this does present a problem for the future: the idea was to "cut away the blockchain" and replace it with a hash only, this is the concept of the merkle tree.

Perhaps this is not yet done to make sure the blockchain is long, but after a certain while this long blockchain might become impractical and will have to be "pruned/cut away" leaving just a hash.

At that point it will become easier since there is no more blockchain to check it has been pruned away, leaving only the remaining blockchain to be checked.
If the pruned away part of the blockchain is replaced with just a hash, replacing that part of the blockchain will go from difficult to impossible. The client could not possibly accept a different view of those blocks because it would have no way to undo their transactions and replace them with transactions in different blocks. A client can only reorganize the block chain for blocks it has. Any pruning of the block chain would only be possible for blocks that had been permanently locked in.

Pruning a block means forever accepting the version of that block you pruned. Without the old contents of that block, there's no way you can replace them with new contents.

Let's see if I understand correctly, and then examine a possible way of totally replacing the blockchain.

Conceptually speaking, all bit coins in existence form a chain of coins. These coins can be moved around from person to person, account to account, can be transerred, sold, bought etc.

Everytime coins are exchanged the chain starts to grow with new coins.

A possible problem with this concept is the chain grows too large.

So the idea is to cut away the tail of the chain to make it shorter again.

The idea behind cutting away the tail is to replace the tail with a single hash. (Merkle Tree Partially collapsed ? or perhaps something else, simply a single hash unrelated to merkle, or perhaps a new merkle hash root node, since something has to be the previous hash for the last block in the tail ?).

Anyway the question is now:

What happens about all the transaction data ?

You seem to imply as well, that this transaction data would have to been thrown away as well, since that would otherwise also grow to large, and since the blocks have been thrown away it makes no sense to store the transactions.

So the bottom line is:

1. Blocks are thrown away.
2. Transactions are thrown away.
3. What remains is a single hash.

My claim/idea was that an attacker could create "fake" transactions which represent the transactions which were thrown away in step 2.

You claim that doing so would be useless, because the entire network/system has apperently agreed to cut away the tail.

So everybody using bitcoin throws away the tail, the blocks, the transactions that went with it, and everybody agrees that that data is now no longer in play.

So you say making those fake transactions won't be usefull because they would be rejected by the system Huh

You seem to say that these transactions cannot be re-injected into the system ?!?

But then my question is:

How does the remaining part of the system, the section beyond the tail, the section that was not cut off know who owns what ?

All those transactions which were done before the tail was cut off, result into some kind of wealth, some kind of account money ?!?

I assume that when a bitcoin application starts up, it starts to scan all transactions for it's own addresses, sums them together and thus figures out what it's balance is ?!?

If those transactions have been thrown away, and/or the blocks are not available for verification purposes ?!?!? Then how would the client know what it's balance is ?!?!?

Is this perhaps why bitcoin could be considered a pyramid scheme ?!?!? Once the cut happens wealth disappears ?!?!?

BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 23, 2011, 01:00:05 PM
 #11

When you spend coins, you tell the network: I take the coins from this transaction and that transaction as inputs, and send them to this address and that address as outputs. You never actually store any coins, you just know which transactions went to your address, and which of those have been "spent", i.e., sent to a different address.

If the blockchain is collapsed or whatever, only the transactions that have been spent would be removed. That way you could still scan the blockchain, and find out how much money you have, by adding all transactions that have not yet been spent.

If there was an attacker claiming "Look! I have this trail of (fake) transactions, and they add up to this hash!" then they would still need to add up to the transactions to your address which you haven't spent yet. This means the attacker doesn't actually achieve anything with his 'attack'. That is beside the point that finding a hash collision really is impossible for the coming few decades.

Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 23, 2011, 01:02:02 PM
 #12

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 23, 2011, 01:13:05 PM
 #13

When you spend coins, you tell the network: I take the coins from this transaction and that transaction as inputs, and send them to this address and that address as outputs. You never actually store any coins, you just know which transactions went to your address, and which of those have been "spent", i.e., sent to a different address.

If the blockchain is collapsed or whatever, only the transactions that have been spent would be removed. That way you could still scan the blockchain, and find out how much money you have, by adding all transactions that have not yet been spent.

If there was an attacker claiming "Look! I have this trail of (fake) transactions, and they add up to this hash!" then they would still need to add up to the transactions to your address which you haven't spent yet. This means the attacker doesn't actually achieve anything with his 'attack'. That is beside the point that finding a hash collision really is impossible for the coming few decades.

What matters is what is stored. The transactions as far as I know are stored on disk ? The transactions are the archive which could be used to makes sense out of things.

You seem to imply that there is a difference between "spending" and "receiving" ? Does this mean there is a difference between "spent" and "receive" transactions ?

What does this mean for a potential collapse/cut of of the trail ? Does this mean all "receive transactions" are kept and the "spent transactions" can be thrown away ?

If so then suddenly you would become rich because it would seem you didn't spent anything ? So that doesn't make sense.

Another conclusion could be possible as well:

If the fake blockchain does not add up to your account balance, then your account balance is fraud !

In another words if suddenly the fake blockchain would be acceptable by a majority for some strange reasons, for example some people got rich and don't mind getting rich, and some people lost a lot, then oops.

If you would be the person suddenly losing a lot, and you complained the guys who got rich would say well ofcourse he's complaining, he's poor and a fraud !
Skybuck
Full Member
***
Offline Offline

Activity: 204
Merit: 100


View Profile
November 23, 2011, 01:25:11 PM
 #14

Perhaps I miss-understand the roll of the hashes and the merkle hash tree.

This article seems to explain it a bit more:

http://sakabatou.dyndns.org/b2evolution/index.php/2011/09/04/how-does-bitcoin-work-technical

Apperently the merkle hash tree is used to allow, multiple chains to exist.

Once the longer chain is discovered after 100 blocks it becomes the main chain.

The other leaves/trees are collapse and re-fed into the system/chain/merkle hash to be tried and reincluded into the system.

So perhaps the blockchain itself is never pruned ?!? The tail is never cut off !?

The blockchain must always keep existing ?!?

This then raises the question:

What if the blockchain becomes to large for average computers to store ?!?!?!?

Does this mean that if bitcoin grows faster then harddisk space that bitcoin will more or less be doomed ?! Wink At least for average people ?!?

Hmmm...

Maybe some compression can help for a while...

I shall have to re-examine how it all works and what's possible for attack vectors Wink Smiley
BTCurious
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
November 23, 2011, 01:30:58 PM
 #15

You seem to imply that there is a difference between "spending" and "receiving" ? Does this mean there is a difference between "spent" and "receive" transactions ?
A transaction is basically a bit of info roughly structured like this:

Code:
Transaction ID: 1234321
Inputs:
    Transaction ID: 1234300
        Output number: 3
    Transaction ID: 1234301
        Output number: 1
Outputs:
    1:
        Address: 1myaddressarstarstarstarst
        Amount: 10 BTC
    2:
        Address: 1someaddressarstarstarstar
        Amount: 30 BTC
Now if I own 1myaddressarstarstarstarst, then I can make a transaction like this:

Code:
Transaction ID: 1234322
Inputs:
    Transaction ID: 1234321
        Output number: 1
Outputs:
    1:
        Address: 1youraddressarstarstarstar
        Amount: 10 BTC

If I have broadcasted that transaction, and it's verified and accepted, then Transaction 1234321's output 1 will no longer be used. Thus you could forget about it.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1004


Gerald Davis


View Profile
November 23, 2011, 01:36:46 PM
 #16

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash.  Finding that hash would require attempting quadrillions of hashes (just like when block was originally signed).  This is what we are doing when we "mine" for coins.

Simplistic outline of mining:
1) Take all transactions that will be in the block.
2) Make a coinbase transaction which awards the block reward + any transaction fees to the miner's address
2) Create merkle tree of all transactions in the block
3) Take the version, merkle root, time, prior block hash, target, and nonce (value from 0 to 2^32 -1).  This forms the block header.
4) double hash the block header.  check if hash is smaller than the target.  if so then submit to network.
4a) if double hash is not msaller than target discard, increment nonce and goto step 4
4b) if nonce is max nonce then modify coinbase (creating different merkle tree), reset nonce to 0 and goto step 4

So for a malware to rewrite existing blocks would require not just 51% of hashing power but 51% of hashing power PLUS more hashing power to retroactively rewrite older blocks.   
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1004


Gerald Davis


View Profile
November 23, 2011, 01:46:05 PM
 #17

As far as blockchain pruning no client currently does this but you can prune any block where ALL the coins have changed after the block to be pruned.

For example say in block 105 there is only a single transaction the coinbase.
50 BTC -> address 123

later in the block chain (say block 210) you have this transaction
address 123 tx 50 BTC to address 999

If block 210 has been accepted by the network (and now is considered canonical by both age and being behind checkpoints) there is no need for block 210 anymore.

The client could mark block 105 as pruned (leaving only the hash to allow validation of block 106), delete the data from block 105 and mark the input of address 123 in block 210 as from a pruned block.

This was a simplistic example.  If a block involves multiple transactions then all coins from all transactions must be involved in a subsequent block in order for the block to be pruned.  This means addresses with "lost coins" can never be pruned.

Still there is sufficient number of "dead end" transactions that IIRC there was a simulation showing block chain pruning could reduce size of blockchain by about 70%.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1003


Democracy is vulnerable to a 51% attack.


View Profile WWW
November 23, 2011, 06:17:06 PM
 #18

Let's see if I understand correctly, and then examine a possible way of totally replacing the blockchain.

Conceptually speaking, all bit coins in existence form a chain of coins. These coins can be moved around from person to person, account to account, can be transerred, sold, bought etc.

Everytime coins are exchanged the chain starts to grow with new coins.

A possible problem with this concept is the chain grows too large.

So the idea is to cut away the tail of the chain to make it shorter again.

The idea behind cutting away the tail is to replace the tail with a single hash. (Merkle Tree Partially collapsed ? or perhaps something else, simply a single hash unrelated to merkle, or perhaps a new merkle hash root node, since something has to be the previous hash for the last block in the tail ?).
That's correct. You remove the entire chain and all you keep is the hash and a table of all Bitcoins that are still spendable. You throw everything else away.

Quote
Anyway the question is now:

What happens about all the transaction data ?
All you need is the transaction IDs and output offsets of any outputs that are still spendable. You can throw everything else away.

Quote
You seem to imply as well, that this transaction data would have to been thrown away as well, since that would otherwise also grow to large, and since the blocks have been thrown away it makes no sense to store the transactions.
Well, you have to keep track of all coins that are spendable. Other transactions can be thrown away.

Quote
So the bottom line is:

1. Blocks are thrown away.
2. Transactions are thrown away.
3. What remains is a single hash.
In principle, all that remains is a single hash. But that hash is sufficient to reconstruct the one and only state of all current transactions.

Quote
My claim/idea was that an attacker could create "fake" transactions which represent the transactions which were thrown away in step 2.
How could he? One of two things would have to be the case for the transactions to be accepted:

1) They'd have to claim spendable transaction outputs that this node still knows. In which case, in what sense are the transactions "fake"?

2) They'd have to claim spendable transaction outputs that could be proven valid based on the hash the node still knows. In this case, the attacker either needs to find a hash collision (in which case, everything is screwed) or the transaction must claim valid outputs.

Quote
You claim that doing so would be useless, because the entire network/system has apperently agreed to cut away the tail.

So everybody using bitcoin throws away the tail, the blocks, the transactions that went with it, and everybody agrees that that data is now no longer in play.

So you say making those fake transactions won't be usefull because they would be rejected by the system Huh

You seem to say that these transactions cannot be re-injected into the system ?!?
They cannot be injected because they do not claim transaction outputs that any node would consider valid by any method.

Quote
But then my question is:

How does the remaining part of the system, the section beyond the tail, the section that was not cut off know who owns what ?
They either keep track of all spendable transaction outputs or they require verifiable proof that there exists a spendable transaction output that they don't know of -- validating by hashes and signatures traceable back to data they know is valid.

Quote
All those transactions which were done before the tail was cut off, result into some kind of wealth, some kind of account money ?!?
They're still valid. Their outputs are still spendable.

Quote
I assume that when a bitcoin application starts up, it starts to scan all transactions for it's own addresses, sums them together and thus figures out what it's balance is ?!?

If those transactions have been thrown away, and/or the blocks are not available for verification purposes ?!?!? Then how would the client know what it's balance is ?!?!?
The client would store its balance, along with the identities of any transaction outputs it could spend.

Quote
Is this perhaps why bitcoin could be considered a pyramid scheme ?!?!? Once the cut happens wealth disappears ?!?!?
Nothing disappears. The cut is just to save memory and disk space. The semantics remain precisely the same. The difference is that everyone can forget about transactions with no spendable outputs and they can forget about blocks prior to a checkpoint.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1003


Democracy is vulnerable to a 51% attack.


View Profile WWW
November 23, 2011, 06:19:29 PM
 #19

So perhaps the blockchain itself is never pruned ?!? The tail is never cut off !?
Currently, the chain is not so big that anyone has implemented any pruning. Pruning is a bit tricky to do correctly.

Quote
This then raises the question:

What if the blockchain becomes to large for average computers to store ?!?!?!?
Then clients can start using pruning. But disk space is growing much faster than the hash chain, so this may never be an issue.

Quote
Does this mean that if bitcoin grows faster then harddisk space that bitcoin will more or less be doomed ?! Wink At least for average people ?!?
Probably people will cut over to clients that don't keep the entire block chain but instead keep only their own transactions.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Terikan
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
November 17, 2013, 05:48:16 PM
 #20

Addition to my previous posting: By the way this means there is another potentially way/attack to bitcoin:

A trojan/virus/malware/worm could start to alter the data which is on everybodies drive and starts to create it's own fake chain as an attempt to chain the thruth.

If the trojan/virus/malware/worm manages to infect enough system for example the 51% then history could be altered ?!?

Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash.  Finding that hash would require attempting quadrillions of hashes (just like when block was originally signed).  This is what we are doing when we "mine" for coins.

Simplistic outline of mining:
1) Take all transactions that will be in the block.
2) Make a coinbase transaction which awards the block reward + any transaction fees to the miner's address
2) Create merkle tree of all transactions in the block
3) Take the version, merkle root, time, prior block hash, target, and nonce (value from 0 to 2^32 -1).  This forms the block header.
4) double hash the block header.  check if hash is smaller than the target.  if so then submit to network.
4a) if double hash is not msaller than target discard, increment nonce and goto step 4
4b) if nonce is max nonce then modify coinbase (creating different merkle tree), reset nonce to 0 and goto step 4

So for a malware to rewrite existing blocks would require not just 51% of hashing power but 51% of hashing power PLUS more hashing power to retroactively rewrite older blocks.   


Firstly, sorry for necro'ing.  I'm going to write an article about bitcoins as they have become interesting to people in the investing world.  However, as more of a computer guy than most traders, I came here out of concerns about the integrity of the transaction system used by bitcoin.  In particular, this quote above leaves me with more questions than answers, so I thought maybe I could ask for some more info.

"Still can't get around the proof or work requirement.

If an attacker modifies a block that block now needs to be "signed" w/ a hash."

Simple question, why?  You've got these blockchains duplicated in computers all over the place, and no one who's checking for valid transactions (like retailers I mean) will know whether it's been signed with a hash, so if every blockchain gets modified in the same way by some sort of virus that utilizes some sort of software vulnerability and thereby was able to spread to every node in the network, how would an end user know what's valid or not? 

Is there some entity or centralized verifier somewhere that holds the key or algorithm to knowing when a transaction entry/hash is valid/invalid?  If the problem was simpler, conflicts between chains that could not be resolved, or massive deletions of transactions from the chain, is there a reference point somewhere that says "ok I'm the big guy in charge, copy from me to restore order". Break it down for me. 

Thanks.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2184
Merit: 1357



View Profile
November 17, 2013, 10:19:15 PM
 #21

If an attacker modifies a block that block now needs to be "signed" w/ a hash."

Simple question, why? 

Is there some entity or centralized verifier somewhere that holds the key or algorithm to knowing when a transaction entry/hash is valid/invalid?  If the problem was simpler, conflicts between chains that could not be resolved, or massive deletions of transactions from the chain, is there a reference point somewhere that says "ok I'm the big guy in charge, copy from me to restore order". Break it down for me.

Every transaction and every block is verified by every full node on the entire peer-to-peer network.

If a transaction isn't valid, then none of the nodes will relay it and miners won't try to add it to the blocks they are mining.
If a block isn't valid, then none of the nodes will add it to their blockchain or relay it.

By adding a proof-of-work to this system, the entire network is able to reach a consensus on the ordering of transactions and blocks without a centralized entity to verify or timestamp anything.

Terikan
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
November 18, 2013, 02:47:35 AM
 #22

If an attacker modifies a block that block now needs to be "signed" w/ a hash."

Simple question, why? 

Is there some entity or centralized verifier somewhere that holds the key or algorithm to knowing when a transaction entry/hash is valid/invalid?  If the problem was simpler, conflicts between chains that could not be resolved, or massive deletions of transactions from the chain, is there a reference point somewhere that says "ok I'm the big guy in charge, copy from me to restore order". Break it down for me.

Every transaction and every block is verified by every full node on the entire peer-to-peer network.

If a transaction isn't valid, then none of the nodes will relay it and miners won't try to add it to the blocks they are mining.
If a block isn't valid, then none of the nodes will add it to their blockchain or relay it.

By adding a proof-of-work to this system, the entire network is able to reach a consensus on the ordering of transactions and blocks without a centralized entity to verify or timestamp anything.

I've read this vague answer a few times, so it just isn't entirely clear how that would prevent anything.   I've read the proof of work page on the wiki, it doesn't shed any light on it.  You have this network of nodes that store a file or filesystem of data called the block chain, if I've gotten anything wrong so far, then I must really need a dummy explanation. 

When people accept a bitcoin as a form of payment, where does their validation query go to ensure the address has that fund, and then where do they send the transfer info so that it then gets added to the block chain?  No central server or main node?  Then where? 

Whatever the answer is, how does anyone know if something has been altered on the block chain via node-side malware?  With every transaction is it checked against others copies?  If so how many?  How does it decide what to verify it against.  Which copies take precedence when two block chains are different?

Hopefully I actually sound really stupid and someone can point out where I can read a better understanding of how it all works.  It doesn't have to get that technical, if it's secure it can be made understandable on a conceptual level.   Let me come back to one thing:

"Every transaction and every block is verified by every full node on the entire peer-to-peer network."

My understanding was that every miner has a full copy.  My question is how every transaction and block is verified, if the ones doing the verifying are the ones under attack by theoretical malware (or possibly transaction spoofing where an exploit in the software is found), then how can you trust their verification?  A compromised computer could tell you that 3+4=17 if so ordered to.  And if there are compromised nodes with altered data (but not randomly altered, all compromised blocks match and confirm each other), then how is such a scenario resolved? 

And when a significant % of nodes get compromised, and payment processors are trying to do business during such a situation, which nodes are going to be providing them with verification of funds etc?
DannyHamilton
Legendary
*
Offline Offline

Activity: 2184
Merit: 1357



View Profile
November 18, 2013, 03:36:52 AM
 #23

I've read this vague answer a few times, so it just isn't entirely clear how that would prevent anything.   I've read the proof of work page on the wiki, it doesn't shed any light on it.  You have this network of nodes that store a file or filesystem of data called the block chain, if I've gotten anything wrong so far, then I must really need a dummy explanation. 

So far, so good.  Nothing there that I can see that's wrong yet.

When people accept a bitcoin as a form of payment, where does their validation query go to ensure the address has that fund, and then where do they send the transfer info so that it then gets added to the block chain?

When a person sends bitcoin as a form of payment, the transaction is sent to each peer that they are connected to. Each of those peers validates the transaction before relaying it to each peer that they are connected to.  Each of those peers validates the transaction before relaying it to each peer that they are connected to, and so on, and so on until almost every node on the network is aware of the transaction.

Each node verifies that the appropriate signatures have been provided and compares the transaction to the history of transactions that they already know about to make sure that the funds being spent are previously unspent.  If the receiver is running a full node (such as Bitcoin-Qt, then their software does the same when it hears about the transaction from any of the peers that it is connected to.

No central server or main node?

No.

Then where? 

Their own knowledge of the entire history of bitcoin transactions.

Whatever the answer is, how does anyone know if something has been altered on the block chain via node-side malware?

You would have to alter the blockchain on every node on the entire network. Otherwise, it would become quickly obvious that your copy of the blockchain didn't match your peers. All you'd have to do then is regenerate your blockchain and any invalid transactions would become immediately identifiable since the hash wouldn't match.

With every transaction is it checked against others copies?

Yes.

If so how many?

All of them.

How does it decide what to verify it against.

It verifies it against the UTXO set that it is aware of.

Which copies take precedence when two block chains are different?

Each node compares against it's own copy.

Hopefully I actually sound really stupid and someone can point out where I can read a better understanding of how it all works.

Have you read the "Satoshi Whitepaper" yet?  Do you at least understand the concepts of a hash and a digital signature?

My understanding was that every miner has a full copy.  My question is how every transaction and block is verified, if the ones doing the verifying are the ones under attack by theoretical malware (or possibly transaction spoofing where an exploit in the software is found), then how can you trust their verification?

Every miner has a full copy.  Every full node also has a full copy.

If malware was created that could simultaneously alter every copy of the blockchain in existence in exactly the same way, I suppose it would be possible to destroy some information from the blockchain.  However, there are people who keep copies of the blockchain offline.  There are copies on multiple operating systems, both on and offline all over the world.  It would be exceedingly difficult to damage them all in an identical way simultaneously.

A compromised computer could tell you that 3+4=17 if so ordered to.  And if there are compromised nodes with altered data (but not randomly altered, all compromised blocks match and confirm each other), then how is such a scenario resolved?

In order to create blocks that "match and confirm each other", the attacker would have to generate an appropriate proof-of-work.  Since each block includes the hash of the block before, it would be necessary to complete more proof-of-work than the entire honest network.  This is often known as a 51% attack (since it requires the attacker to have more than 50% of the entire netowrk's hashing power to reliably accomplish it for an extended period of time).  In this case, the blocks broadcast by the attacker are considered valid (as long as they only include valid transactions that spend unspent transaction outputs and have appropriate signatures).

And when a significant % of nodes get compromised, and payment processors are trying to do business during such a situation, which nodes are going to be providing them with verification of funds etc?

I don't understand the question.

Terikan
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
November 18, 2013, 04:56:26 AM
 #24


Sadly I don't really have any answers yet.  Just more of "it verifies against other copies".  Not that I don't appreciate, and maybe I'm just too dense for this.  But let me give it another try.

"When a person sends bitcoin as a form of payment, the transaction is sent to each peer that they are connected to. Each of those peers validates the transaction before relaying it to each peer that they are connected to.  Each of those peers validates the transaction before relaying it to each peer that they are connected to, and so on, and so on until almost every node on the network is aware of the transaction."

How many peers are we talking about?  If one peer reports the transaction is invalid, but 4 say it's valid, what then?  Is it majority decision, or does it have to be 100%?

"Each node verifies that the appropriate signatures have been provided and compares the transaction to the history of transactions that they already know about to make sure that the funds being spent are previously unspent.  If the receiver is running a full node (such as Bitcoin-Qt, then their software does the same when it hears about the transaction from any of the peers that it is connected to."

Is the signature something different from the public key, private key, address?

"You would have to alter the blockchain on every node on the entire network. Otherwise, it would become quickly obvious that your copy of the blockchain didn't match your peers. All you'd have to do then is regenerate your blockchain and any invalid transactions would become immediately identifiable since the hash wouldn't match."

This is important.  Yes, it's given that your copy would not match peers.  But not just yours, many others, all not matching each other.  I'm assuming that if malware had compromised a node or miner, that it would not longer be capable of detecting bad hashes.  It would tell you that yours is fine.  Uncompromised nodes wouldn't agree, but what then?  Retailers might still be connected to compromised nodes that could tell them whatever the malware wanted right?  

Or even worse, if the node software on the payment gateway were compromised, it might not even really reach out to other nodes, and just approve all fake transactions.  It might not directly compromise the blockchain for the overall system, but that gateway would be hosed financially.

Now about the hash.  Why can't that be faked by malware?  And further, is there private info (like private key for example) that is sent to the payment gateway that's used to generate a hash, but then isn't actually stored in the block?  If so, is that private key sent to all the nodes like the transaction to verify that the hash is correct, or can it verify that without needing the key? this might be too tedius to answer, I'll understand.

You said no central server.  I had read that bitcoin can change the way the blockchain is stored.  How would that be possible without some central server to refer to for instruction?  I seriously google every way I can "where do bitcoins come from" and read everything and I still don't get a clear answer, I assume because most media that write about it also don't understand what they are writing.  I don't get how new ones are generated, or if that involves some central resource or verification.  

"Each node compares against it's own copy."

I don't know what UTXO is.  Each node compares against it's own copy, and then what?  Does it trust it's own copy more than what other nodes tell it in case of a conflict or what?  I feel like I'm going to keep getting the same answer about hashes and verification and this ability to use these things to know whether or not a transaction is valid... when I don't understand how such a thing is possible... Maybe not impossible, but how it's infallible is what confuses me.  At one point in time, CC takers could use math to tell whether or not a credit card number was a POSSIBLE real one.  But the only way to know that it was a real one that belonged to Teri A Kan was to check a database that spelled that out for them.  I find any verification less than this hard to grasp.

I have not read the whitepaper.  

"If malware was created that could simultaneously alter every copy of the blockchain in existence in exactly the same way, I suppose it would be possible to destroy some information from the blockchain.  However, there are people who keep copies of the blockchain offline.  There are copies on multiple operating systems, both on and offline all over the world.  It would be exceedingly difficult to damage them all in an identical way simultaneously."

True, and you can't blame the system if a payment gateway infected with malware results in massive fraud, as the same can happen with banks and credit cards... with one huge exception that since bitcoin fraud victims have absolutely no recourse (assuming the gateway has protected itself through geographic locations or user agreements or both).  But once again this ability to just take the one true copy of the blockchain to fix all the incorrect ones via verification that is infallible seems to be at the heart of my confusion.

"In order to create blocks that "match and confirm each other", the attacker would have to generate an appropriate proof-of-work.  Since each block includes the hash of the block before, it would be necessary to complete more proof-of-work than the entire honest network.  This is often known as a 51% attack (since it requires the attacker to have more than 50% of the entire netowrk's hashing power to reliably accomplish it for an extended period of time).  In this case, the blocks broadcast by the attacker are considered valid (as long as they only include valid transactions that spend unspent transaction outputs and have appropriate signatures)."

This is way above me.  Uncompromised nodes would know what's wrong, but how would people know what's compromised and what's not if they don't know which nodes are compromised by hidden attacks?  And also, what if just one node another node is connected to reports back that 99999999999999 other nodes agree with it (it lies), so that it outweighs the report back from all the nodes it's connected to that are actually checking with the rest of the network?

"And when a significant % of nodes get compromised, and payment processors are trying to do business during such a situation, which nodes are going to be providing them with verification of funds etc?

I don't understand the question."

See if I can clarify.  The payment gateway communicates with several other nodes to verify right?  If X number come back saying one thing and X come back saying something else, how does that gateway know which to believe?

Thanks.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1004


Gerald Davis


View Profile
November 18, 2013, 05:08:33 AM
 #25

Start with this.
http://www.youtube.com/watch?v=Lx9zgZCMqXE

If you really want to understand Bitcoin at a technical level you MUST read the whitepaper.  Also a minimum level of knowledge is required.  You should know how digital signature work, what is a private key, what  a public key is and how they are used together.  You will also need to understand how hashing algorithms work and why the output is considered a random oracle.  You should understand what SHA-256, RIPEMD-160, and ECDSA are (inputs, outputs, how they are used, what they are used for). Most people will never understand Bitcoin at a technical level but trying to "know it" without basic introductory knowledge is like trying to walk into an operating room say "show me surgery" when you lack basic anatomy.

One thing you keep going making a mistake about is nodes don't have to ask other nodes if a tx (transaction) is valid.  All nodes immediately can INDEPENDENTLY verify if a tx (or block) is valid or not.  When a node relays a tx to its peers, those nodes verify the tx, not for the senders sake but because nodes in the Bitcoin network work on a no-trust basis.  They NEVER use information from other nodes until they INDEPENDENTLY verify it first.

The use of the blockchain (the UXTO is simply a subset of the blockchain which contains unspent outputs of txs), and the properties of ECDSA allows all nodes to verify if a new tx is valid without needing any input of another node.
JoelKatz
Legendary
*
Offline Offline

Activity: 1582
Merit: 1003


Democracy is vulnerable to a 51% attack.


View Profile WWW
November 18, 2013, 05:38:30 AM
 #26

How many peers are we talking about?  If one peer reports the transaction is invalid, but 4 say it's valid, what then?  Is it majority decision, or does it have to be 100%?
If the transaction is valid, a peer that reported it invalid would only be lying to itself. It can't convince anyone else it's invalid.

Quote
This is important.  Yes, it's given that your copy would not match peers.  But not just yours, many others, all not matching each other.  I'm assuming that if malware had compromised a node or miner, that it would not longer be capable of detecting bad hashes.  It would tell you that yours is fine.  Uncompromised nodes wouldn't agree, but what then?  Retailers might still be connected to compromised nodes that could tell them whatever the malware wanted right?
No. Each node independently verifies everything, period. If your software is compromised, you are screwed, of course. But if someone else lies to you, you can always detect it. All the verification is mathematical -- it is based on what is said, not who says it.

Quote
Or even worse, if the node software on the payment gateway were compromised, it might not even really reach out to other nodes, and just approve all fake transactions.  It might not directly compromise the blockchain for the overall system, but that gateway would be hosed financially.
Of course. If any computer is compromised, its own operations will be screwed up for the person who operates it. But that has nothing to do with Bitcoin or the blockchain. You must make sure your own software isn't compromised, that's true of any software that does anything.

Quote
Now about the hash.  Why can't that be faked by malware?
What would make it "fake"? If it follows the mathematical rules, it is not fake. If it doesn't follow the mathematical rules, then nobody will be fooled. It really is that simple.

Quote
And further, is there private info (like private key for example) that is sent to the payment gateway that's used to generate a hash, but then isn't actually stored in the block?
What do you mean by "payment gateway"? Bitcoin transactions are public because everyone verifies them.

Quote
If so, is that private key sent to all the nodes like the transaction to verify that the hash is correct, or can it verify that without needing the key? this might be too tedius to answer, I'll understand.
The private key is not sent anywhere. It's just used the generate the signature that is included in the transaction. This signature makes the transaction comply with the mathematical rules for a validtransaction.

Quote
You said no central server.  I had read that bitcoin can change the way the blockchain is stored.  How would that be possible without some central server to refer to for instruction?
Each server stores the blockchain, thus each server can store the blockchain however it wants.

Quote
I don't know what UTXO is.  Each node compares against it's own copy, and then what?  Does it trust it's own copy more than what other nodes tell it in case of a conflict or what?
If the node itself is broken, then it can't do anything reliable. If the node is not broken, then its copy can be 100% trusted by it because it 100% checked that it complied with the mathematical rules.

Quote
I feel like I'm going to keep getting the same answer about hashes and verification and this ability to use these things to know whether or not a transaction is valid... when I don't understand how such a thing is possible... Maybe not impossible, but how it's infallible is what confuses me.  At one point in time, CC takers could use math to tell whether or not a credit card number was a POSSIBLE real one.  But the only way to know that it was a real one that belonged to Teri A Kan was to check a database that spelled that out for them.  I find any verification less than this hard to grasp.
It sounds like you don't understand enough of the basics of public key encryption for an explanation to be possible. Let me give you an imperfect analogy.

Suppose you pick two very large prime numbers and multiply them together. Call the result X. The result will be a number whose factors only you know. Now, I can tell someone "give the $50,000 to anyone who knows the two numbers that multiply to X". You can now prove perfectly that you are the recipient of the $50,000 by revealing the two numbers that multiply to X. This identification is infallible (except that you must reveal the two numbers to complete it. But that's easy to fix with small adjustments).

Quote
But once again this ability to just take the one true copy of the blockchain to fix all the incorrect ones via verification that is infallible seems to be at the heart of my confusion.
Imagine you had some rule that could compare any two blockchains and tell you which one was "greater". And say we had a rule -- the "greatest" blockchain is the valid one. Wouldn't that do it? (And, in fact, Bitcoin has such a rule. The chain that follows all the required mathematical rules that would be expected to take the greatest amount of work to generate is the valid one.)

Quote
This is way above me.  Uncompromised nodes would know what's wrong, but how would people know what's compromised and what's not if they don't know which nodes are compromised by hidden attacks?
What does "compromised" mean here? If the results follow the mathematical rules, what makes them compromised? If they don't follow the mathematical rules, what would stop people from seeing that they're compromised?

You still miss the basic concept -- a block chain is valid if, and only if, it follows certain mathematical rules. The correct blockchain, of all the valid ones, is the one with the most proof of work. All of this is easily testable by every node.

Quote
And also, what if just one node another node is connected to reports back that 99999999999999 other nodes agree with it (it lies), so that it outweighs the report back from all the nodes it's connected to that are actually checking with the rest of the network?
Each node's verification is independent. It's not based on agreement but 100% independent verification.

Quote
See if I can clarify.  The payment gateway communicates with several other nodes to verify right?  If X number come back saying one thing and X come back saying something else, how does that gateway know which to believe?
Any that violate the rules are ignored. Of those that follow the rules, the one with the greatest proof of work is believed. That covers every case except the case where every node is lying.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
DannyHamilton
Legendary
*
Offline Offline

Activity: 2184
Merit: 1357



View Profile
November 18, 2013, 05:56:33 AM
 #27

"When a person sends bitcoin as a form of payment, the transaction is sent to each peer that they are connected to. Each of those peers validates the transaction before relaying it to each peer that they are connected to.  Each of those peers validates the transaction before relaying it to each peer that they are connected to, and so on, and so on until almost every node on the network is aware of the transaction."

How many peers are we talking about?

All of them.

If one peer reports the transaction is invalid, but 4 say it's valid, what then?

Then the 4 will relay it to their peers, and the 1 won't.

Is it majority decision, or does it have to be 100%?

Every node decides for itself if it will relay or not.

"Each node verifies that the appropriate signatures have been provided and compares the transaction to the history of transactions that they already know about to make sure that the funds being spent are previously unspent.  If the receiver is running a full node (such as Bitcoin-Qt, then their software does the same when it hears about the transaction from any of the peers that it is connected to."

Is the signature something different from the public key, private key, address?

Yes.  It is something different from the public key, private key, and address. And if you don't understand what a signature is or how it works, then you aren't going to understand bitcoin.  You might as well be saying, "I have no idea how an internal combustion engine works, and I don't really want to bother learning about it.  Can someone just tell me why putting gasoline into the tank of my car makes it so the wheels can turn when I press the accelerator?"

"You would have to alter the blockchain on every node on the entire network. Otherwise, it would become quickly obvious that your copy of the blockchain didn't match your peers. All you'd have to do then is regenerate your blockchain and any invalid transactions would become immediately identifiable since the hash wouldn't match."

This is important.  Yes, it's given that your copy would not match peers.  But not just yours, many others, all not matching each other.  I'm assuming that if malware had compromised a node or miner, that it would not longer be capable of detecting bad hashes.  It would tell you that yours is fine.  Uncompromised nodes wouldn't agree, but what then?  Retailers might still be connected to compromised nodes that could tell them whatever the malware wanted right?

Assuming the retailer is running an uncompromised node, they will be able to distinguish between the valid and invalid hashes.

Or even worse, if the node software on the payment gateway were compromised, it might not even really reach out to other nodes, and just approve all fake transactions. It might not directly compromise the blockchain for the overall system, but that gateway would be hosed financially

Payment gateway? I'm not sure what you're talking about.  You do realize that bitcoin is decentralized, right?

Now about the hash.  Why can't that be faked by malware?

Because any node that isn't compromised will be able to tell that it is an invalid hash.

And further, is there private info (like private key for example) that is sent to the payment gateway that's used to generate a hash, but then isn't actually stored in the block?

There's that phrase "payment gateway" again.  I'm not sure what you're asking about.  A hash is a hash.  It's a mathematical formula.  I'm not sure what you're trying to ask.

If so, is that private key sent to all the nodes like the transaction to verify that the hash is correct, or can it verify that without needing the key? this might be too tedius to answer, I'll understand.

A hash is a mathematical formula applied to a set of data.  Since the hash is a standard well known formula, any node can verify the result of the hash.

You said no central server.  I had read that bitcoin can change the way the blockchain is stored.  How would that be possible without some central server to refer to for instruction?

The instructions necessary to follow the protocol are stored in the client software that every node runs.

I seriously google every way I can "where do bitcoins come from" and read everything and I still don't get a clear answer, I assume because most media that write about it also don't understand what they are writing.  I don't get how new ones are generated, or if that involves some central resource or verification.

When a miner creates a new block, they assign some value to themselves.  The protocol allows this, and all nodes are aware of the protocol, so they all allow it.  There is no central source, but every node on the network verifies that the correct value is created with each block.

"Each node compares against it's own copy."

I don't know what UTXO is.

And this is why you don't understand the overall system.  You are skipping the basics.  That isn't going to work.  If you haven't read the "Satoshi Whitepaper" yet, then please go read it before you ask any more questions.

Each node compares against it's own copy, and then what?  Does it trust it's own copy more than what other nodes tell it in case of a conflict or what?

Yes.  Bitcoin is entirely trustless.  No node trusts anything it is told by any peer.  Every node verifies everything against its own knowledge of the transaction and block history.

I feel like I'm going to keep getting the same answer about hashes and verification and this ability to use these things to know whether or not a transaction is valid... when I don't understand how such a thing is possible... Maybe not impossible, but how it's infallible is what confuses me.  At one point in time, CC takers could use math to tell whether or not a credit card number was a POSSIBLE real one.  But the only way to know that it was a real one that belonged to Teri A Kan was to check a database that spelled that out for them.  I find any verification less than this hard to grasp.

The "belongs to" part is handled by the digital signature.  Only the person who has access to the private key can generate a valid signature.  This is the nature of digital signatures.  The "what are they spending" part is handled by keeping track of every single transaction that has ever occurred, and knowing what the list of Unspent Transaction Outputs (UTxO) is. The ONLY thing that can be spent is an unspent transaction output with a valid signature.

I have not read the whitepaper.

Please don't ask anymore questions until you do.

"If malware was created that could simultaneously alter every copy of the blockchain in existence in exactly the same way, I suppose it would be possible to destroy some information from the blockchain.  However, there are people who keep copies of the blockchain offline.  There are copies on multiple operating systems, both on and offline all over the world.  It would be exceedingly difficult to damage them all in an identical way simultaneously."

True, and you can't blame the system if a payment gateway infected with malware results in massive fraud, as the same can happen with banks and credit cards...

There's that phrase again (payment gateway).  What exactly is a payment gateway in bitcoin?

"In order to create blocks that "match and confirm each other", the attacker would have to generate an appropriate proof-of-work.  Since each block includes the hash of the block before, it would be necessary to complete more proof-of-work than the entire honest network.  This is often known as a 51% attack (since it requires the attacker to have more than 50% of the entire netowrk's hashing power to reliably accomplish it for an extended period of time).  In this case, the blocks broadcast by the attacker are considered valid (as long as they only include valid transactions that spend unspent transaction outputs and have appropriate signatures)."

This is way above me.  Uncompromised nodes would know what's wrong, but how would people know what's compromised and what's not if they don't know which nodes are compromised by hidden attacks?

Because they can verify the signatures and hashes themselves.

And also, what if just one node another node is connected to reports back that 99999999999999 other nodes agree with it (it lies), so that it outweighs the report back from all the nodes it's connected to that are actually checking with the rest of the network?

No node is trusted.  Nodes aren't asked how many nodes agree with them.  Every node verifies everything it receives from any other node.

The payment gateway communicates with several other nodes to verify right?

No.  There is no payment gateway.  Each node has a complete copy of the blockchain. The node verifies for itself.

If X number come back saying one thing and X come back saying something else, how does that gateway know which to believe?

There is no believing.  The nodes verify for themselves.

Terikan
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
November 18, 2013, 07:26:47 AM
 #28

Thanks for the replies, this helps me a lot.  It's clear I don't understand enough, but I disagree about whether or not I should be asking questions.  Until a whitepaper was mentioned here, I had no idea such a thing existed.  Had I not asked, I still wouldn't.

"You might as well be saying, "I have no idea how an internal combustion engine works, and I don't really want to bother learning about it.  Can someone just tell me why putting gasoline into the tank of my car makes it so the wheels can turn when I press the accelerator?""

Eh, you could tell them how a combustion engine works (to my brain it's simpler than bitcoin).   Anyone interested in bitcoin expansion is going to deal with people far less knowledgeable than I, and people in general aren't going to take a programming class to understand how their currency works.  Inconvenient, I realize.  A quicker, easier method of explaining to the uninitiated why their money is safer than their Playstation Network personal information is likely going to be vital at some point.  Right now, seemingly impossible.

I thank you guys again, lots of good responses to questions coming from a less knowledgeable base.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2184
Merit: 1357



View Profile
November 18, 2013, 07:46:16 AM
 #29

Thanks for the replies, this helps me a lot.  It's clear I don't understand enough, but I disagree about whether or not I should be asking questions.

The problem isn't the asking of questions.  The problem is the making assumptions about how you think it works, and then asking how it can be secure based on those assumptions.  You are a elementary school student asking about how calculus works.  You need to get the basics first, then buil your understanding on a solid foundation.

Until a whitepaper was mentioned here, I had no idea such a thing existed.  Had I not asked, I still wouldn't.

So have you read it yet now?

"You might as well be saying, "I have no idea how an internal combustion engine works, and I don't really want to bother learning about it.  Can someone just tell me why putting gasoline into the tank of my car makes it so the wheels can turn when I press the accelerator?""

Eh, you could tell them how a combustion engine works (to my brain it's simpler than bitcoin).

Sure, but to anyone that has never been exposed to the concepts of Ideal Gas Law, pressure, combustion, torque, reduction gears, etc. Any explanation is just going to sound like magic.  And if the person is trying to tie their understanding to the concept of a horse drawn vehicle, they are simply goin to become more confused.

 Anyone interested in bitcoin expansion is going to deal with people far less knowledgeable than I, and people in general aren't going to take a programming class to understand how their currency works.  Inconvenient, I realize.  A quicker, easier method of explaining to the uninitiated why their money is safer than their Playstation Network personal information is likely going to be vital at some point.  Right now, seemingly impossible.

Those same people don't seem to have any problem using a computer without understanding binary mathematics or the physics of a semiconductor.  They use the internet without any understanding of the TCP/IP protocol.  Why will the bitcoin protocol be any different?

Pages: 1 2 [All]
  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!