Topic: Some odd blockchain questions (Read 956 times)

Correct - it should be perhaps termed the "best chain" at a particular height. This is generally termed as the chain "weight" which (in PoW in particular) is how you decide out of two "forks" which chain you are going to build upon (each node will build upon the one with the "greatest weight").

So if you are on chain A100 B110 C110 you would report to your peers that your blockchain is at height C with weight 320.

If a peer reports to you they are on a chain of height C with a weight > 320 then you would check that this new chain checks out and if it does you would now build upon that rather than the one you were going to previously.

Danny might be correct in the sense you care about.  However, you really can't arbitrarily modify blocks within the blockchain because every block contains the hash of the prior block.  This is why its called a "chain".  So if you modify one in the middle, the hash will no longer match up.  But this is code, so you *could* add an exception to your altcoin block validation tool, allowing this broken hash...

But it might be better to create a one-time "fork" block that would adjust balances in any manner you choose.  It is code after all...


I think that when people speak about "sending bitcoins from an address" the "from" address IS "the specific previously received outputs".  So you can't choose an arbitrary "from" address, but using the "coin control" feature in the 0.9.1 version of Bitcoin core you CAN pick which previously received outputs to use for a particular send.  Other wallets, like armory let you keep multiple separate "wallets" within the same program.  Coins from both wallets are never spent in the same transaction.


Also, although people say the "longest" chain, its really (AFAIK) the "most difficult" that is chosen.  For all normal cases these two concepts are the same but this is why an attacker can't hack the code to artificially reduce the difficulty to 1, create a chain longer than the rest of the network and have everyone switch over.

I think if someone transformed the concept of you last post in to animation/movie or ... ,that could be easy understood by "normal" people, be good for wider adoption ...

First you have to decide if you are trying to discuss this at a user level, or at a technical protocol level.

