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

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: Gavin Andresen on December 11, 2010, 12:15:50 AM

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!

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

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...

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

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!

davux

sr. member

Activity: 288

Merit: 263

Firstbits.com/1davux

Quote from: caveden on December 10, 2010, 09:55:37 AM

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.

QuantumMechanic

member

Activity: 110

Merit: 19

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.

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: caveden on December 10, 2010, 09:55:37 AM

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 !

caveden

legendary

Activity: 1106

Merit: 1004

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

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: davout on December 10, 2010, 09:24:37 AM

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.

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: Gavin Andresen on December 10, 2010, 08:49:35 AM

Quote from: galeru on December 10, 2010, 02:00:08 AM

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

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: galeru on December 10, 2010, 02:00:08 AM

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.

galeru

newbie

Activity: 8

Merit: 2

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?

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: ribuck on December 09, 2010, 09:11:20 AM

Quote from: ptd on December 09, 2010, 07:37:42 AM

... 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

ribuck

donator

Activity: 826

Merit: 1039

Quote from: ptd on December 09, 2010, 07:37:42 AM

... 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

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: ptd on December 09, 2010, 07:37:42 AM

Quote from: davout on November 25, 2010, 10:59:52 AM

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

ptd

member

Activity: 114

Merit: 10

Quote from: davout on November 25, 2010, 10:59:52 AM

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 .

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: davout on November 25, 2010, 10:59:52 AM

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.

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: wumpus on November 25, 2010, 10:17:42 AM

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

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: davout on November 25, 2010, 10:01:08 AM

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

davout

legendary

Activity: 1372

Merit: 1007

1davout

Quote from: wumpus on November 25, 2010, 09:43:36 AM

Quote from: davout on November 25, 2010, 09:40:41 AM

A really sweet thing would be the client storing its data in a MySQL DB

Wouldn't that open a full can of worms about database support? A wants MySQL, B wants PostgresSQL, C wants Oracle, D wants some NoSQL thingy. And then the dev team will spend all their time with yet another database wrapper.

IMO, it would be better to keep the client self-contained (which can be done with BDB that is used now) and as small as possible. All queries can be done through JSONRPC. Why would you need SQL?

I think I opened a can of worms suggesting that Cheesy

Also,

Quote from: wumpus on November 25, 2010, 09:43:36 AM

~~All~~ some queries can be done through JSONRPC. Why would you need SQL?

I'm ok with the client being self contained, if i really need to go read the DB I'll find myself a nice little BerkeleyDB wrapper Cheesy

On a side note, I'm really curious about how blocks and transactions are uniquely identified inside the client, through their hashes ?
They're not guaranteed to be unique, and, over the course of time I think it's almost certain collisions will happen. I was wondering about that when asking myself what column to use for primary key...

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Yeah, it's also a matter of documenting and specifying the protocol.

If that were documented, people could write their own clients in Python, PHP, Java, etc with their own database backends and fun. The official reference implementation could remain simple, small, optimized, without too much abstraction layers and dependencies.

Then again, it seems that bitcoind is still in a state of flux and unstable, so doing that now will be aiming for a moving target.

Topic: Accounts: svn rev 188 (JSON-RPC API changes) (Read 7947 times)