UUIDs have 2^128 possible identifiers. They are also designed to be collision-proof. Wikipedia says: To put these numbers into perspective, one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs. Compare this to Bitcoin's 2^160 possible addresses. Bitcoin has: 1461501637330902918203684832716283019655932542976 addresses UUIDs have: 340282366920938463463374607431768211456 identifiers |
|
|
|
What are the best ways today to have "safe bitcoin" like "safe sex" ? Is the future of untraceable bitcoin going in the direction of anonymous re-mixers where you have to trust a third party bitcoin bank or are there other ways that i am missing?
In the future I hope Bitcoin will offer: - Manually selecting which coins to send. This would allow you to send coins known to be safe. - Creation of accounts that never mix coins when sending. Use one for anonymous transactions and one for non-anonymous transactions. - Automatically mixing coins to new addresses that you own. This is not foolproof, but it significantly increases anonymity. Third-party mixers will hopefully be available in the future, but most people don't need to use them. Just having them exist gives tons of plausible deniability to the automatic self-mixing strategy. Right now the best thing you can do is the MyBitcoin method mentioned on the wiki's anonymity page. |
|
|
|
This step actually does the disconnection. I am assuming the send address, as values differ the addresses used for sending should be different from the ones used for receiving. Did I understand this wrong?
And yes, a user can carefully do this without a proxy, but we know how many will do that...
You can see him send the BTC to internal addresses. Someone looking at the block chain will see A send to Y, Y send to a few addresses, and all of those addresses send to the destination. You can only completely remove identities from transaction histories if you use someone else's coins: A sends to Y, and some other address sends to the destination using coins not gotten from A. |
|
|
|
- A uses the proxy API to say "I want to send X to B".
- A receives an address Y
- A sends some value to Y, could be more, could be less multiple times
- Once enough is transfered, proxy sends to one or two new addresses internally, breaking the value in pieces with a little randomization along the way
- proxy sends X to B
- proxy sends change to A
--- and the tricky part
- after enough confirmations on both to A and to B transfers are received, proxy deletes the addresses from the wallet
This prevents casual spying, but there would still be a connection between A and B. If an attacker was really serious about seeing where A was spending his coins, they would follow the transactions down to the the first known identity. If this is B, then they can force him to reveal who he received coins from at that address. They then either find A or find a closer person who they can question. This simple mixing can be done without a third-party by creating some new addresses on your machine and doing the mixing yourself. If the proxy has many customers and is careful not to give coins back to the customer who sent them, then you have a true "Bitcoin proxy" that can't be bypassed without compromising the proxy. Relevant: http://bitcointalk.org/index.php?topic=241.0http://www.bitcoin.org/wiki/doku.php?id=anonymity |
|
|
|
BTW, is storing a file on FreeNet reliable ? I mean, as I understand it, FreeNet is P2P. This means that a file is there only if people use it. If I am the only one who need a file, isn't it likely to disappear from the network if I don't consult it regulary ?
It might stay for a week or two (unpredictable). It's certainly not a good destination for backup. |
|
|
|
I almost fell out of my chair when I imagined law enforcement each having Block Explorer running as their home page.
This is exactly the effect I intended!  Once people understand how attacks would be performed, they can learn how to use Bitcoin safely. Maybe Bitcoin could implement a Tor system for the transactions in itself, so buyer and seller never interact directly. I will confess I have not master the bitcoin protocol (I am lazy) so can anyone tell me if it makes sense?
Tor doesn't ensure anonymity, though it is required for anonymity. The problem is not in the network layer; the problem is that every transaction is recorded in the block chain (and there's no known way to avoid this in a decentralized way). See http://www.bitcoin.org/wiki/doku.php?id=anonymity . Maybe Open Transactions will someday be used for Bitcoin-backed bank notes. Open Transactions is perfectly anonymous, but centralized. |
|
|
|
CHK ?
A CHK is the main type of Freenet URI. The file is already encrypted on the network, and the key is in the CHK, so if you keep the CHK secret the wallet can't be recovered. |
|
|
|
I think that this can be fixed by changing this: if (pindex->nHeight == height) {to this: if (pindex->nHeight == height && pindex->IsInMainChain()) {jgarzik: I don't have any orphan blocks right now, so can you test this on your block 90539 and compare it to the real one? |
|
|
|
There are currently 4.56 million bitcoins. Looking at the graph, it seems to be very close to the current reality.
My old prediction said there'd by 4.02 million now, so we are a bit ahead. |
|
|
|
|
You could modify Bitcoin so that they all use the same key for generation transactions.
|
|
|
|
Upload a backup of your wallet.dat (encrypt it first).
Encryption isn't necessary if you keep the CHK secret. |
|
|
|
|
The bitcoins earned per block ("subsidy") will halve at 210,000 blocks, regardless of the network's CPU speed. The problem is in determining how fast we'll get to that point.
The generation difficulty adjustment tries to keep the rate of blocks per hour constant, so the chart won't be far off. The timing of the chart might be a little late because the CPU speed of the network is constantly growing, so blocks are currently being produced more frequently than they should be. Once growth stops in a few years, it'll be possible to predict the times of future subsidy adjustments more accurately.
So the chart is not affected per se by total CPU speed, but by growth/reduction in that speed.
|
|
|
|
Increasing the rate of block generation would increase the number of chain forks, which makes the system less reliable and easier to attack. Focus is shifted from CPU power to network power. 10 minutes already causes a significant number of chain forks: // Don't show generated coin until confirmed by at least one block after it
// so we don't get the user's hopes up until it looks like it's probably accepted.
//
// It is not an error when generated blocks are not accepted. By design,
// some percentage of blocks, like 10% or more, will end up not accepted.
// This is the normal mechanism by which the network copes with latency.
//
// We display regular transactions right away before any confirmation
// because they can always get into some block eventually. Generated coins
// are special because if their block is not accepted, they are not valid. |
|
|
|
|
ArtForz figured out that this is caused because getblock is showing an orphan block at that position instead of the real block. Deleting the block database files fixes it because you won't re-download orphan blocks.
|
|
|
|
I'm suggesting you do this, but it just occurred to me that you could add the ability to put notes on everything wiki style.
Comments about addresses especially. This could be useful for sharing information while investigating scams and such. Plus it would just be fun to sift through all the labels people put on stuff, like I was wondering how much the mtgox donation addy got, I think I found it from my transaction history, but I don't know for sure, or if he had a different one up previously, etc.
I was thinking about that, too, but it seems to me that any comments would get lost in the gigantic sea of pages. If I see a lot of "look at this cool thing on BBE!" posts on the forum, I will implement this. |
|
|
|
An address has 33 significant characters, each of which has 62 possible values (10 numbers, 26 uppercase letters, 26 lowercase).
So you have 62 * 62 * ... * 62 possibilities (33 times).
Actually, now that I remember, it's 58 (uppercase i and lowercase L are not included because they look too similar, same for zero and uppercase o).
So there are 58^33 possibles values, which is slightly more than 10^58. Still high, but not quite as high as 10^92.
As ByteCoin already explained earlier in the topic, an address contains a non-data check code and version number. There are actually "only" 160 bits of randomness in each address: 2^160, or 1.46x10^48 possible addresses. Addresses can also be 25-34 characters in length, depending on how numerically large the hash160+check code is (the larger it is, the more base58 characters required). |
|
|
|
Did anybody ping satoshi on this thread?
Open Transactions must be centralized, so it doesn't fulfill the goal of Bitcoin. |
|
|
|
Thanks theymos, this was much needed. I sent you some bitcoins for your efforts Will you be releasing the source? Or maybe just giving access to your processed data in a nice format? I'd like to try to make some GraphViz charts (for example, being able to graph all transactions to/from a certain address given a maximum depth - that sort of thing). Thanks! I will not release the source unless there is a lot of demand for it. It is written specifically for BBE, and it would probably not be very useful for learning about Bitcoin or making similar things. For example, my getblock->SQL script does a bunch of unnecessary and redundant work in order to create database tables that can be efficiently accessed by BBE. Here are the PHP base58/address functions that I wrote for this project, though: http://pastebin.com/vmRQC7haI will offer data (maybe for a small fee). What format would be useful? |
|
|
|
I made it so inputs/outputs are always listed in the order they appear in blocks. So are listed balances correct, but the faucet is off because it uses/used multiple addresses or something? Can you elaborate on the change issue you mentioned?
Most of the faucet's balance is stored in addresses created when sending change. Here you can see that it sent 0.5 to someone, and then sent back to a new address - this new address does the same thing, and the new address from that transaction does the same thing, etc. You can also see the ordering randomization from this chain of transactions. |
|
|
|
|
Show Posts