If you are trying to discuss technically what happens at the protocol level, it gets far more confusing than you might imagine.  First you have to come to the realization that there is nothing that can be called "a bitcoin", and the "bitcoins" (that don't exist) aren't "sent" anywhere.

Instead, a script from a previous transaction output is satisfied in a way that will result in a result of "TRUE" (typically this is accomplished by providing a proper digital signature), and value from that previous output is then considered to be available to be re-assigned.  Then, a new script is created encumbering some portion of the available value with a requirement in a new output.

The most common script is written in such a way as to require a signature from a private key.  The required signature is identified by a hash of it's public key.  This hash, when encoded with Base58check encoding, is what we call a bitcoin address. Therefore, to make the discussion about transfer of control of value at the user level easier to discuss, we call the process of creating and broadcasting such a transaction, "sending to a bitcoin address".

I'm confused. Are Bitcoins sent to an address or to the scripts?

Makes sense. So it is working. Nice!
I'm a crypto noob that has just started to understand the fundamentals and successfully forked a few cryptos for research and fun.
How would you estimate the effort for that kind of solution? It probably involves a lot of code adaptions, there doesn't seem to be a single function that takes care of the encryption and could easily be modified...

I'm trying to mix scrypt with keccak to lock out the new scrypt asics. Has this been done before?

Such a construction typically involves using the original algorithm for old blocks until a certain crossover checkpoint and using the new algo on all blocks afterwards. So the blockchain that you import will need to be verified by clients through the use of the original algorithm, but you can enforce that any blocks after block-height X require the new algorithm.

It's not possible to change the algorithm used to verify old blocks unless you redo the proof-of-work on all these old blocks with the new algorithm.

Thanks alot for helping me out again!

It's actually top secret, but the bitcoin network has been hacked, and this is Satoshi with dementia trying to fix it.
Just kidding. Nah, I was talking about an alt coin. But the attack was far in the past, hundreds of unwanted blocks have already been confirmed.
This is far beyond my capabilities, and I think I will leave the blockchain untouched.

Just one more question - is it possible to copy an existing blockchain into a new crypto currency that uses a different algo?
Couldn't find anyhing about that, but someone claimed it was possible. Wouldn't the block hashes be different with another algo?

I've just tried it and adjusted the hash of the genesis block and the message start string (is the latter one necessary?). Then I copied wallet and block data from an existing coin. But when I start it up I get an assertion error, because hash != hashGenesisBlock.

I'm a noob and just started poking around in the source code. I might just have missed something (like reading the docs)...

I've lost track at this point of whether we are talking about Bitcoin, or some altcoin.

Assuming we are talking about bitcoin, then the "repair" that you are suggesting is going to depend a lot on exactly what the attacker did, and how far back in the blockchain you need to change things.

If the "attack" is discovered before 100 blocks have occurred, the "repair" won't be quite as bad, since none of the outputs of any of the coinbase transactions will have been spent yet.  This means that nearly all the transactions in the blocks are valid.  The blockchain can be rolled back to the last "valid" block, and all the transactions can be confirmed again in the new blockchain.

Once you get beyond 100 blocks, it starts to get a lot messier.  At that point, the attacker could have spent the outputs that they received in the coinbase transactions.  The value from those spent outputs would then be cycled through more and more transactions as people spend what they receive.  If you roll the blockchain back past spent coinbase outputs, those outputs vanish and no longer exist.  That means that any transaction that includes any portion of the value from those coinbase transactions becomes invalid and ceases to exist.

If the attacker just used their hash power to reverse a few of their own recent transactions, I suspect that very little would be attempted to fix it.  The user's that are defrauded by the attacker would be scolded by the community and told that they should have waited for more confirmations.

Thanks for sharing your wisdom, mister guru. 


I'm trying to figure out a way for a compromised currency to be "repaired". What I want to do is to copy the blockchain into the new currency. Almost all of the last blocks of that chain were faked by an attack, so I want to revert the blockchain to a specific height. As far as I understand this is not a problem.
BUT this will also mean, that some transactions are lost and some funds remain in wallets of pools (unpaid rewards) and other services like exchanges. I think it's impossible to transfer them to the correct addresses, and that's why I want to delete these balances, because noone can guarantee that the owners of those "3rd party wallets" would be fair and redistribute the coins. it also would require them to adjust their databases, if they want to continue their service with the new coin. i doubt admins would be willing to do that.

It should be possible to be done, but how would you estimate the effort?
I can imagine the analysis of the data alone would take a lot of time.

And if I got you right, I would have to invalidate all the unwanted (unspent) inputs of an address to set the balance of an address to zero.
This has to be hardcoded (OMG) to make it work, and there is no easy way of just manipulating the block data / berkeley db?

So in case of several addresses with tens of thousands of unwanted inputs this would mean endless spaghetti code in the protocol.
Not only that it would look horrible, wouldn't it also be a performance issue, because every single future transaction would have to be checked against them?

You already said it wouldn't be working, but I thought it might be as simple as to make certain addresses inaccessible by changing the public key of those addresses and making the import of a private key impossible. But this would probably break the chain, right?

Is it worth poking around in that matter or would it just end up with headaches and wasting a lot of time, if you're all new to that crypto stuff?
I just cannot afford to spend weeks on that.

That depends on what you're trying to accomplish, why you're trying to accomplish it, and how you want it to work. 


You would need to create a protocol that would simply ignore particular transactionIDs or transaction outputs.


Not sure what you mean by inconsistency. My assumption is that you would be trying to invalidate some unspent outputs.  Your new protocol rules would simply be hard coded to not recognize them as valid inputs to any transactions.


We are back to talking about bitcoin, and not some new altcoin, right?

In that case, the Bitcoin Core client has the protocol rules.  The best way to understand the EXACT rules is to read the source code.

In general though the more significant rules that come to mind are:

• Each block must have a reference to a previous valid block all the way back to the genesis block.
• Each block must hash to a value that satisfies the difficulty at the time.
• Each block must have a merkle root that is generated from a list of valid transactions.
• Each block must not award a block reward that is larger than the sum of the proper block subsidy plus all the transaction fees of all included transactions.
• Each block must have a timestamp within certain constraints relative the the blocks prior to it.

Yes. As long as you could catch up before the next checkpoint is set.


I don't think that is the intended purpose of the checkpoints, but I think it is a side effect of their existence.  As I understand it, the intended purpose has more to do with streamlining the bootstrapping process for new nodes.


Every client sets a target difficulty for itself, but they all do it based on the same information and rules so they all end up with the same difficulty.  If you try to set a lower difficulty, then all peers will refuse to relay or accept your block.

Every 2016 blocks the client looks at the 2016 blocks that just finished.  If it took more than 20160 minutes to solve the blocks, then the difficulty is decreased proportionally to speed up block solving.  If it took less than 20160 minutes to solve the blocks, then the difficulty is increased proportionally to slow down block solving.  The only way to control the average time to solve a block is to adjust the difficulty, and the difficulty that you solve must be at least as difficult as the rest of the network, or they will simply ignore your blocks.  This is why it is called a "proof-of-work".  The hash that you provide "proves" to the rest of the network that you "worked" on the block as hard as they did.

Thanks alot for your detailed reply, Danny!
This helps me alot in understanding the fundamentals, and I even have some more stupid questions - sorry for that, just repond if they are not too crackbrained, I'm almost too tired to think everything through, now

Cool. But how to approach? I guess you cannot do anything with rpc-commands but have to use Berkeley for that.
How would you estimate the effort for editing a chain, and how hard would it be to change the binary data?
Is it enough to modify the public key in the database/binary data or wherever it's stored to erase an address and could it affect the balances of other addresses?
What happens if there is any kind of inconsistency in the chain? Would it still be vailid?

And those requirements would be? Is there some kind of technical doc?


So theoretically one could attack the chain and fork from the last checkpoint if one had enough hashpower to catch up with the network?
Does the network protect itself by updating the checkpoints?

And I think there was little misunderstanding. What I actually wanted to ask is if it's possible to modify the client's source code to find blocks more quickly by changing the average time to solve a block from 10 minutes to 10 microseconds or something like that - not modiying the timestamp. i guess not, diff would be too low, and it would probably already have destroyed btc a long time ago.

Sure. You'd need to import all the private keys from the original wallet (unless you were using a wallet that has deterministic keys, such as Electrum in which case you'd need to import the seed).


