A rolling root to solve Bitcoin's scalability problem?

[sugarpuff]

a) SPV clients have copy of all block headers

Yes, and that doesn't prevent the MITM attack that I mentioned.

b) there is no such thing as "balances" at an address.  Bitcoin works on the concept of inputs and outputs.

What language do you speak then? Special forum language?

Here is an address: 18uvwkMJsg9cxFEd1QDFgQpoeXWmmSnqSs

Click on that link and you will see on the resulting page a label that says Final Balance, indicating what I think is a "balance", at an "address".

d) "The transactions containing them can simply be moved automatically according to some strict rules that I don't care enough to come up with"  That is why you have no proposal.  "Um yeah we can do this stuff but it will require some stuff but I don't really fill like saying the stuff but if you don't agree with me you are jerks and just trolling.  We can fill in the stuff later and stuff."

... Maybe I will take the time, or maybe I won't. It doesn't much matter in the end does it? If you don't see the potential usefulness of the idea at this point, I don't think you'll see it even if I write the code for it, so why waste my time?

[1714877549]

1714877549

[1714877549]

1714877549

[1714877549]

1714877549

[1714877549]

1714877549

[1714877549]

1714877549

[V4Vendettas]

Sounds to me like I'm going to need a bigger hard disk. Still I have every faith some smart lad or lass will come up with a solution. Seems bitcoins come so far it would be a shame for it to fall apart because of the block size. I just cant see it happening or maybe I just don't want to see it.

[kjj]

b) there is no such thing as "balances" at an address.  Bitcoin works on the concept of inputs and outputs.

What language do you speak then? Special forum language?

Here is an address: 18uvwkMJsg9cxFEd1QDFgQpoeXWmmSnqSs

Click on that link and you will see on the resulting page a label that says Final Balance, indicating what I think is a "balance", at an "address".

Well, this farce has gone on long enough.  By now it should be perfectly clear to anyone stumbling across this thread that you are a moron with no interest in how bitcoin actually works.

[oakpacific]

People insist on retaining a full copy of blockchain locally, supposedly for the purpose of protecting the interest of every Bitcoin user, nevertheless, if the anonymization of coins through Coinjoin/CoinSwap/Stealth payment...becomes widespread in the future, those who participate in such txs will have absolutely no interest in you keeping a record of them and couldn't appreciate you more for pruning them.

[maaku]

People insist on retaining a full copy of blockchain locally, supposedly for the purpose of protecting the interest of every Bitcoin user, nevertheless, if the anonymization of coins through Coinjoin/CoinSwap/Stealth payment...becomes widespread in the future, those who participate in such txs will have absolutely no interest in you keeping a record of them and couldn't appreciate you more for pruning them.

Those anonymizing techniques are interesting specifically because the records of transfer are not kept on-chain.

[oakpacific]

People insist on retaining a full copy of blockchain locally, supposedly for the purpose of protecting the interest of every Bitcoin user, nevertheless, if the anonymization of coins through Coinjoin/CoinSwap/Stealth payment...becomes widespread in the future, those who participate in such txs will have absolutely no interest in you keeping a record of them and couldn't appreciate you more for pruning them.

Those anonymizing techniques are interesting specifically because the records of transfer are not kept on-chain.

I meant even the remaining tx info they wouldn't care to have removed.

[sugarpuff]

Well, this farce has gone on long enough.  By now it should be perfectly clear to anyone stumbling across this thread that you are a moron with no interest in how bitcoin actually works.

I'm sure that's also true of the people who run blockchain.info, you should go tell them that.

They could write, instead of "Final Balance", "the summation of all of the bitcoins sent to this public key fingerprint (successful "transactions") minus the summation of the bitcoins sent by the private key for this public key fingerprint to another public key fingerprint that resulted in successful transactions that made their way into a block that was accepted by the network", but that would be silly. Likewise, for ever instance that I've said the word "balance" in reference to an "address", I could have defined what those words really mean and how they are calculated, but that would be ridiculous too. It is assumed that people like you who claim to understand how bitcoin works know what those words refer to.

[mot7]

Unspent outputs are only a transactionID and an output number.   In other words , any spending of a Bitcoin requires this sha256 hash and a number referring to the output and the script therein.

Bitcoins dont exist. Inputs and outputs do.

What a rolling root should be (based on my understanding so far) is a pointer to that transaction.  

So how about this formula:

Agree on a confirmation count that provides zero trust guarantees.  Say 100,000

Find the lowest target in the blockchain (remember difficulty can decrease due to a split or other reasons).  If that is less than 100,000 (selected above) then choose the candidate purge point to start at current-100,000 blocks.  If it is more than 100,000 blocks away from the current block, candidate purge point starts at that location.

