 Show Posts
|
|
Pages: « 1 2 [3]
|
The fact is that ancient blocks, at any given point in time, are already highly trusted by the network. If they weren't, Bitcoin would simply not work.
There is already "trust" in the Bitcoin network, for these ancient block Every node verifies the history, this is how you can be sure that claims like "satoshi premined a billion bitcoins and is secretly waiting to spend them" cannot be true. We do not trust, and cannot trust— because it would be trust founded on nothing. Except your own Wiki says the opposite: Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary. From: https://en.bitcoin.it/wiki/Scalability#StorageNotice how nowhere in that section does it say anything close to "Every node verifies the history.", and instead refers to "archival nodes". It also says "Only a small number" of them are needed. I think you should stop using the word trustless while you have multiple bitcoin developers telling you that you do not understand it. The way my mind works is that I do not accept BS from anyone. It doesn't matter how large an angry mob gets if what it is saying is complete nonsense. I've addressed every objection to this proposal, and have received confirmation on it now from two people who seem to know something about Bitcoin: Realpra, and a friend of mine whom I know is intelligent (works on SocialVPN). And while not a vote of recognition, one of the Bitcoin is Vulnerable authors didn't say that the idea wouldn't work when I shared it with him, but said "i'd feel nostalgic if i had to part with the genesis block."  Edit: I called it 99.9% trustless, not 100%. |
|
|
|
1:31:31 PM sipa: sugarpuff: now, about dealing with ways to improve performance, IF you are giving up zero trust
I just want to point this out, to make sure that no one overlooked it. Lots of problems get really, really easy once you give up security. That is nonsense. Just a false characterization of what is being proposed. Security is not being given up. Trusted systems have wildly different properties than trustless systems. If you don't mind moving from a trustless to a trusted system, then what you are proposing can work*. And people on the internet often make "wildly" thoughtless comments, like this one here. This is not a black and white proposal like you are trying to make it out to be. It is not a suggestion in the slightest to "give up security." The fact is that ancient blocks, at any given point in time, are already highly trusted by the network. If they weren't, Bitcoin would simply not work. There is already "trust" in the Bitcoin network, for these ancient blocks. For established nodes, there would be zero difference.And for brand new nodes: 1. They would actually exist. If the "doomsday scenario" pans out, and 14TB is needed every 3 months, there would be virtually no new nodes. Your trustless system would be mostly useless to most people, including, probably, you (unless you have a datacenter in your back yard). 2. It would be not entirely trustless, but "approximately trustless" (like 99.9% trustless, once the entire window has been consumed). Read the rest of that IRC chat. New full-nodes would have security greater than the already very-secure light clients that we have today like Electrum. 3. There would be nothing stopping those nodes, if they really want, from downloading an archive of the no-longer-useful data from the discarded blockchain tail. Even the posts telling you it won't work are recycled. So far not a single post has shown that this "won't work". Every objection was answered. |
|
|
|
There is new software being developed for the forums, so that's why upgrading and fixing everything would be pointless.
Sorry, not sure I understand what you mean by "new software", could you elaborate or link to more info? |
|
|
|
|
Sorry if this was already asked (I did a search for "upgrade" and couldn't find anything).
Why are the forums stuck on version 1 of SMF? SMF v2.x has been out for many years now I think.
Are there plans to update the software?
|
|
|
|
Unless I'm misunderstanding you, I think I addressed that in an earlier reply:
I thought this was obvious, but perhaps not: New nodes could ask others for the current root then. If nodes lie about it, there are one of two possible scenarios:
- They give a root that is too old. This can be mitigated by asking multiple nodes and picking the majority answer, combined with simply downloading the rest of the blockchain. If it got unlucky and the majority lied, it will eventually catch up and discard the outdated root on its own anyway because of the rolling window that's hard coded.
Downloading the rest of the block chain requires someone storing the entire block chain, no? You can't download something which everyone has deleted. I do not believe that is correct. The relevant bits of "the entire block chain" are always carried forward by the network and stored. This proposal is addressing the irrelevant bits, which can include some or all of the following: - Lost coins (a coin can be declared "lost" by some metric, like coin age > T, where T = 2 years.) - The histories of coins that were spent and are now living farther down in the blockchain (within the rolling window). - Any other outdated information. There's no reason to store the history of a "coin" (in quotes because we're really talking about balances) all the way back to its creation. It can simply have a new, verified "origination point" in the blockchain. But besides that you have an even bigger problem: it costs me, or any network attacker approximately nothing to make sure that every single node you connect to is a compromised node I control. This is the problem which bitcoin seeks to solve! And the answer which Satoshi came up with, and the only answer which we have at this time is to validate the entire chain from start to finish and trust the longest valid fork. That answer is, as far as I can tell, identical to what I am proposing. All the implications remain the same. You still end up needing to validate "the longest fork", it's just that forks are trimmed down to a reasonable size. - They give a root that's too young. This can be mitigated, again, by asking multiple nodes. If it also gets unlucky with its chosen majority, it should be able to figure this out because it's assumed that not all nodes are evil, and it will eventually stumble across a trustworthy one, which would make it have a longer blockchain than the ones that the lying nodes gave it, and it would automatically adopt that one. This is an invalid assumption. Your ISP could simply block packets from honest nodes, for example. Yes, and that's a problem that Bitcoin also faces. There's no difference that I can see here. |
|
|
|
True VISA scale (i.e 5,000 tps on blockchain)?
Figure 5,000 transactions per second. Average tx is 400 bytes that is maybe 2MB/s (16 Mbps) sustained to write to the disk. Average block would be 600 * 5,000 * 400 / 1024^3 = 1.2 GB. So pretty much nothing. Now to validate txs requires reading the outputs from the UXTO so maybe double that in terms of random reads. Still we are talking a tiny fraction of the IO that even high end disks (to say nothing of SANs) can handle today.
Everyone thinks of disk first because it is the most obvious but in my analysis of the resource requirements I see it as the least critical bottleneck for full nodes. If I had to rank them it would be node bandwidth (especially for residential connections), then memory, then computing power, and way back in last place would be disk capacity and speed. Thanks for that analysis DeathAndTaxes! Very informative.  Also, just an FYI, I edited the OP to add: Edit2 March 5, 2014: Something not mentioned here is that bitcoind can (and might already in some ways do) prune its locally stored blockchain, but only after it downloaded the entire thing once. Thus, this issue is more of a problem (I think) for new full-nodes, which currently must download the entire blockchain before they can prune the entire thing. Based on a convo I just had about this topic over on #bitcoin-dev, I'm realizing that I have some knowledge gaps that I need to fill to better understand some of the alternative proposals, but I think others here might find this interesting so I'm sharing it here (with sipa's permission): 1:31:31 PM sipa: sugarpuff: now, about dealing with ways to improve performance, IF you are giving up zero trust 1:31:35 PM sipa: sugarpuff: see it this ways 1:31:47 PM sipa: sugarpuff: internally, every full node maintains a database of all unspent transaction outputs 1:32:13 PM sipa: sugarpuff: this is a high-efficiency, compact database with just outputs (not signatures for example) and not those that have already been spent 1:32:31 PM sipa: sugarpuff: every block you can see as sort of an authenticated patch against that database 1:32:45 PM sipa: (add outputs of trenasactions in the block, remove the outputs spent by transactions in it) 1:33:08 PM sipa: if we can somehow agree on a snapshot of that database at some point in time, and you trust it, we can just copy the database 1:33:13 PM sipa: instead of copying all blocks before it 1:34:01 PM sugarpuff: sipa: right, and that sounds like going into checkpoint territory. the rolling-root proposal is similar but not entirely the same 1:34:27 PM sugarpuff: but old blocks should have almost unanimous agreement in the network 1:34:36 PM sipa: sugarpuff: not done yet 1:35:07 PM sipa: sugarpuff: there are proposals to make such a snapshot of that database essentially for every block, and put a hash of that snapshot in the block itself 1:35:14 PM sipa: sugarpuff: and have this validated by miners too 1:35:43 PM sugarpuff: sipa: ah, yeah, that's a good idea. is that what UXTO is about? 1:35:56 PM sipa: the UTXO set is just what we call that database 1:36:10 PM sugarpuff: ah, lol, i just got the acronym 1:36:11 PM sipa: (Unspent TransaXtion Outputs) 1:36:14 PM sugarpuff: 1:36:29 PM sipa: now, this has a very significant impact on the network 1:36:41 PM sipa: as validating and maintaining these database snapshots is not cheap 1:37:16 PM sipa: (there are ways to make it pretty efficient, by using a merkle tree for that entire database, but the impact is not neglectable) 1:37:48 PM sipa: now, you can have a node that just asks a peer, "give me your current UTXO set", and it can validate that at least the majority of hashing power agrees with it 1:38:02 PM sipa: without needing to downloading any old blocks 1:38:36 PM sugarpuff: sipa: just by asking enough nodes for it and assuming the majority is right? 1:38:56 PM sipa: sugarpuff: no no, not the majority of your peers 1:39:06 PM sipa: sugarpuff: you can actually just validate the entire old blockchain, but only the headers 1:39:14 PM sipa: sugarpuff: which is very cheap (80 bytes per block) 1:39:18 PM sipa: sugarpuff: like SPV nodes do now 1:39:31 PM sipa: sugarpuff: but the headers would be committing to the hash of these UTXO set snapshots 1:39:42 PM sipa: so you can verify that the chain agrees with the snapshot 1:39:50 PM sipa: which implies the majority of miners do 1:40:31 PM sugarpuff: sipa: i'd like to do more reading on this and not use up more of your time, do you have some recommended links about this topic? Think SPV + UTXO thread is a good start? 1:40:54 PM sipa: several mailing list posts, forum posts, ... 1:41:00 PM sugarpuff: too broad... 1:41:05 PM sugarpuff: i could spend a year doing that 1:41:18 PM sugarpuff: i love the bitcoin paper, i've read it like 3.5 times now 1:41:18 PM sipa: there's no nice centralized knowledge repository of all these experimental ideas 1:41:28 PM sugarpuff: ah that's unfortunate 1:42:15 PM sugarpuff: sipa: ok, well thanks, i think what you said here is enough to get me started. i'll go do some more research on it. right now there are too many gaps in my knowledge to give you useful replies on this 1:42:23 PM sipa: 1:42:23 PM sipa: yw |
|
|
|
Your suggestion won't work because there's no way to resolve conflict over which purported branch is valid except by reference to the historical block chain data.
Unless I'm misunderstanding you, I think I addressed that in an earlier reply: New nodes could ask others for the current root then. If nodes lie about it, there are one of two possible scenarios:
- They give a root that is too old. This can be mitigated by asking multiple nodes and picking the majority answer, combined with simply downloading the rest of the blockchain. If it got unlucky and the majority lied, it will eventually catch up and discard the outdated root on its own anyway because of the rolling window that's hard coded.
- They give a root that's too young. This can be mitigated, again, by asking multiple nodes. If it also gets unlucky with its chosen majority, it should be able to figure this out because it's assumed that not all nodes are evil, and it will eventually stumble across a trustworthy one, which would make it have a longer blockchain than the ones that the lying nodes gave it, and it would automatically adopt that one. |
|
|
|
Could etotheipi negativeone (I *just* realized what that says!) or someone knowledgeable comment on how the "rolling-root"/"ledger-solution" impacts this proposal (whether it enhances it, makes it unnecessary, or is wrong for reasons XYZ)? Summary: keep the blockchain down to some finite size by moving unspent transactions out of old blocks and into new ones at the head via a "rolling-root" mechanism. Relevant link: https://bitcointalk.org/index.php?topic=501039 |
|
|
|
Realpra, sorry, I tried, but my google-fu is failing me. The closest thing I was able to find is this post of yours mentioning it. If you could provide some history/links it'd sure be appreciated! |
|
|
|
This was debated before, what you call "rolling root" we called "ledger-solution"/"ledger-block".
Same idea; every say 1 year you would take all the 20 years or older transactions and move their unspent outputs to the latest "ledger block". Amounts in the ledger block would be much like coinbase transactions/miners fees.
Barring minor minor data growth from address fragmentation and perhaps block headers, this puts a quite final limit to the blockchain size.
Another idea (of my own) was "swarm clients" that individually would validate only parts of the blockchain, but as a whole would validate the whole thing - all zero trust etc..
This would allow for almost the smallest devices to participate in block validation forever.
You can google these terms, and I do mean google, the forum search is shite.
The main reason nothing has happened yet is laziness and people too busy getting rich off of Bitcoin - and no you can't lump me in with that group I have been hard at work helping Bitcoin for a while now.
Thank you sir! *That* is what I was looking for. I will do as you suggested and search for those terms. If you're feeling especially kind, could you summarize the current status of the "ledger-solution"/"rolling-root proposal"? Did you already summarize it by saying, "The main reason nothing has happened yet is laziness and people too busy getting rich off of Bitcoin"? And does that mean that it actually is a potential solution (as vetted by people with brains</ducks!>)? |
|
|
|
Found this, not sure if it helps your particular case.
What is a "Change Address", and why is it useful?
The concept of change addresses is a feature not of the Bitcoin protocol, but of a Bitcoin client. It is implemented not only in Electrum but in most Bitcoin clients, including the original "Satoshi" Bitcoin client.
How it works:
Whenever your Bitcoin client (e.g. Electrum) sends Bitcoins from your wallet's address "A" to a foreing address "B", a new change address "C" is created by Electrum and added to your wallet.
Example: Address "A" has 20 BTC. Electrum sends 9 BTC from "A" to "B". The change (20-9 = 11 BTC) is sent to the "change address" "C". For this purpose, address "C" is created by Electrum at this moment and added to your wallet.
Exception: If all the Bitcoins of "A" are sent to "B", there is no need for creating a change address "C".
Actually, Bitcoin clients can also work without change addresses. In this case, the change would be sent back to "A" instead of the new address "C".
Why the concept of "change addresses" is useful:
Using a new change address makes it more difficult for other people (by analyzing the blockchain) to track how many Bitcoins you have or where you're spending them.
It also conceals which output is the "spend" and which is the "change".
Thanks, that's a very helpful explanation! |
|
|
|
The restrictions are there for a good reason, to encourage learning before teaching. The problem you are about to tackle is hard. I recommend this thread to get an insight of its complexity. https://bitcointalk.org/index.php?topic=88208.0Thanks, I'd had a look at that thread already, but a second, closer read-through is probably warranted (especially since etotheipi has revised his idea a few times). Still looking for confirmation on this or a "you're suggestion won't work for reason(s) XYZ." |
|
|
|
Only the private key holder of the tx output can create a new tx. There is no mechanism to "copy the outputs that were coped as new transactions to the head".
The new protocol dictates that your node create this new transaction for you. Edit: I suspect that might not even be necessary, since the balance wouldn't change. It would just be an alias for the old txn.. not entirely sure ATM.If this method works, and disk space becomes a real problem, it might just have to work this way. (BTW, I'd love to give ya'll faster replies, but this forum has imposed a bunch of restrictions on this account because it hasn't posted much. I can currently post a maximum of 1 reply per 6 minutes, and I don't know if that timer resets each time I try.. Annoying.) |
|
|
|
Discarded by whom? "Considered invalid" by whom? By all full-nodes. Which ancient block? The one that's at the back end of the rolling window. Bitcoin is an imperfect solution to a very hard problem. You can't just handwave it all away like Dilbert's boss. I agree and I'm doing my best to give concrete answers to these questions that are not handwavy. |
|
|
|
If I "sent" you coins and you didn't have the block which contained the transaction which contained that output how would you validate the input is valid and not just some nonsense I sent you because I know you have no way of validating? That just wouldn't be possible. It would be discarded like all other invalid transactions. You wouldn't be able to send to or from an outdated address (it would be considered invalid). You'd use the new ones that were copied as new transactions to the head. It's possible I am misunderstanding (I've only read the original paper a couple times, and perused the wiki, but I'm not working with the code itself). Sidenote: consensus about an ancient block should be extremely high. There should be no disagreement about it. |
|
|
|
How do you reach "internet-agreement"?
One way would be to do what you already do (checkpoints), although those are controversial. I haven't given it too much thought, but it might be possible to do something like have a hard coded rolling window, and have nodes mark the new root with some flag ("currentRoot = true"). New nodes could ask others for the current root then. If nodes lie about it, there are one of two possible scenarios: - They give a root that is too old. This can be mitigated by asking multiple nodes and picking the majority answer, combined with simply downloading the rest of the blockchain. If it got unlucky and the majority lied, it will eventually catch up and discard the outdated root on its own anyway because of the rolling window that's hard coded. - They give a root that's too young. This can be mitigated, again, by asking multiple nodes. If it also gets unlucky with its chosen majority, it should be able to figure this out because it's assumed that not all nodes are evil, and it will eventually stumble across a trustworthy one, which would make it have a longer blockchain than the ones that the lying nodes gave it, and it would automatically adopt that one. I'm making these answers up on the fly btw. I'm sure better ones could be given with more thought. Still don't get what the problem is... |
|
|
|
How else would you bring new nodes online?
Download the internet-agreed upon new "rolling-genesis-block-snapshot". |
|
|
|
EDIT June 18, 2014: To avoid confusion: this thread is now about a solution to the tremendous (and increasing) financial and temporal costs of bringing new nodes online, not disk space....to handle the number of transactions that visa handles in 3 months the bitcoin system will require 14 Terabytes of storage space. To assume that people are going to be willing to buy 14 terabytes of disk space every 3 months (even if it is just $40 in 2020) is a leap. References: - http://stormcloudsgathering.com/bitcoin-what-youre-not-being-told- https://en.bitcoin.it/wiki/Talk:Scalability#Disk_spaceSo... I don't get it. Why do we need to hold onto the root? Can't this problem be easily fixed by letting go of the root? "What about unspent transactions at block 20?" I hear you cry. Copy whatever data is necessary to move them automatically to the head in a new transaction. Am I missing something? Edit March 5, 2014: thanks to Realpra for pointing out that this was called the "ledger-solution". See his reply below, also quoted here:This was debated before, what you call "rolling root" we called "ledger-solution"/"ledger-block".
Same idea; every say 1 year you would take all the 20 years or older transactions and move their unspent outputs to the latest "ledger block". Amounts in the ledger block would be much like coinbase transactions/miners fees.
Barring minor minor data growth from address fragmentation and perhaps block headers, this puts a quite final limit to the blockchain size.
Another idea (of my own) was "swarm clients" that individually would validate only parts of the blockchain, but as a whole would validate the whole thing - all zero trust etc..
This would allow for almost the smallest devices to participate in block validation forever.
You can google these terms, and I do mean google, the forum search is shite.
The main reason nothing has happened yet is laziness and people too busy getting rich off of Bitcoin - and no you can't lump me in with that group I have been hard at work helping Bitcoin for a while now.
Edit2 March 5, 2014: Something not previously noted here is that bitcoind can (and might already in some ways do) prune its locally stored blockchain, but only after it downloaded the entire thing once. Thus, this issue is more of a problem (I think) for new full-nodes, which currently must download the entire blockchain before they can prune the entire thing.
|
|
|
|
|
