Accounts: svn rev 188 (JSON-RPC API changes)

[wumpus]

On a side note, I'm really curious about how blocks and transactions are uniquely identified inside the client, through their hashes ?

Yes, the 256-bit hashes are used as key in blkindex.dat, both for transactions and blocks.

I wouldn't be too worried about them colliding any time soon. Most of the world still uses 128-bit UUIDs for database keys

[1714011560]

1714011560

[1714011560]

1714011560

[1714011560]

1714011560

[1714011560]

1714011560

[davout]

Yes, the 256-bit hashes are used as key in blkindex.dat, both for transactions and blocks.

I wouldn't be too worried about them colliding any time soon. Most of the world still uses 128-bit UUIDs for database keys

Using 128-bit UUIDs as primary keys is definitely not a good idea.
Even if collisions are highly unlikely in most cases it still is a really bad idea for clustered indexes.
There can only be a single clustered index, and it's usually the PK.
In other words, on each INSERT statement, the RDBMS will statistically have to write in the middle of the table.

As for collisions, they might be more likely than you expect, especially if bitcoins get to grow old.
Time will tell I guess.
Also I'm getting really frustrated about this because I want to back and check all this with numbers, and except for Mathematica there is no tool that'll let me make interesting probability calculations. And I don't have Mathematica installed ><

[wumpus]

Using 128-bit UUIDs as primary keys is definitely not a good idea.
Even if collisions are highly unlikely in most cases it still is a really bad idea for clustered indexes.
There can only be a single clustered index, and it's usually the PK.
In other words, on each INSERT statement, the RDBMS will statistically have to write in the middle of the table.