Change the block version number to "4" (versions 3 are already assigned) and include a special spot for old unspent transactions.  Transactions in this special part of the block would look like double spends if placed in the regular part of the block therefore special handling is needed.  Miners and full nodes will need to validate that the full txid hash ( no matter what normalized form it's in) is identical to the old tx.   

The transaction will then live in two blocks, but with the same txid and same outputs.  During the sunset period all clients and miners should verify that the old tx and new tx do have matching ids and content.  This protects from an exploit in sha256 as the current Tx is added to the trusted merkle tree.

After a sunset period of 100,000 blocks the old block can be purged.  

If someone attempts to modify the transaction, the SHA256 hash will be different.  All full nodes who see an altered transaction should reject the Tx, and if it's included in a block, reject the block.


Yes someone probably thought of this. Yes there are probably errors and inefficiencies but it seems logical.

[theonewhowaskazu]

Random comment in here by a noob at this kind of thing, but I'm not quite seeing why this wouldn't work:

Every client keeps some kind of a record with a balance for each address, right (Or at least, a record with the balance of its own addresses).

At some point, its going to become more efficient to store the balance of each address, rather than the entire blockchain.

At that point, why not start encoding this balance of each address directly into blocks, and have it be verified by proof of work, just like every other transaction? After some number of confirmations (you can "work backward" from block N's balance table to that of block N-1 by looking at all of the transactions in block N) that transaction table is taken down and stored on your hard drive. Only addresses with balances need be stored.

Could it be that simple? Or is it useless as then the size would grow proportionate to the number of addresses with balances, instead? Still, seems number of addresses with balances < total number of transactions in the long run.

[DeathAndTaxes]

There is no such thing as "balance at an address" that is merely an abstraction.  The only thing which exists is input and outputs.   A transactions references as it inputs the unspent outputs of prior transactions.  The transaction destroys (or "spends") those referenced output(s) and creates new outputs (which will become the inputs of future txs).

All spent outputs can already be pruned from the blockchain.  Of the ~18GB only ~4GB of that is usnpent outputs.

[sugarpuff]

Unspent outputs are only a transactionID and an output number.   In other words , any spending of a Bitcoin requires this sha256 hash and a number referring to the output and the script therein.

Bitcoins dont exist. Inputs and outputs do.

(The following comments are not directed entirely at you, mot7, but at everyone who keeps bringing this issue up.)

It baffles me how this thread got so derailed over this philosophical point.

Bitcoins both exist and don't exist. The word "Bitcoin", "balance", etc. exist in a quantum superposition of linguistic masturbation. They are a mechanism through which the universe gratifies the sexual urges of nerdy nit-pickers. The way it works is that one party has Concept A in mind when they say "Bitcoin" (or some other word), while the nit-picker insists on using Concept B for the same term. Concept B does not exist, so it is somewhat unclear why the nit-picker chooses said non-existent interpretation, but perhaps it is because it gives the nit-picker a way to attack another party and derail a thread.

What did Satoshi have to say about the "existence" of "Bitcoins"?

We define an electronic coin as a chain of digital signatures.

That is what a Bitcoin is. Here you can see where the wave function collapsed to a value that actually does exist. If you have difficulty with the word, just substitute "input and output" or whatever other term you fancy. The English language is abundant with diverse words that all refer to the same concept.

It is a waste of everyone's time to derail this thread arguing about these semantics, especially when the other party (me) demonstrated that they know what an "input and output" is, what a "bitcoin" is, etc. The same is true for the word "balance".

Find the lowest target in the blockchain (remember difficulty can decrease due to a split or other reasons).  If that is less than 100,000 (selected above) then choose the candidate purge point to start at current-100,000 blocks.  If it is more than 100,000 blocks away from the current block, candidate purge point starts at that location.

Using confirmation count to determine the window size is interesting.

However, whatever the metric ends up being, it should probably be based on percentages, not absolute values (unless some absolute value can be demonstrated to be useful regardless of network size and transaction volume).

Thank you for bringing this thread back on topic mot7!  

[maaku]

When DeathAndTaxes says there's no such thing as a bitcoin balance, he's not making a philosophical point. He's saying that full nodes do not have balances, or the information necessary to efficiently calculate them in their working memory. Adding capabilities based on balances would require either adding this information to the working set (thereby increasing resource usage for all full nodes), or switching to using balances only which has drastic implications for bitcoin in terms of its low-level functionality. It would be a hard-fork that breaks all infrastructure out there for dubious benefit.

[sugarpuff]

At the request of "HoboJerk", I've revived this thread.

[sugarpuff]

At the request of "HoboJerk", I've revived this thread.

Copying a reply I posted there which I am copying here because if my now (possibly complete) understanding of UTXO is correct, then UTXO is a superior solution to my rolling-root idea:

OK, I decided it's about time I dive into the details of UTXO to see whether or not you are correct. After spending about an hour reading and thinking about it, I think you might be correct.

Here is my current understanding, please let me know whether I've understood it correctly (you too @HoboJerk):

For a new node to boot up from scratch and begin securing the network, approximately the following needs to happen:

1. Download entire BTC blockchain headers.
2. Download entire UTXO blockchain headers. EDIT: download the entire UTXO meta chain.
3. Begin merged mining on UTXO and BTC blockchains.
4. For each new transaction the "almost-full node" receives, query other nodes for the block in which the payer's bitcoins were previously located, along with the hashes to verify the merkle root in the BTC blockchain. Verify the root can be found.
5. Query other nodes for the transactions and merkle root hashes that result in the merkle root hash of the most recent block in the UTXO blockchain. Verify that previous txn the coins belong to exists in the current data comprising the most recent merkle root of the UTXO blockchain.
6. If the transaction passes the above verifications, store all received data so far in order to build the Merkle hash tree that represents all the UTXOs.
7. Continue mining blocks as per above to secure the network and build new blocks, slowly transforming this light node into a full node.

Is that correct? If that's how it works, then you are both correct UTXO secures the network and brings new nodes online fast (and is actually better, I think, than my rolling-root suggestion).

I welcome replies here too as to whether or not I understood UTXO correctly.

[sugarpuff]

Copying a reply I posted there which I am copying here because if my now (possibly complete) understanding of UTXO is correct, then UTXO is a superior solution to my rolling-root idea:

OK, I decided it's about time I dive into the details of UTXO to see whether or not you are correct. After spending about an hour reading and thinking about it, I think you might be correct.

Here is my current understanding, please let me know whether I've understood it correctly (you too @HoboJerk):

For a new node to boot up from scratch and begin securing the network, approximately the following needs to happen:

1. Download entire BTC blockchain headers.
2. Download entire UTXO blockchain headers. EDIT: download the entire UTXO meta chain.
3. Begin merged mining on UTXO and BTC blockchains.
4. For each new transaction the "almost-full node" receives, query other nodes for the block in which the payer's bitcoins were previously located, along with the hashes to verify the merkle root in the BTC blockchain. Verify the root can be found.
5. Query other nodes for the transactions and merkle root hashes that result in the merkle root hash of the most recent block in the UTXO blockchain. Verify that previous txn the coins belong to exists in the current data comprising the most recent merkle root of the UTXO blockchain.
6. If the transaction passes the above verifications, store all received data so far in order to build the Merkle hash tree that represents all the UTXOs.
7. Continue mining blocks as per above to secure the network and build new blocks, slowly transforming this light node into a full node.

Is that correct? If that's how it works, then you are both correct UTXO secures the network and brings new nodes online fast (and is actually better, I think, than my rolling-root suggestion).

Actually, I'm not sure about that. What's the incentive for nodes to mine on that meta-chain? There doesn't seem to be one, and without a compelling incentive a denial-of-service attack might be possible against UTXO. Since mining on the meta-chain decreases the rewards a miner can expect (if there were to mine only on BTC), they wouldn't mine on it, and that might make it easier for someone to get 51% control over it... I'm not sure how that would play out.

I see that the UTXO thread has some discussion about this issue, but it's too late in the day for me to spend more time on this (work calls!): https://bitcointalk.org/index.php?topic=88208.msg971762#msg971762

[sugarpuff]

Actually, I'm not sure about that. What's the incentive for nodes to mine on that meta-chain? There doesn't seem to be one, and without a compelling incentive a denial-of-service attack might be possible against UTXO. Since mining on the meta-chain decreases the rewards a miner can expect (if there were to mine only on BTC), they wouldn't mine on it, and that might make it easier for someone to get 51% control over it... I'm not sure how that would play out.

I see that the UTXO thread has some discussion about this issue, but it's too late in the day for me to spend more time on this (work calls!): https://bitcointalk.org/index.php?topic=88208.msg971762#msg971762

maaku made an interesting reply in that thread in response to my request for confirmation of understanding.

Here is that reply along with my follow-up question, you might want to follow along in the UTXO thread:

You never ever under any circumstances want to be mining on top of a chain you have not validated the entire history of.

Interesting point. Hope you don't mind if I mention your reply in that other thread as well.

So, what is the takeaway from that then? That new lite-nodes can use UTXO to validate arbitrary queries, but they cannot participate in securing the network until they have all the transactions for the leaf nodes of the entire UTXO tree?

[sugarpuff]

Looks like rolling-root is still needed for new nodes to be brought online reliably because UTXO, according to maaku, requires you "to download and process every single block since Genesis": https://bitcointalk.org/index.php?topic=88208.msg7391152#msg7391152

[jonald_fyookball]

OP, It seems like the bottom line is you would need massive changes to bitcoin (with hard fork) to do what you want to do....and really the scalability problem is quite manageable so that's why it doesn't make sense.

[sugarpuff]

OP, It seems like the bottom line is you would need massive changes to bitcoin (with hard fork) to do what you want to do....

It's time for a hard fork anyway:

http://hackingdistributed.com/2014/06/13/time-for-a-hard-bitcoin-fork/
http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/

the scalability problem is quite manageable so that's why it doesn't make sense.

There are opinions, and there is data. The latter impresses me more and is linked in the first post.

[sugarpuff]

In the UTXO thread, I modified the "7 steps" in the previous posts here with my current understanding of how UTXO can be used to quickly boot up "full-security new lite-nodes":

https://bitcointalk.org/index.php?topic=88208.msg7423013#msg7423013