Topic: Cryptocurrency with Finite "Mini-Blockchain" (Read 5729 times)

pfft, it was reasonably solved a long time ago: https://bitcointalksearch.org/topic/with-balance-sheets-most-of-the-block-chain-can-be-forgotten-505

I also independently came up with the solution in 2011: https://bitcointalksearch.org/topic/announce-encoin-an-alternative-with-a-completely-different-paradigm-44682

That's a good idea actually, but I was talking about if the receiver comes online after the block of interest has been pruned from the mini-blockchain. They will be able to verify the money went to them because of the address database (which I now prefer to call the account database), but if they come online too late they wont be able to identify the sender or get the message. They could as you mentioned just get the block again from the sender if the sender saved it and sender node was still online. Or they could ask around in the hope another node was still holding onto the block they were after. But they would really only need to bother with this to retrieve detailed information about the transaction, it's always possible to confirm received funds without needing the block in which the transaction happened.

it was reasonably solved

Enough bragging just publish solution already and we can get to work.

Sender can store copies of blocks in which he made transactions. Validity of blocks can always be proved with chain of block headers(these are stored indefinitely) and sender can still prove that he had send funds to some address with certain message even after rest of network forgot about it.

But my latest solution is perfect. As far as I can tell it provides that almost "absolute" level of security bitcoin has.

No that's not enough to make it sufficiently secure. That's why I kept thinking about this problem, and now I finally do have a solution. It was really so obvious all along. I' about 99% confident this idea will work, but then again I'm no mathematician or cryptographer.

But you still have a point. I was thinking about this earlier today actually. But one must remember the message will only remain visible whilst it is in the mini-blockchain. After that it wont be possible to see the message or even where the funds came from.

I think the whole point of finite blockchain is that NO node in network is required to hold full copy of blockchain. If you still need full nodes i don't see how it is better than bitcoin.

Try to not overthink this. I believe including hash of state of all known accounts and its balances in block headers is sufficient to keep level of security similar to bitcoin.

one simple feature which would bring users to it: attaching custom message to a payment. Bitcoin cannot do this because it would bloat blockchain to unmanageable size, but it shouldn't be a problem when you can forget transactions and just keep balance sheet.

Make a checkbox in the client to enable full or pruned blockchain download.  Pruned blockchain can just download the block from a bunch of full nodes in the event of a dispute.  The danger of a sybil attack exists, but I don't think it's great.

I'm not sure I even follow this logic, though.  If the ledger contains every address and every amount of coins at every address, whenever a block is received you can just adjust the ledger accordingly.
For instance,
block n: send 50 coins to address 1 from address 2
block n+m: send 50 coins to address 1 from address 3

Client sees both tx at different times, adds 50 coins each time to adjust the ledger, hashes the ledger and checks it against the one in the next block found.  Address 1 contains 100 coins, while both address 2 and address 3 contain 50 less coins.  That the amount is duplicated is of no consequence as long as the quantities are adjusted per block.  If you want to include stake, you just input the block height and make separate amounts for each input.  Or, you can simply ignore this and just download the block from one of the full blockchain clients from which the stake is claimed to arise.  All the block hashes are easily able to be stored by anyone, so verification of any single block in the blockchain history is very simple.

You can just sign a message from the address you send it from...

You can just sign a message from the address you send it from...

I think PoS makes transaction pruning impossible. How would you suppose to check if miner of block N in the past really held claimed amount of stake at time of block signing if you forgot how account balances looked at that time?

I think block height is sufficient for account ledger.

Actually minimum ledger entry is
(Address, amount, version)

Version is needed because coins are indistinguishable and without version a transaction to send first half of balance to some address would look exactly same as transaction to send other half of coins to this address. Simply receiver of first transaction could rebroadcast same, already signed transaction, in subsequent block and receive rest of coins. Version needs to be increased after every withdraw from address in order to defend from this kind of fraud. I think version can simply be block number in which last withdrawal was included.

Try to not overthink this. I believe including hash of state of all known accounts and its balances in block headers is sufficient to keep level of security similar to bitcoin.

Anyway new coin with finite blockhain would be a winner, because we could include one simple feature which would bring users to it: attaching custom message to a payment. Bitcoin cannot do this because it would bloat blockchain to unmanageable size, but it shouldn't be a problem when you can forget transactions and just keep balance sheet.

You can use a consensus network via stake to do ledger verification, too.

Yes, it would be a good idea to include the block height and also the depth in the block in which the last tx appears.

Don't forget (from_acct_num, amt, to_acct_num) for a total of 15 or so bytes + signature.

Ideally the client should keep a ledger of addresses and amounts at the address to prevent double spending.

I had been thinking about similar idea independently and this is what I came up with:

Blockchain has two different functions.

1 ) Maintaining a distributed database
2 ) A way to know which view of this database is correct/most up to date

These two functions are independent. Distributed database can be almost anything you like as long as you define some basic rules for applying modification to it.

1) works this way:
There is some initial database state (genesis block). Every subsequent block contains some operations that modifies this state (in bitcoin these are transactions).

2) works as follows:
Block headers contains proof of work which is used to check which database view should be considered correct. Rule is simple: you find peer which have longest block header chain (in terms of proof of work) and you know what the correct database should look like (best block header contains hash of correct database). Then you download current database from peers and check whether it is correct.

Bitcoin uses somewhat peculiar database format: list of all transaction that happened from genesis block (block chain still needs to be stored at some nodes for the sake of history, but not all). I don't see any reason why database format can't be changed to something else. For example list of public keys with corresponding balances as you propose.

Here is my idea:

Database is just a list of accounts.
Every account consists of three things:
(public key, balance, block number of last spend operation)

Every block includes some number of transactions.
Transaction is (from_pubkey, from_last_spend_block, amount, destination_pub_key). You prove your ownership by signing it with private key of sending address.

Miners collects transactions, apply it to current database state and generates block.
In block header miner include hash of transactions and hash of database after applying all of these transactions.
Network validates that all included transaction are correct just like with bitcoin.

What is better than bitcoin is that block contents are not really needed after network reached consensus about database state, so after say 1000 blocks you can discard oldest block contents and just store account list at that moment.

This post is probably little chaotic but I can clarify my idea if you give questions.