That depends on the UUID generation scheme used; if you use random keys, sure, that can be inefficient for indexing (at least for btree-based indexes... hash-based indexes don't nearly suffer that much). Time/node based schemes fare much better in that regard.

There is no good alternative to UUID as keys for distributed databases, as you don't want a single point of failure. With UUIDs, every node can generate its own keys without any synchronisation and waiting. That's very efficient as well.

However, UUIDs suffer from the problem that they are big, and that they're not semi-sequential so you cannot use them for sorting. Twitter recently introduced a scheme between sequential IDs and UUIDs, and open sourced it, Snowflake (http://engineering.twitter.com/2010/06/announcing-snowflake.html). But although multiple hosts can be generating them at the same time, it still requires some synchronisation. And because there is a limited number of generation hosts, you'd have a few 'id generators' locally per data center.

Anyway, this is a very interesting topic, with a lot of development The only sure thing is that strictly incrementing sequential keys seem to be a dying breed.

[ptd]

As for collisions,

Assuming all SHA hash outputs are equally likely then, we have to generate 4 * 10^38 hashes to have a 50% chance of finding a collision. Thats not going to happen anytime soon. See http://en.wikipedia.org/wiki/Birthday_attack .

[davout]

As for collisions,

Assuming all SHA hash outputs are equally likely then, we have to generate 4 * 10^38 hashes to have a 50% chance of finding a collision. Thats not going to happen anytime soon. See http://en.wikipedia.org/wiki/Birthday_attack .

Thanks for doing the math, I didn't manage to get Mathematica working so i dropped the calculation altogether.
Guess p is much smaller than I expected

[ribuck]

... we have to generate 4 * 10^38 hashes to have a 50% chance of finding a collision ...

And the expected cost of that collision is, I think, the average value of one bitcoin transaction. Multiply the cost by the likelihood, and Bitcoin would need many more than 8 places after the decimal point to record the tiny economic risk.

[davout]

... we have to generate 4 * 10^38 hashes to have a 50% chance of finding a collision ...

And the expected cost of that collision is, I think, the average value of one bitcoin transaction. Multiply the cost by the likelihood, and Bitcoin would need many more than 8 places after the decimal point to record the tiny economic risk.

You're forgetting block hash collision

[galeru]

What exactly is the difference between move and sendfrom?  Is it just shorthand for getting the account address and sending the coins to it?  How does a moved coin act in the block chain?

[Gavin Andresen]

What exactly is the difference between move and sendfrom?  Is it just shorthand for getting the account address and sending the coins to it?  How does a moved coin act in the block chain?

moves do not touch the block chain, they add accounting entries to your wallet to adjust the balances of the accounts involved.

[davout]

What exactly is the difference between move and sendfrom?  Is it just shorthand for getting the account address and sending the coins to it?  How does a moved coin act in the block chain?

moves do not touch the block chain, they add accounting entries to your wallet to adjust the balances of the accounts involved.

So, how is the balance of an individual address managed ?
Lets say two accounts have an address each, i send 100 to address 1, then move the funds between the two accounts, will bitcoin actually use the first address for sending when sending coins from the second account ?

[Gavin Andresen]

So, how is the balance of an individual address managed ?
Lets say two accounts have an address each, i send 100 to address 1, then move the funds between the two accounts, will bitcoin actually use the first address for sending when sending coins from the second account ?

Accounts do not affect the previous-transaction-selection algorithm at all; if you sendfrom FOO, bitcoin doesn't make any effort to only use coins that were received by FOO.

Think of your wallet as being a big pool of coins.  Coins are not stamped with account names when they go in, instead, there's a little man with a green visor making entries in a ledger.

Each receiving address is a pipe that dumps coins into the pool, and the little man knows which pipes are assigned to each account.

Every send the little man grabs his shovel and picks a bunch of coins randomly from the pool.  Then debits an account.

And for moves, the little man doesn't have to touch the coins in the pool at all, he just adjusts his ledger.

[caveden]

So, an account balance doesn't always equal the summed balance of all address that belong to this account, that's right?

[davout]

So, an account balance doesn't always equal the summed balance of all address that belong to this account, that's right?

Looks like no

I was going to say I liked little men but figured how it could be interpreted XD

So, yes, thanks for your explanation, makes things very clear.

However, that would allow someone holding an account at some online wallet site to know that some address belongs to the wallet system, do you see what I mean ?

That might be problematic for privacy, maybe there should be an option to force the previous transaction selection algorithm to choose only transactions to a given account (which could also fail meaningfully when trying to send funds from an account that came themselves from an account transfer).

As far as I know it can't be handled at the application level.

Well anyway thanks for the accounts feature, it works very well !

[QuantumMechanic]

Is there/could there be a command that moves all the bitcoins associated with a given account to a new single address?  I could see this being useful for auditing purposes.

Edit: This probably wouldn't be useful since I don't think you have control over which addresses payments are sent from using sendfrom.  I.e. if you're trying to maintain an association between account A and address 1, then a payment sent from account B may be at least partially sent from address 1, with the "little man with a green visor" doing the relevant bookkeeping on the side.

[davux]

So, an account balance doesn't always equal the summed balance of all address that belong to this account, that's right?

If I understood correctly, there's no such thing as an "address's balance". At least, it doesn't mean a lot. Even with no account, you can receive coins on an address, but you never know which address the next payment will take coins from. The only thing you can tell is what percentage of the whole income each address is responsible for.

If I understood correctly (again), the whole point of accounts, or one of them, is to introduce the notion of separated balances, precisely for this reason. But then, a balance only has a meaning for a whole account, not for an address.

I think it's clever to separate accounting from the specifics of sent and received coins. It's just like if you manage money for, say, a bank. Let's pretend you can only add money to your account by depositing real bills. You always know how much money you have in your account, but when you pull bills from the ATM machine, they're not necessarily the ones you deposited before. And, well, it sure is a privacy issue, just like fingerprints on bills taken from the bank are a privacy issue, but if you want your coins to be separated from the others', run your own wallet. The "pool" thing seems fair enough to me.

[Gavin Andresen]

I wrote all this up (minus the little man) for the wiki:
  http://www.bitcoin.org/wiki/doku.php?id=accounts

Let me know if it doesn't make sense.  Or, even better, fix it for me!

[Gavin Andresen]

Oh, and RE: privacy:

Mixing all of the 'coins' for all of the accounts together is, I think, an overall plus for privacy.  True, you might receive coins from somebody and be able to figure out "Hey, they sent me some of exactly the same coins I deposited in my BigBitBank account yesterday!   They must have an account at BigBitBank, too!"

But mixing all the accounts' coins together makes it much more difficult to figure out where any user's coins came from, or, if you know where they came from, where the user is spending their bitcoins.  Unless you can subpeona BigBitBank's records, of course...

[davout]

Oh, and RE: privacy:

Mixing all of the 'coins' for all of the accounts together is, I think, an overall plus for privacy.  True, you might receive coins from somebody and be able to figure out "Hey, they sent me some of exactly the same coins I deposited in my BigBitBank account yesterday!   They must have an account at BigBitBank, too!"

But mixing all the accounts' coins together makes it much more difficult to figure out where any user's coins came from, or, if you know where they came from, where the user is spending their bitcoins.  Unless you can subpeona BigBitBank's records, of course...

Yea that makes sense, so if I sum it up, with accounts :
 - (-) I can pretty accurately tell if some other address belongs to the bank pool (even if I'm not able to check an arbitrary address)
 - (+) I can send coins from addresses that didn't originally receive the coins, making them very hard to track through BBE

Sounds fair!