Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

Quote

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.

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?

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

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

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?

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

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

What happens if there is any kind of inconsistency in the chain? Would it still be vailid?

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.

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

Quote

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

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

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.

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

Quote

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.

So theoretically one could attack the chain and fork from the last checkpoint if one had enough hashpower to catch up with the network?

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

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

Does the network protect itself by updating the checkpoints?

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.

Quote from: CaptainHash on April 15, 2014, 03:55:07 AM

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.

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.