I will be there, and I will be on the alt-coin panel as well very excited! Flying inform Europe. :-)
Edit: not staying at one of the hotels. I am paranoid about all that bitcoin centralized in one place. Especially those hotel networks.
I hope people are not bringing tons of Bitcoins with them. That seems risky. Good old cash for me  Heh. I intend to treat the whole trip like a visit to Defcon. Dumb phone, no computer. |
|
|
|
|
Correct thread title:
Some random guy says that he's heard from "anonymous sources" (aka other random guys), that the government is preparing to prosecute some bitcoin users
|
|
|
|
Not gonna happen.
From the numbers of 'not gonna happen's, I'm guessing I've worded my post badly. I just wanted to know how people would feel if a bunch of late adopters upped sticks and started their own thing having had us Bitcoiners pioneer e-currencies. It wasn't about inflation or voting rights. They can fork bitcoin or make their own, but they don't, no matter how they vote get to take the value that we have put into the system over the years. If their new system is useful, it will begin to gather value for itself. This experiment has been done lots and lots of times already. Bitcoin is the most valuable not because it was the first, but because it is the best. A vote will not change that any more than a vote could make gravity reverse itself. |
|
|
|
|
I'll be there. Staying at the Marriott.
I'm flying in to LAX earlier in the week, going to visit some family and then drive up. Can't say exactly when I'll get there.
|
|
|
|
|
Here's the thing, there is no vote. Mining doesn't matter.
Any block that exceeds the generation curve in the software is rejected. Doesn't matter if 99.9% of the world population want it, the blocks are still not valid. Doesn't matter if 99.9% of the hashing power on the planet wants it, the blocks are still not valid.
There may be a new thing, a thing that is not-bitcoin, and people may use it. But bitcoin blocks will continue to follow the original generation rate, forever.
|
|
|
|
C. CASE #3
1. There is / are account(s) in a wallet. There are addresses in accounts - I am correct?
2. When I pay BTC 1 somebody for a service, the remaining BTC 9 are sent to a hidden address. These BTC 9 are sent internally to the same account as the original BTC 10 or to a new account?
1. Incorrect. Accounts are a purely local bookkeeping measure. You can associate one or more addresses with a given account, but that just means that new incoming payments to that address are added to that account balance. 2. This entire question is based on a faulty premise. Coins are not owned by accounts. When you spend, the account you specify is decreased by the amount of the spend. The coins used for the spend have absolutely no bearing on the account system. Start with a new wallet. Generate a new address, associate it with account "A". Receive 100 BTC to that address. Default account: 0 BTC Account "A": 100 BTC Now create a new address, associate it with account "B". Now spend 50 BTC, specifying account "B". Default account: 0 BTC Account "A": 100 BTC Account "B": -50 BTC At this point, your wallet also has a change address in it, with a 50 BTC UTXO that can be spent. That address is not associated with any account, but since you'll never see it, you can't give it out to receive coins anyway. Also note that at each step, the sums of the accounts was equal to the wallet balance. 0 + 100 = 100 and 0 + 100 - 50 = 50 You could use the move RPC command to "transfer" 1,000,000 BTC from acocunt C to account D. Default account: 0 BTC Account "A": 100 BTC Account "B": -50 BTC Account "C": - 1,000,000 BTC Account "D": 1,000,000 BTC And again, the sum works out. |
|
|
|
|
Right now, a new chain takes over as long as the embedded difficulty is at least one hash more than the currently known chain.
I have proposed many times that reorgs beyond a trivial depth should require exponential difficulty increases. For example, we could say that a reorg of more than 10 blocks requires 1.02 times as much work, per block past 10, or dD=1.02(blks-10).
This would force any potential history rewriting attacker to move quickly and make their intentions obvious to all, lest they find themselves fighting that exponential.
My scheme, like all such schemes to add state, has some very serious downsides. For starters, it makes network convergence not automatic. I have argued a bunch of times that the trade-off could be worthwhile, but I still have to accept that the burden of proof for messing with such a core concept is very high.
|
|
|
|
The bug is that the timestamp difference is calculated on the wrong blocks. If you change it, then the new software will be instantly incompatible with the old software, and they will never, ever, ever reconverge. That is a hard fork.
My suggested solution, that the 2 blocks in question must have nearly the same timestamp doesn't cause a fork at all. The reason the bug works is that it lets you cheat the timestamp system. The bug is basically that you can have something like this I'm getting tired of saying it. You are talking about something totally different. The bug is that the window is calculated on a range of blocks that is offset by one from the blocks it actually should be looking at, leading to a tiny inaccuracy. The inaccuracy sums to zero in the long run, which is why no one really cares about it. Amusingly, you are also totally wrong. No node on the network will accept a block that appears to come from more than a few hours into the future. |
|
|
|
|
The bug is that the timestamp difference is calculated on the wrong blocks. If you change it, then the new software will be instantly incompatible with the old software, and they will never, ever, ever reconverge. That is a hard fork.
That is the only bug that I'm aware of in the difficulty code. You are talking about something entirely different, which is not a bug, but a design decision. The looseness allowed in block timestamps is something else that generates a bunch of whining and "good" ideas for fixing, but so far, no one has actually come up with a compelling argument on why the numbers they pulled out of their ass are better than the numbers satoshi chose.
|
|
|
|
Any asymmetric function for difficulty adjustment can be gamed.
Your concerns are inherent if someone has > 51% of the hash power. Rather than show 6 blocks required for security require 6 blocks worth of POW is required. Clients would show that the chain has lost hashing power without completely locking up. So, the conclusion is that if you can't generate enough hashing power, you can't assume the chain is safe. However, the standard difficulty rule does help there anyway. * Well, almost exactly. There is an off-by-1 bug in the difficulty calculation that throws things of by about a twentieth of a percent, but the bug is symmetric, so it doesn't change the security of the system.
Yeah, they should soft fork that one out. Require that the two blocks have the same timestamp (or the one after must have timestamp + 10 minutes of the old one). You are missing my point. A poorly chosen difficulty mechanism is a force multiplier. It lets someone with considerably less than 50% of the network power fuck with you. P.S. The bug cannot be fixed with a soft fork. It is an absolutely hard fork to change the number of blocks used in the calculation. |
|
|
|
This is an insanely bad idea, just like it was the last 20 or so times it was suggested.
Total proof of work still increases and the "real" main chain should still be the highest. Is there a specific flaw in it? Any asymmetric function for difficulty adjustment can be gamed. If anyone with a bit of hashing power cared enough about the scamcoin de jour, they could use it to overwrite the current chain. If they don't have quite enough hashing power for that, they can manipulate the future chain to exclude whatever they want excluded. If you compensate for either of those attacks by adding state to the block acceptance mechanism, they can fork your network into oblivion. Note that most of these things have already been done. Feel free to search for the various threads where they have been discussed. Sooner or later, everyone comes to the conclusion that Satoshi got it exactly right*, but there is usually a bunch of whining and crying along the way. * Well, almost exactly. There is an off-by-1 bug in the difficulty calculation that throws things of by about a twentieth of a percent, but the bug is symmetric, so it doesn't change the security of the system. |
|
|
|
A simple rule is build on the valid chain with highest POW.
A chain is valid if
- the head of the chain meets the standard difficulty
- the head of the chain was seen by the miner at least f(block difficulty) minutes ago
Re-targets would be every 2016 blocks, but would take total POW between the 2 endpoints as the target.
The function could be a decaying exponential. For example, the target could drop by 50% every 10 minutes, after the first 20.
f(block difficulty) = 20 + 10 * log2( (standard difficulty) / (block difficulty) )
Blocks which meet the standard difficulty are zero.
If the block has 1/64 of the difficulty, then it would be forwarded to peers, and then held in a queue for 20 minutes + 60 minutes. In the normal situation, another block would arrive that meets the standard difficulty and thus that block would be discarded.
This is an insanely bad idea, just like it was the last 20 or so times it was suggested. |
|
|
|
|
Accounts are just an internal bookkeeping thing. Coins don't belong to them.
|
|
|
|
Besides, demurrage is a natural phenomenon. If we sit on a truckload of apples to survive the winter, some of them go sour. We'd be better off trading some of the apples in the autumn to a contract that provides fresh food throughout the winter. It is usually good to imitate natural phenomenon, and value transfer system should be no exception.
Money is "trading some apples in the autumn to a contract that provides fresh food throughout the winter". |
|
|
|
|
1 in base58 means zero. It is a special case at the beginning of a string to mean 8 bits of zero. This allows the base58 encoding to preserve arbitrary bit strings, rather than just integers.
|
|
|
|
|
If I had to guess, I'd say the switch from BDB in <= 0.7.x to leveldb in >=0.8
|
|
|
|
|
There is no such mechanism. Furthermore, any possible mechanism would be worse than the (alleged) problem it hopes to solve.
Feel free to search out any of the many, many threads on this topic if you'd like more details.
|
|
|
|
|
Meh. The world record for quantum computing is 21. Not 21 qubits, but 21=3*7 at least a few percent of the time. This was after roughly a decade of work since the previous record of 15=3*5. But, to be fair, a good chunk of that decade was in making the initial 15=3*5 result actually be a quantum effect.
Then there is the tricky part about building quantum circuits. Turns out that those get harder the bigger you make them, while classical circuits only get harder at changes of scale. As in, when we shrink a transistor, we can suddenly put billions of them on a die, instead of millions. But adding qubits isn't simply a matter of finding physical room for them, they interact, so the difficulty multiplies for each one added.
I suspect that we have at least a couple of decades, minimum, before quantum attacks on ECDSA become a serious threat. And even if they do, good key hygiene (for example, what the stock client has been doing since day 1) will make the attacks pointless.
|
|
|
|
We should perhaps let Impaler respond, but I feel compelled to comment on this; you must be punished with a currency that loses value over time, so that you can be encouraged to be as wasteful as everyone else.
I guess that could be put more nicely. The bottom line there likely is not to promote wastefulness, but progress, growth, evolution and all the good stuff. The idea of accelerating progress through enhancing flow of value is starting to reveal upon me. Saving is stagnation. In nature, saving achieves little as compared to swift exchange of value. Keeping things stationary - whether material or immaterial - is subject to heavy corrosion. In all things, time eventually eats your value through entropy if you don't use it. As long as a human monetary system obeys the laws of nature, the same would apply there. It's not difficult to imagine how keeping money off circulation (saving) does discourage initiative and achievement => increasing entropy (= what we generally consider the opposite of "good"). When you save, you aren't holding wealth stagnant, you are deferring your claim on that wealth, aka money. By letting the rest of the world use the wealth that you own (by way of your claim on that wealth, aka your money) until you want to use it, you should be rewarded, not punished. When you come along later to claim your wealth, the natural progress of technology should have made the things you want somewhat cheaper for the world to produce for you. Demurrage perverts that process in exactly the same way that inflation does. Under inflation, the money you hold is worth less wealth when you want to spend it, then when you save it. Under dumurrage, the money in your pocket literally evaporates, so that you have less of it to redeem when you want to. Both systems are theft, plain and simple. The difference is that under demurrage, you may have a hard time figuring out who stole your wealth, while under inflation, everyone already knows. |
|
|
|
Let's put this discussing into terms simple enough that even Impaler can understand them.
I have $1000. I have the choice of buying a capital good for $1000 that will return 5% ROI over the next year, or lending the $1000 to someone for a year. If I choose to make the loan, I'm giving up not just $1000 now, but $1050 a year from now. It would be irrational, all else being equal, to make such a loan for less than 5% interest.
Time preference and the general "risk-free" rate of interest are just the aggregate effects of these sorts of opportunity-cost considerations being made by all the holders of currency in the market. Most of the time the ROI is more subjective than the fixed 5% return in the example, but it is no less real for that. No one is taking advantage of anyone else; lending at interest is nothing more or less than redistributing ready capital and future income to where they are each most valuable, which is fundamentally the basis for any economic activity.
Ahh, but you are indeed taking advantage of the unfortunate. Fans of demurrage allege that it is unfair that you have a future time preference while someone else has a now time preference. Because you are capable of planning for the future, you must be punished with a currency that loses value over time, so that you can be encouraged to be as wasteful as everyone else. I'm paraphrasing slightly, of course. But that is the essence of Impaler's argument. |
|
|
|
|
Show Posts
