Why aren't you forming your own?
Because mine would be a laughing stock compared to a Bitcoin Foundation with the lead dev on it's board of directors together with the two biggest Bitcoin businesses. And I don't like to be a laughing stock, that's why. That's a terrible reason. It's also tantamount to stating that Gavin and Bitinstant *are* bitcoin, which, I think, is exactly the opposite of your viewpoint. As I noted, these orgs are inevitable, and there's room for more than one. You could get a pool operator or two on board, maybe the devs of one of the alternative clients, other bitcoin businesses... No, you couldn't build something as prominent as TBF immediately, but if you were serious about it, you could build something else respectable that indeed have some sway, and serve to keep TBF "honest", if that's your intent. Personally, I'd wait a few months, see if there is something that TBF isn't doing well, or doesn't think is important, but you do. And then create an organization to do some of those things. |
|
|
|
I think you are confused if you think I am proposing this as a good idea, I am simply exploring the scenario's viability.
The problem raised with innocent recipients would not be a problem, since the recipient would be instantly aware that the received coins are tainted.
It would only be possible to launder the bitcoins by mixing them with third parties legitimate coins if the third party does not use the list. If the third parties use the list, then they would instantly know they are receiving dirty money, and halt any business with the theif.
It would also not result in destroying bitcoins, since they should of course be sent back to the person they were stolen from.
I realize, that this would be massively disruptive to bitcoins, and I in no way condone this. I am simply exploring the idea.
I wasn't trying to suggest that you think it was a good idea, I was saying that it can't possibly work. That it can't work doesn't depend on who is endorsing it. For this to work, someone would need to impose their will on the entire network at once. All miners, all nodes, all exchanges, everything. Otherwise, the network would fork away from the damaged nodes and life would go on. Also, if they had that much control over the world, they wouldn't need to do this. |
|
|
|
Receiving bitcoins does not require the consent of the receiver, just their address. By the time the receiver would have a chance to check the dirtiness of the transaction, it is too late, he already has them.
I realize this. What the list-compliant client would do was check with the list as soon as the dirty money showed up, the client would warn the user that he had recieved dirty money that are of no use. This could happen with 0 confirmations, as it would already say in the blockchain where the transaction originated from. Well, if you know that, then why didn't you know how to search for and read some of the hundreds of other threads on this topic?  Basically, all of the taint schemes have fatal flaws, and the only way to fix them is to kill the whole thing. |
|
|
|
I would argue, that instead of the above being true, we could end up with exactly the opposite. Governments in developed countries could impose regulation stating that "dirty money" could not legally be accepted. It would be trivial to follow the laundering efforts, all coins that come into contact with or originate from a "dirty money" transaction are not accepted as tender and it could be coded into the standard clients, that "dirty money" would not be accepted as money at all, or even make criminal to accept it.
A central public list would keep all the "dirty money" in check. If you do not use this list, you are responsible if you end up with "dirty money" since you could easily have avoided the risk by using the list. For the sake of this argument, it should be presumed that the majority of participators in the bitcoin economy would adhere to this list.
Receiving bitcoins does not require the consent of the receiver, just their address. By the time the receiver would have a chance to check the dirtiness of the transaction, it is too late, he already has them. |
|
|
|
|
Order placed, 500 assorted colors. I'll let you know how it goes.
|
|
|
|
This is sick. Now we, the users, can choose between red and blue? I can predict the next movement: What about a council of ancient and wise users to judge and arbitrate conflicts in the bitcoin world?  It's not going to work. We just need to keep Bitcoin and its ecosystem the more decentralized and pseudonymous we can. Well I agree, we do not want to be blue. However you might look at it a different way. Gavin and the like are setting themselves as the king, we should at least organize a Senate... I would rather not have to do this but our options are not many. LOL. Yes, please make a senate. When you find out that your senate can't make anyone do anything that they don't want to do, and neither can the foundation, will all of you stop bitching about the foundation? |
|
|
|
A nice little song....  A nice little video... |
|
|
|
|
You created labels (accounts) for some addresses, and then you received bitcoins with them. Then you spent them without specifying a label (account) that they should come out of, meaning they were deducted from the "" account.
Accounts are just an internal bookkeeping system. The actual transactions in your wallet don't carry the tags with them.
|
|
|
|
Newbie question: to make a fully secure savings account, is it possible to roll some 20-sided dice a bunch of times to generate a private key, then use a calculator or TI-95 to derive the public key?
The first part you probably won't do very well, leaving you with a weak key. Do it with one die at a time, into a box without looking, and ALWAYS take the number that comes up. Takes 60 throws to generate that much entropy. The second part is apparently yes. I'm not sure about that specific model, since it is very old (1987), but any of the later Z80, 68k or ARM calculators should have enough power to do the math. Hmm. I may have to put fresh batteries in my trusty old TI-85. |
|
|
|
Why does the standard client always send the change to a new address?? It would make more sense to send the change back to one of the sending addresses.
Sending to a new address leaks the least privacy. Also, there is no concept of a sending address in the bitcoin system. |
|
|
|
The scripts have no notion of time, and this is for good reasons.
Okay. Awareness of time would be a useful feature. And a huge can of worms... Blocks have timestamps which need to be accurate within a few hours. Blockcount can also more or less work. Yes, but the scripts do not. Basically, transactions only depend on their order, specifically they must come after their inputs, and before their own double-spend attempt. Adding a notion of time or block count would make it possible to have transactions that might be valid in one block, but not another, which could have cascading consequences and be a big ugly mess. And that is only the most obvious problem, the one that we are aware of, there are probably plenty of others too. |
|
|
|
|
I'm not sure. Off-topic, maybe? Or maybe a full non-child board under Other.
|
|
|
|
The scripts have no notion of time, and this is for good reasons.
Okay. Awareness of time would be a useful feature. And a huge can of worms... |
|
|
|
Still a tiny chance of recovering the laptop. The encrypted wallet is not on the flash drives. In my mind at the time, I thought that encrypting the wallet was a repeatable process just like encrypting any other file, so I did not think to back it up again.
Yes the developers really screwed that one up. That's why bitcoin still deserves beta status. Don't be too hard on the devs. Wallet encryption has been around for like a year, and we are just now noticing this problem, which suggests that it is not obvious except in hindsight. |
|
|
|
|
The scripts have no notion of time, and this is for good reasons.
Maybe try 2-of-3, with an option to print and forget one of the keys. That way, if the second device is lost, you can load that key up, recover all of the transactions that used it, and make new ones.
|
|
|
|
|
Good idea, but I'm not sure that dev & tech is the appropriate parent board.
|
|
|
|
If you look at the block chain with a hex editor it appears at the start of every block I believe. I'm looking at bool LoadExternalBlockFile(FILE* fileIn) and bool ProcessMessages(CNode* pfrom) in main.cpp to see if an unexpected instance of the pchMessageStart could cause an issue.
Doesn't look like it, no. In LoadExternalBlockFile, the most obvious way to mess it up is covered by the code already. And that way to mess it up is to try to get the parser to skip a valid block by putting in a fake magic number and a size value that would make it miss the start of the real block following. But the code is already smart enough to avoid that problem by only advancing nPos if it finds a valid block. If it doesn't find a valid block, it only skips past the few bytes of the fake magic number. This is only meaningful when the parser is in the "looking for the start of the next block" state. The magic number has no special meaning inside a block, and since it is only 32 bits, I think there are good odds that some number of blocks include that sequence by random chance already. Note also that loading external block files is not a common thing. People should not be loading block files from untrusted sources in the first place. If someone has the ability to change your block file, you probably have much bigger problems already. In ProcessMessage, the context is a message, rather than a stream, so the parser doesn't need to be as clever. It will still mark peers sending bogus block messages as misbehaving and eventually disconnect and ban them. |
|
|
|
|
I don't understand your question.
This is a magic number used to identify the network.
|
|
|
|
|
I'm in. Hurry, October is almost here.
|
|
|
|
|
Show Posts
