It's quite amazing how the Tylers' animosity towards Bitcoin seems to have done a total 180 from just a few months ago. Now we're getting ZH articles on Bitcoin regularly, all neutral to positive. Looks like he finally figured out what Bitcoin really was, or at least that Btcoin articles generate tons of pageviews and comments.
Peter Schiff had his "21 million" moment. |
|
|
|
Firstly, FinCEN do not make laws, they are an enforcement arm of the govt. Their interpretation is as good as the next best lawyer who wants to come along and argue against them in the courts. Secondly, the law is so vague as to be basically useless for any objective interpretations so everybody gets to make up whatever flavour of opinion that suits them on the matter. No one has ever said with any convincing arguments that bitcoins are illegal AFAIK, so they are legal. Nothing new here. FinCEN will say whatever they want to suit their agenda, nothing new there either ... I think they have bigger problems elsewhere than "virtual currencies" right now (note they did not attempt to define what a "virtual currency" is anywhere, or they may happen to include govt. fiat in the dragnet  ). |
|
|
|
Go, little coins, go! Ah, I think I found the ultimate ZH commenter quote! The simple fact of the matter is that bitcoins are intangible. You can't hold them, feel them, smell them, or hide them. There you have it. Irrefutable logic. If you can't touch it, smell it, or hide it, it is invalid. Much like outer space, neurons and math. Well, you can hide your math, but it's probably not a good thing... Would be interesting know exactly how much a guy like this keeps in an electronic fiat money database. |
|
|
|
|
The damage is already done ... in confidence based fiat currency it is enough to merely have the knowledge that authorities are considering seizure of deposits to precipitate the withdrawals.
Even if the eurocrat creatures totally did a u-turn on the theft/tax of bank deposits and opened up the Cyprus banks for regular trading on Tuesday the run has already started because the knowledge is now out there.
The run has begun, get out of anything to do with euro. it is no sin to panic early in these situations. The ECB is totally out of touch and out of control, it is an epic example of why centralised systems can be bought down through simple mistakes, by the powerful at the center. Bitcoin should observe and learn well ....
Edit: People saying Cyprus is small island probably don't realise that it has order of EUR60 billion in deposits. This is quite large, and the people who have money now locked up there, i.e. think Roman Abramovic, etc Russian billionaires and other powerful people are not going to react the same as your average Joe Schmo on the street and just take it up the ...
|
|
|
|
Just another demonstration how Bitcoin is by far better money than Euro (in this case).
Bitcoin is fungible. Euro is not. In Germany Euro worth 100 cents in Cyprus it is only 90-94 cents. Bitcoin worth 100000000 Satoshis everywhere.
cypherdoc: is a bank run a deflationary event?
they are just grabbing the cash to pay for more powerful computers to add more zeros to the end of the numbers they already fictionally create and to buy more coin at this stage in the game  You are way closer to the truth than you might imagine. Because these seized deposits are Tier 1 capital, i.e. unencumbered cash, then the banksters can leverage those by 10-20 to 1 with various ponzi loans and derivatives ... what that means is that 5.8 billion that they seized will most likely be used as collateral for up 58 - 100 billion in debt. Cash is the heroin that system craves right now ... and as we witness it will do anything, legal or illegal, by which to acquire it for the next fix. |
|
|
|
According to Dutch newspapers they did it because the majority of the savings in Cyprus were from tax evading Russians and that this was the reason the European Union wouldn't bail Cyprus out directly.
That appears to be the reasoning, a similar one they used for effectively banning cash from the southern European economies. "Tax evasion" has been the convenient excuse for central bank monetary meddling for over 100 years now. They are on a sorely misguided path. They are meddling with the basic properties of their money itself, i.e. digital fiat databases, and in the process thoroughly destablising the whole financial and economic systems. It is is yet more evidence that they have fundamental misunderstandings about what money is and how people think about money. It is a fatal conceit of socialist power centers that inevitably leads to the collapse of their monetary systems. While we worry about the ECB writing reports about bitcoin, the ECB themselves seem not to understand how money works, in fact some of the bitcoin ECB report was revealing in how central bank bureaucrat thought about money, and it was unsettling to observe how ignorant they were in some aspects. I would mark this as the beginning of widespread bank runs in Europe. The message is now clear, bank deposits do not belong to you but at any time the ECB can "have" them to re-allocate as they see best. |
|
|
|
|
I think the correct term for wide-scale theft like this is plunder.
Not unlike MF Global but seems to have a thicker patina of legitimacy applied, they are calling it a "one-off" tax on bank deposits.
|
|
|
|
Maybe look at basing transaction fees on the number of locks a transaction uses is another angle for a solution? Loosely specifying "1MB" as the block limit is in fact abstracting a data size away from the actual physical configuration of how that data is stored/accessed which is what actually defines the total transaction cost, includes CPU cycles, disk read/writes and storage. Excellent reasoning... If bitcoin was about locking databases that would be just the very kind of quantification that should go into its specification.
Unfortunately, bitcoin is a little more about attaining, storing and transmitting a proven state of consensus than about controlling how many entities can access how many bits of it, and which bits, exactly ...
Quite. My suggestion was just an example, a hint towards engaging in some lateral thinking on the exact nature of the underlying problem we are facing here. It could be mem. locks (I hope not), it could be physical RAM space, it could mem. accesses, CPU cycles, total HD storage space occupied network-wide. Point being, we are searching for a prescription for the physical atomic limitation, as a network rule, that needs to priced by the market of miners validating transactions and the nodes storing them, so that fees are paid and resources allocated correctly in such a way that the network scales, in the way that we already know that it theoretically can. If we are going to hard fork, lets make sure it is for a justifiable, quantifiable reason. Or we could be merely embarking on holy grail pursuit for the 'best' DB upgrades to keep scaling up, endlessly. Bitcoin implementations could be DB agnostic if it were to use the right metric. Jeff Garzik has some good ideas like a "transactions accessed" metric, as I'm sure others do also. Maybe some kind scale-independent transactions accessed block limit and fee scheduling rule? |
|
|
|
He's mostly right, but he is using divisibility and fungibility interchangeably which is incorrect. I'm glad he has hit a home run on the financial privacy and intrinsic value link, (the "prison planet money" argument ) Although, I thought his summary should be that bitcoin has the desirable properties of money. It can only become money when the market decides. |
|
|
|
Climategate anonymous whistleblower releases another tranch of FOIA emails and accepts donations in bitcoins. http://wattsupwiththat.com/2013/03/13/climategate-3-0-has-occurred-the-password-has-been-released/#more-82057Even if I have it all wrong and these scientists had some good reason to mislead us (instead of making a strong case with real data) I think disseminating the truth is still the safest bet by far.
Oh, one more thing. I was surprised to learn from a “progressive” blog, corroborated by a renowned “scientist”, that the releases were part of a coordinated campaign receiving vast amounts of secret funding from shady energy industry groups.
I wasn’t aware of the arrangement but warmly welcome their decision to support my project. For that end I opened a bitcoin address: 1HHQ36qbsgGZWLPmiUjYHxQUPJ6EQXVJFS.
More seriously speaking, I accept, with gratitude, modest donations to support The (other) Cause. The address can also serve as a digital signature to ward off those identity thefts which are part of climate scientists’ repertoire of tricks these days.
Keep on the good work. I won’t be able to use this email address for long so if you reply, I can’t guarantee reading or answering. I will several batches, to anyone I can think of.
Over and out.
Mr. FOIA |
|
|
|
I'm tired of these sorts of threads and will not be posting on the issue further. The code that Satoshi left behind is certainly not ideal in many ways, and the only way to fix it is incremental upgrades. That means real work. If you are going to make yourself useful instead of just insulting people anonymously, then get to it and start finding bugs. Probably best if we leave at that then. I'm happy the problem has been laid bare for all to see and the community is made aware of the issues in a transparent way so informed decisions can be made. Fear not, real work is happening. |
|
|
|
How can it be a bug if it is a clearly defined behaviour in the documentation of the s/ware dependency?
Ah, excellent, can you please send me the documentation that says exactly how many locks will be taken by each bdb operation? I haven't been able to find that. Thanks! Well that's implementation specific, as the tutorial states, (posted above), sorry can't be more helpful but I am looking into it so you'll be first to know if I find anything. Pre-0.8 bitcoin have specified the limits for their BDB implementation in db.cpp lines 82 and 83
dbenv.set_lk_max_locks(10000);
dbenv.set_lk_max_objects(10000);
Most definitely a limitation but not a bug nor an "unknown behaviour" is the main point. Unfortunately this is a proxy limitation on bitcoin block sizes, only loosely correlated with block data size, that we will have to live with for now, and we have lived with for some time now. Maybe look at basing transaction fees on the number of locks a transaction uses is another angle for a solution? Loosely specifying "1MB" as the block limit is in fact abstracting a data size away from the actual physical configuration of how that data is stored/accessed which is what actually defines the total transaction cost, includes CPU cycles, disk read/writes and storage. |
|
|
|
evilpete But more than 51% of the hash power has to stay behind until a good 90%+ of nodes have been upgraded. This tries to swim against the tide of all individual incentives built into the system. Why would anyone want to be on a version that the miners are not using? ... you are opening yourself up to the possible risk of ending up on a useless fork. |
|
|
|
Naturally there's still potentially more problems in 0.7 lurking.
and in 0.8 .... what's good for the goose .... 0.7 has been running for much longer in production than 0.8. |
|
|
|
Mike H. The lock limit in 0.7 is not a protocol rule - it serves no useful purpose, was not previously known about and doesn't even appear to be consistent across different versions of Berkeley DB, so 0.7 nodes are already inconsistent with each other. What's more, the lock limit also applies to re-orgs. What that means is that some 0.7 nodes are in an unstable state in which they may be unable to process a valid re-org and thus permanently hose themselves, even with a 250kb soft block size limit. Incorrect that the lock limit rule was not known about. It is stated explicitly in the pre-0.7 source code, db.cpp lines 82 and 83
dbenv.set_lk_max_locks(10000);
dbenv.set_lk_max_objects(10000);
But good to see that you have finally gotten to grips with BDB lock limits ... AFTER implementing the new levelDB that ignored these two lines of code in all pre-0.8 bitcoin reference code ... which recall by your own words ... to paraphrase "if you want a protocol read the source code" 0.8 maybe a superior solution but it has been rushed out. The fact you haven't fully understood the previous code and implemented the upgrade correctly may be more your deficiency than pre-0.7 code. |
|
|
|
I was told on #bitcoin-dev that actually the devs have met the BDB configuration numbers before, and to look at db.cpp to see where in the bitcoin code the explicitly set the numbers they want BDB to use.
-MarkM-
Removed incorrect, thnx Jeff. |
|
|
|
as we want to get back to the 1MB limit, and that can only be done with 0.8. Wrong. |
|
|
|
Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.
So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough need more locks than the BDB had been configured to permit.
-MarkM-
I think that size of the block (total size of all tx) and number of locks required is only loosely correlated ... so raising the block size limit made it more likely that the default lock limit would be hit, but not predictably. If you constructed a block just so, i.e. it has more than 5000 locks required, it will predictably recreate a defective block. In fact, if you were a malicious mining pool operator you could do that now with a pre-0.8 version and fork the chain the same as 0.8. Bitcoin is vulnerable in the current state ... security through obscurity it seems, because someone would need to be arsed to figure out how these lock limits work so they can attack the chain. I could go on but I think I might be saying too much already. |
|
|
|
|
Show Posts
