Im trying to get some cash. Wonder if we will get a worldwide cyprus event soon.
Seems unlikely to me. Cyprus was caused by an inability to devalue. Most of the world doesn't have that problem. Mind you, we have different, potentially worse, problems. We just don't have that particular failure mode on the menu. |
|
|
|
|
Colored coins are a pretty lousy idea anyway.
I mean they sound like a great idea at first, but they just don't seem to work when you try to actually do it. That sort of stuff belongs in a merged mining alt-chain. Namecoin is the proof-of-concept, but doesn't support fractional ownership, so it isn't exactly right. A chain for general fractional ownership has been described elsewhere. Just needs to be implemented.
|
|
|
|
|
The signed/unsigned fork may have been longer. I'm not sure.
I think that the record for typical latency race fork is 2 deep.
|
|
|
|
Because more BTC was bought than sold?
Heh. That would be a neat trick. |
|
|
|
|
Compression is easy. Look at the last bit of the Y coordinate, add it to 0x02 and use that as the flag instead of 0x04. Then discard Y.
|
|
|
|
|
Can we get a mod in here to nuke that link, and maybe give the spammer a time-out for advertising his scam in here?
|
|
|
|
His point referred to distribution not division. The only value that Bitcoin has, beyond niches, is that ascribed to it in supplanting something else of value and this remaining so.
You are really reaching here. Go back and read the first post. Most of it is about division, not distribution. And his summary at the end even makes it clear that he is talking about the "limited supply". Perhaps you are reading what you want to read, rather than what was actually written? You have two choices, as do I. The first is to maintain the myths for as long as possible, make what you will of good fortune (and perhaps work, I don’t know you and don't dispute efforts expended), continue facilitating zero-sum intellectual and capital investment and waste an incredible opportunity for crytocurrencies to revolutionise finance and personal empowerment that would far surpass short-term personal gains. The second is to recognise that if bitcoins are not scarce because they may be replicated (for all intents and purposes, with just a name change) then what is their value, or if they are scarce then people will find something else to use instead; and thus something needs to change.
I can make no sense of this, which is strange because all of the words are familiar to me. If you'd like to try to restate it more clearly, feel free. Oh, and your dilemma in the second part is false: scarceness is necessary for money. That’s up to you, but please don’t assume everybody is an idiot.
I never assume that anyone is an idiot until they've given me a reason. In fact, if you read my posting history, you can see for yourself that I have a tendency to chastise people for underestimating the public (this comes up often in the many many threads about naming the fractions). P.S. Confusion does not imply idiocy. Money is hard to understand, very few people really "get" it, but I suspect that most people can if they put in the effort. |
|
|
|
If someone popped up asking if the software could safely hold up his aquarium without bending or cracking, there isn't much that can be said by way of direct reply.
Such was his analogy. He is deeply confused. It is neither defensive nor tangential to point that out.
Tangential in that it doesn't address his point, rather ones own. Defensive in responding with mutual and valueless memes to distract from the possibilty of any merit. We might not all agree, but we do all understand the point he was making. If you hope to build cryptos into anything more than a zero-sum techie plaything I suggest it's time to stop playing and skirting around the questions everyone outside this small circle will have. If you don't, then as you were. There was no point to address. Bitcoin is not bread. The sustaining power of a loaf of bread is fixed, and dividing it up doesn't change the sum. One loaf cannot feed a herd of angry villagers. The money power of bitcoin is not fixed. 1 BTC can serve the exchange uses of the entire world. Value is not a thing that exists outside of our minds. We aren't embedding some of it into our money. We are measuring it, like we measure temperature or distance, just not with a coherent or standardized scale*. No one is worried that there won't be enough temperature to go around, or enough kilometers. Worrying that there won't be enough money for everyone demonstrates a serious confusion. Once again, it is not defensive to point out that someone's thinking will not lead to useful questions, much less useful answers. * Although bitcoin is the world's best attempt at a coherent measure for value, by far. The far end of the scale is subject to the whims of politicians or bankers. If only that were the only problem... |
|
|
|
Oops, we are both wrong. It is 2 hours. No idea why I've been thinking 3. main.cpp, function CBlock::CheckBlock: // Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
Note that this changes the maximum amount of borrowed time from ~1% to ~0.6%. Actually, I'm rounding (and I was rounding before). 2/336 is 0.5952% and 3/336 is 0.8929%. (336 being the number of hours in 2 weeks.) |
|
|
|
Your solution is indeed simple. But it doesn't do the same job that checkpoints do. Checkpoints are not about forks in the present or future, they are about helping clients avoid dead end forks in the past, while they are doing their initial sync. Checkpoints help new nodes catch up to the network with minimal annoyance for the node operator, nothing more*. So you are saying that checkpoints don't actually prevent my node from downloading, storing and routing an alternative block that would refer to the genesis? Or are you saying that they do prevent it, but the important thing here is that I should care more about those who are just downloading the chain and dont know yet which branch to choose?  Well, the genesis hash was coded in from day one. If you want an alternate chain, you need a new genesis hash, plus you'd have to clear out the checkpoints. (My apologies if that wasn't what you meant, I'm not entirely sure that I understand you.) The early blocks had very low difficulty. If I wanted to, I could generate thousands of low difficulty blocks, with appropriate fake timestamps, and I could set my node to wait for new connections, then feed those bogus blocks to the noob. They'd figure it out eventually, but I could keep them mired down for hours or days, working on my garbage. The checkpoints give a handy shortcut to that "eventually". If my chain doesn't include the checkpoint blocks, the new node won't waste their time on it. The notion of "the correct chain" gets fuzzy. If I have a lot of hashing power, like more than the rest of the world, and I start today making a new chain, but I keep my farm isolated from the rest of the network, is it "the correct chain"? The only really hard rule is that the longer (more work, not necessarily more blocks) chain is correct. My chain would be (work) longer, so in that sense, it is correct. But no one knows about it but me, so the world would be working on a chain that they think is correct. When I release my chain, it will overturn possibly thousands of blocks, possibly millions of transactions. The hard rule says that it should happen, but almost no one would actually wants that outcome. A checkpoint could invalidate my whole chain, if a big part of the network upgrades to a client that includes a checkpoint that happens to come after I started. That situation is unrealistic, intentionally. But it shows that the simple rule that we can easily write into our software is incomplete. We humans want the rule to be "the longer chain is correct, except...", and the "except" part is hard to write. We know that checkpoints aren't the right way to codify the exception. If you've ever talked to Gavin, or even read his posts on the subject, you'll know that he absolutely hates that he could end up in the position of picking which chain wins. So, we end up in the strange situation we are in. The checkpoints are useful in the real world , but we can see that they also hold a power that no one actually wants to wield. The devs advance them now and then, but always sorta grudgingly, and always months behind. If someone released a 5000 block attack chain, we'd all be bitching that the checkpoint was too far behind. Because no one has (and probably never will) hide a fork of that length, we are all bitching that checkpoints are contrary to the bitcoin design. |
|
|
|
Hmm, I went back and looked, and I was wrong. The bug is not symmetric. It is still unimportant because it only represents a fraction of 1% of the interval. Basically, every 2016 blocks, we look at the previous 2015 blocks for the difficulty adjustment. This is off by one, because we had intended to look at the previous 2016 blocks. I was confused about the symmetry part because this was mostly discussed in threads about time-warp attacks. Some alt-coins allow difficulty to be skewed more easily in one direction than the other, so Art Forz showed that he could game them by cranking difficulty way up, or way down. Bitcoin's difficulty algorithm is perfectly symmetric*, so the best we can do is tweak the final block's timestamp (within the very liberal timestamp rules) to shift a few hours of actual time into or out of the apparent time of the current period. Say you are a miner that wanted a lower difficulty in the next period. You can make that happen if you find the appropriate block by setting the timestamp in that block as far forward as the rest of the network will accept, about 3 hours. This makes the next difficulty about 1% lower than it would have been if you'd put the actual time into that block. If not for the bug, the next retarget period would start at that timestamp, so the apparent interval of that period would be 3 hours shorter, which would bump the difficulty up by about 1%. You could again manipulate the current timestamp, but the best you can do is 3 more hours, which compensates for the 3 hours borrowed before. So, the worst that can happen is that if a lot of miners get together, they can keep the difficulty about 1% too low for a long time. They can't ever get a second 1%. But, because of the bug, the timestamp of that block is never actually checked. The period is calculated based on the timestamp of the following block. That block can be as early as 1 second later than the median timestamp of the 11 blocks before it. This slight asymmetry means that a large group of miners could repeatedly keep the difficulty a fraction of a percent lower than they could with the liberal timestamp rules alone. It also means that borrowed time doesn't necessarily need to be paid back, if they can get a 51% cabal working. Not like there aren't worse things they could do at that point... See this thread for some discussion on both issues. * Well, not perfectly symmetric, because of the bug. But we use 2016 blocks at the retarget interval, come hell or high water. Art had ASICs several years ago, so he would "test" alt-coins by throwing a lot of hashing power at them, then leaving. If he represented 90% of the hashing power on some alt coin, it could take months for them to retarget back down to their normal speeds. Some of them responded by adding code to allow difficulty to drop faster if hashing power left. This is the sort of asymmetry that really matters, and Art showed them that it opened them up to serious manipulation. |
|
|
|
I'm glad you managed to dig up and read my proposal for exponential difficulty reorgs, and that you find it superior. Not surprising, considering that yours is a degenerate case of mine where the exponent is infinite.
But it really isn't a checkpoint system. The checkpoint system is all about the past, while both your proposal and mine are useless in that domain.
I wish I did, but as you figured, I didn't. I'm a man of simple solutions. Checkpoints that are there now, in the bitcoin client, are stupid. My idea - may be simple, but at least it would do what it has to do and close the problem once and for all. And it's surely much simpler. Your idea - I believe it's impressive, but why to complicate things that are simple and do the job? Your solution is indeed simple. But it doesn't do the same job that checkpoints do. Checkpoints are not about forks in the present or future, they are about helping clients avoid dead end forks in the past, while they are doing their initial sync. Checkpoints help new nodes catch up to the network with minimal annoyance for the node operator, nothing more*. The real replacement for checkpoints is a smarter sync system. Greg is working on a smarter sync (see here), but I don't think it has been implemented or tested yet, so for now, we are stuck with the dumb downloader and checkpoints as a sanity check. * They can also be used to rectify a fork in the network, but this is an extraordinary usage that requires a lot of manual intervention by a lot of node operators. When a signed/unsigned bug was found in the value interpretation code and someone used it to give himself billions of bitcoins, a checkpoint was used to help the corrected chain overtake the errant chain that had grown for several hours before the fix could be applied. It was also used to unroll the more recent BDB/blocksize fork. But again, these were not checkpoints already built into the code, we just used the same mechanism as a manually override. |
|
|
|
|
Every 2016 blocks, each node looks at the timestamps of the recent blocks and calculates what the difficulty should have been to make the span 2 weeks. This is used to set the new difficulty, and blocks with a different difficulty are rejected. If there is a fork that covers the last block in the calculation window, then each branch will have a slightly different difficulty.
(Note that there is a subtle and unimportant bug in the code that throws the calculation off by a small fraction of a percent. The bug is symmetric, so no one can use it to tweak difficulty in the long run, so it isn't a security issue.)
|
|
|
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really good solution, if you want  Just make a rule that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever constant you want, but I think more than a week time would be exaggerating. No, that sucks. Sorry. Yeah, I'm sure your checkpoints idea is much better. I'm actually even ashamed mentioning something such stupid I'm glad you managed to dig up and read my proposal for exponential difficulty reorgs, and that you find it superior. Not surprising, considering that yours is a degenerate case of mine where the exponent is infinite. But it really isn't a checkpoint system. The checkpoint system is all about the past, while both your proposal and mine are useless in that domain. |
|
|
|
|
My input (mentioned in several of the previous 1000 threads on this exact same topic, thanks for searching... ) is that people will figure out their own names for things.
No one calls the US Dollar a "buck" or a "greenback" because Congress sat down in committee and figured out some cool slang words for us to adopt.
|
|
|
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really good solution, if you want Just make a rule that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever constant you want, but I think more than a week time would be exaggerating. No, that sucks. Sorry. |
|
|
|
i said din another post price was a problem, no one listened of course, btc is sliding and nothings being done from the top
LOL. "the top". Bitcoin has no "the top". |
|
|
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them. not really. they only put checkpoint for blocks that are buried at least few hundreds deep already - unlikely to be reverted by honest means. but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine. well that's a practical solution, but it violates the notion of 'peer-to-peer' or equality for all nodes in the network. there is no indication of 'checkpoints' in the satoshi whitepaper. furthermore, if we rely on such checkpoints for security, why do we even have proof of work at all? Why don't we just rely on the checkpoints? I'm having a hard time figuring out what you mean by "equality of all nodes". The equality (or inequality) of nodes is not part of the system. No one cares about nodes. We care about the chain. If a node has the correct chain and can give you a copy, it is "equal" to all of the other good nodes. If it doesn't, or can't, then it equal at all, isn't even a node. The checkpoints do not provide any security, nor were they ever intended to. They just keep "unequal" nodes from wasting your time with bogus chains (whether by accident or malice). Also, you are free to edit and recompile as needed. You can strip them out entirely, or add your own, or change them. Whatever you want. The reference client is written for (and compiled for) working well for a wide audience. Technically, a longer chain is the best chain, regardless of the checkpoints. In practice, the checkpoints are far enough in the past that if a new chain showed up that overturned one, we'd almost universally consider it an attack, and roll back. P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution. |
|
|
|
Once upon a time, there was a guy that didn't understand the difference between physical goods with mass, and abstract money. He wrote a story comparing bread to bitcoin. Sadly, everyone laughed at him, because each tiny little bit of bread can only be consumed once, so the whole loaf has only a fixed amount of sustaining power, no matter how divided, while money circulates to be used over and over again without ever being consumed.
Not everyone's laughing at him, many are laughing at the tangential and defensive responses. If someone popped up asking if the software could safely hold up his aquarium without bending or cracking, there isn't much that can be said by way of direct reply. Such was his analogy. He is deeply confused. It is neither defensive nor tangential to point that out. |
|
|
|
Nothing grows at 10%+ every 2 weeks for a century. Run the numbers out for a decade or two if you don't believe me. 
|
|
|
|
|
Show Posts