In your newly created altcoin? Sure.  There are a variety of ways you could maintain balances that you want, and remove balances you don't want.


The addresses all have individual keys.  The only way to restore entire balance would be to have all the private keys from the original wallet.


Bitcoins aren't sent "with and address"  They are sent "to an address".  You can choose what address you want to send them to.

(Actually, they are sent to scripts.  There is a particular commonly used script that encumbers spending with a signature from a private key of an address.  This commonly used script is called "sending to an address" as a common way to describe it)

When spending them, you spend the specific previously received outputs by satisfying the script (which in the case of bitcoins "sent to an address" means providing a valid digital signature).


As long as your chain satisfies the other requirements of the protocol?  Sure.


No.

Each block has a reference to the block before it.  You would have to choose which previous block you want to fork from.  Then you would have to create blocks faster than the the rest of the network is updating the current chain until your chain has more blocks than the current one.

The timestamp has no bearing on that.

Since the protocol says that your blocks have to meet a particular difficulty, your hash rate determines how many blocks you can solve in a given amount of time.


That depends on what the attacker is trying to accomplish and how careful they are about it.

I have a few questions about blockchain compatibility.

I think it should be possible to copy a whole blockchain into a new crypto currency, with all the keys and transactions, so that you can restore your transaction history and balances by importing your private key into the new wallet. Is that correct?

If yes, could one modify the blockchain to erase unwanted transactions and move balances into nirvana?

Another noob question: If a wallet has multiple addresses, is it possible to tell if they are belonging together or do they all have individual keys, or in other words - can you restore the actual wallet balances?

Is it possible to send coins using a secondary address, or will they always be sent with the main address?

Some more  off topic question about 51% attacks:
Afaik you can take over a chain if you have the longest one in the network (chains, i'm talking about chains!).
Would it be possible to speed up the calculation of the chain for such an attack by modifying the block time in the source code and then start calculating, so that you can override far into the past until the last checkpoint?

And finally - how do you trace such an attack AFTER it happened? Are there any traces that can be found in the blockchain?

Thanks for your replies