movoda.net my favorite timer based text based mmorpg  oh and nethack |
|
|
|
Humans can live without vegetables, and you can get the necessary fiber, vitamins, and minerals from other sources.
If you are interested you will find several amusing accounts of doctors during the last few hundred years who have tried to prove just that. Vitamin C can be found in raw liver, etc. Raw sheep brain suggested by one for other necessary vitamins. Generally they don't ever do as well as the Inuit apparently do. Cheers to OP! |
|
|
|
Hashing power can be introduce at will and without any control of the network. That is pretty bad IMHO.
There was a coin where the network had no control concerning newly added hashing power. It was called liquidcoin. Typically a difficulty adjustment algorithm takes care of that  |
|
|
|
Oh you absolutely cannot just send 300MB, your peers could just lie to you and it would be greatly in their short term financial interest to do so (because they could make you accept inflation or spends of non-existing coins). But you can produce this trusted state for yourself and you don't need to store anything else. ECDSA is cheap, with libsecp256k1 my i7 desktop here validates at almost 6000x the maximum realtime rate for the Bitcoin network.
Thanks for your very helpful replies. There are two issues we are discussing: 1) Cost of downloading & validating full chain 2) Cost of "keeping up" a full node I guess your machine is 6000x more than adequate enough for task number two My original concern is with number 1. In general, do you think we are prepared to cope with these two costs with current software (e.g. core)? Could you point toward some development task which could help keep these costs down? |
|
|
|
So there needs to be a way to make stake dependent on running a node continuously. The proposed mechanism for this is as follows: Every block has a hash. Let's say the hash for a given block starts with ABC. Once this block is created, every address matching AxxxxxxBxxxxxxC (or some other formulation; this is just an example) must "check in" by sending a transaction to themselves to prove that they're connected. These Proof-of-Connection transactions will be included in the next mined blocks. This transaction does not lose Stake-Days or Coin-Days. If this Proof-of-Connection transaction does not appear in a block within X blocks (perhaps 30 minutes' worth?) of the triggering block, their Stake-Days drops back to 0. This would prevent people from accumulating stake by simply keeping their coins dormant.
Proof of Connection looks inherently vulnerable to sybil attacks. Further, one could park the stake on a service which does the "check in" and avoid running the node anyway. You are trying to patch a tiny hole in the PoS system. There is a much bigger hole: the explicitly unfair distribution of new currency, something that bitcoins are supposed to help us avoid. |
|
|
|
The data you use to validate doesn't have to have any relationship to the data sent over the wire beyond the fact that you get the same results when verifying. No hashing is required to verify a new transaction that shows up (other than the hashing in the signatures, of course). A transaction shows up, it names which txid:vouts it is spending and provides the required scriptSigs. You look up those txid:vouts in your utxo set and accept the transaction if the signatures pass. The utxo set is currently about 300mbytes. You don't store the history there, you just store the much smaller set of spendable coins. The resulting behavior is indistinguishable from a node with the history except that a node without it can't serve old blocks to new bootstraping nodes... and this all works today, Bitcoin core is already structured this way, but doesn't yet support actually removing the old data.
OK I think I am finally getting your drift. A full client can basically *already* (sorta?) make a utxo list and use that rather than hold the whole chain? Incidentally if the set is 300mbytes my estimate was way off. For 1 million addresses (I think we are at more than that now), at 160 bits each, that leaves 15 bits to each address for the amount of unspent. Am I calculating something wrong there? And if this is true, why aren't we doing it already?
Can is very different than _does_. Today everyone constantly validates these things and instantly rejects invalid data. If you instead make it so that validation has a high marginal cost and by default people don't validate then you'll find many never validate and a few do. If miners start rewarding themselves too much coin ("A bit of inflation is good for the economy!") the network will partition into real validating and non-real validating nodes. You might then say that the non-validating now need to go fix themselves to validate but what if they have spends in the non-validating fork that they've already acted on which are conflicted in the other fork already they're certantly not going to want to do that. Once the network has a non-trivial partition there is an extreme risk that it is fundamentally impossible to resolve it without causing severe monetary loss for someone. So the "don't check and if something goes wrong, hopefully people will figure something out" mode doesn't really work— the only time you can really deal with an invalid block is the moment it happens, not later after people have taken irreversible actions because they thought it was okay.
Yes, an increase in marginal cost of validation is a real concern. I guess I am thinking that the marginal cost of validating 5+ years of dust and mixing transactions is already getting too high. At the very least we will need some kind of intermediate node. Sending all new nodes 20 gigs of data and checking ECDSA sigs when you could be sending 300Mb seems suboptimal. Especially if that 300Mb list of UTXOs had been validated by the entire network of miners for 100 blocks or more. If there is a better way to do that with minimal (or no) changes to the protocol I am all ears. Thanks! -- |
|
|
|
Do you think these are all his coins? If I were him once I got to 1 million in that wallet, I'd have switched over to mining into a different wallet address.. held onto the 1 million as an investment and spent the rest.
Every block was mined to a different address. The evidence of one operator is from the extra nonce. |
|
|
|
There is _no_ storage requirement in general for the past history. Full nodes do not need to store it, they've already validated it and can forget it. This isn't implemented in full nodes today— little need because the historical storage is not very great currently, though Bitcoin core's storage is already structured to enable it: You can delete old blocks and your node will continue to work normally, validating blocks and processing transactions, until you try to request an older block via rpc or p2p (and then it will crash).
This one kind of blew my mind You're not talking about SPV nodes either here I think. I guess the idea is that when a transaction appears on the network and I want to validate it, the TX already has the UTXO data and I just need to hash it, if necessary up a tree until I can compare to a merkle root that I do have stored. But if I really have nothing stored, then the high level security of validating everything myself can't possibly be there? Anyway, I am looking forward to seeing more of this. What I am proposing is a restructuring of the database. The block chain is a log structured database due to the way it is built, but this is in general not an efficient way to store this kind of data. A restructuring could be performed and validated by the network. However if I understand what you are saying it may never be necessary. Validation is the process which accomplishes this spotting and rejection. If you seek to not validate, then in cases where there is no validation those errors can be passed in. If some parties validate and some do not then you risk partitioning the network— e.g. old nodes 'ignore' your "superblock" and stay on the honest network, while new nodes use it and are willing to follow a dishonest network (potentially to the exclusion of the honest one).... and the inconsistency is probably worse than the fraud. So you're still stuck with if someone mines a invalid state that some nodes will not catch because they do not verify, then all must accept it without verifying it. How is this different than a miner today issuing a block with a coinbase transaction greater than 25 coins? Anybody can verify at any time that the block is fraudulent and ignore it and all blocks above it. With my proposal new nodes can always check old blocks to verify the chain and the checkpoint. They just aren't required to store the old blocks. Cheers - |
|
|
|
Expect a multi-million dollar lawsuit against the police authorities. Feels sad for the player.... but at least this is a clear case of police brutality, and he is liable to get a substantial compensation.
Maybe you should think this through a bit more, keeping in mind who the biggest psychopaths are and who is most heavily armed. If you still don't get it you could take a look at how many cases like this against officers for their regular abuse of authority lead to compensation. |
|
|
|
This kind of stuff has been discussed many times before. What you're suggesting here violates the Bitcoin security assumptions— that the integrity of the data is solid because all nodes full nodes have verified it themselves and not trusted third parties to do it— and in the simple form described opens up some pretty nasty attacks: Make your state commitment always be to one where you own all the "lost" coins, sure, you're unlikely to find the next commitment yourself, but if you do— ca-ching!. Of course, if you're verifying the state commitments, then there is no reason to use a 'high apparent difficulty' to select which blocks provide them (see the proposals about merkleized utxo for how a reduced security model can be implemented this way).
Thanks for comments! I guess one could argue that we trust the network to verify transactions and provide the block chain, why not trust it to make checkpoints? I can see the argument that the integrity and security is better if every transaction back to 2008 is verified by every node, but that needs to be weighed against the integrity and security lost by the number of full nodes dropping slowly off due to the storage and computation requirements. I need to think more about the the potential attacks, but I'm not sure I follow the one you describe. A state commitment which redistributes unspent outputs, lost or not, to different addresses, would be easily spotted and rejected. I was more worried about incentivising nodes/miners to pay attention to checkpoints at all due to the extensive requirement of verification. A miner would likely simply ignore superblock and try building on top of the last normal block rather than spend the time verifying a list of millions of entries and writing gigabytes to storage. I had a look through https://bitcointalk.org/index.php?topic=314467.0looks relevant but I'm not proposing such a reduction here. |
|
|
|
I was referring to the block itself
You can't get much smaller than a list of who has what money, that's the essential information. So that's 160 bits per address and lets say 32 bits per amount (in general more is needed but some compression could be used as most unspent amounts are less than 2^32 satoshi). That's 640 bytes per entry. At 2 million nonzero addresses (roughly where we are now) that is about 1.3 gigs. Seems like a lot for one block but if you are dropping 15 gigs of block chain the net gain in portability is substantial. There will always be copies of the old chain lying around which can be verified as authentic as well as used to verify that superblocks are valid. |
|
|
|
how much memory would that snapshot require do ya think?
Good question. I guess the answer depends on the exact implementation. Do you mean how much RAM required for verification or for creation? Or the size of the superblock itself? One related question is how much "data efficiency" there is on the block chain, which we could define as the size of a list of all unspent output address/amount pairs divided by the total size of the block chain. Lots of mixing and spending leads to lower data efficiency. A quick back of the envelope calculation shows we are doing pretty well here now, I estimate 75% or so. Edit: more like 10%. I had confused bits and bytes At this stage it seems clear that we don't need anything like this because TX pruning works pretty well already. However as rumblings continue from block chain bloat and the number of running full nodes decreases due to storage costs could it become worth considering a solution of this nature? |
|
|
|
The superblock could even behave as a genesis block of sorts in that full clientś and miners might not be required to download previous blocks.
I think they still would have to download previous blocks because a block only contains 10 minutes worth of transactions. It doesn't know all the inputs and outputs of what came before it. A checkpointing sblock would contain not only 10 minutes worth of transactions but a snapshot of the entire chain. You can look at it as making a new pre-mined coin where the pre-mine goes to all addresses which had coin on the old chain. One could even play some more tricks like adjusting the sblock difficulty in proportion to the amount of data collecting in the chain to target a certain portability. |
|
|
|
Less than 5% of the Bitcoin trades occur in China.
What leads you to that conclusion? Volume numbers published by exchanges say otherwise. |
|
|
|
Thought I'd share this if others are trying to achieve it for demonstration purposes.
|
|
|
|
|
I've been thinking about ways to make a decentralized checkpoint of sorts.
My purpose here is more to find if anybody has built anything like or this or considered it rather than to suggest it be a practical suggestion for the main chain.
A superblock checkpoint is mined in the usual way, but the rate can be chosen such that the difficulty is some factor 10000 or more times the usual block difficulty. When a miner gets lucky enough to find a superblock, it creates a normal block but also includes a checkpoint structure of some kind, for example a list of all unspent outputs, or a digest of that list. The superblock could even behave as a genesis block of sorts in that full clientś and miners might not be required to download previous blocks. A superblock author could be incentivized by an increased coinbase reward, but the additional proof of work added to the chain from a superblock would not be greater (i.e. superblocks could be orphaned).
|
|
|
|
Bit coin is just the first stage of developing a new currency.. [....] So how much money would it take to KILL Bitcoin when it could be challenging revenue in a country? At the moment there are many countries trying to embrace it and there are many countries that hate it and it threatens revenue (taxes). For a country to take on "killing" btc it would be a splash in the pan .... nothing ... just a self preservation move. Come on ... some countries can spend more on there armed forces, nuclear program self defence in a week or month?  Summary... BTC will be killed at some stage, by some organisation or joint government. Enjoy whats left of the ride and for how long it lasts because I will and I will weep when its gone  1) We are at about $600m cap in alts. Is crushing one chain worth your time and effort? Why? 2) remember if you have that kind of hashing power you will get rich quick by mining by the rules, or simply lose money by DDOSing. |
|
|
|
|
If you give out the new money to those who have the most already, you only exacerbate the problem of unequal distribution of wealth. Haven't we learned our lesson there yet?
|
|
|
|
|
USD is a proof of stake coin. The stake is often called "collateral" and the coinbase transaction is called a "loan".
|
|
|
|
I'm pretty happy about all the people selling. I was worried I'd never get to buy at sub-500 prices again.
+1 I think most of the sellers were people not really understanding Bitcoin. Once you understand it, you become more inclined to hold onto it imo. Hello.. pay the rent much? vacations? bedsheets? alpaca socks? |
|
|
|
|
Show Posts
