Bitcoin Forum
December 06, 2016, 04:14:54 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Accounts: svn rev 188 (JSON-RPC API changes)  (Read 7094 times)
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
November 25, 2010, 02:17:42 PM
 #21

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 Smiley




Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
1481040894
Hero Member
*
Offline Offline

Posts: 1481040894

View Profile Personal Message (Offline)

Ignore
1481040894
Reply with quote  #2

1481040894
Report to moderator
1481040894
Hero Member
*
Offline Offline

Posts: 1481040894

View Profile Personal Message (Offline)

Ignore
1481040894
Reply with quote  #2

1481040894
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481040894
Hero Member
*
Offline Offline

Posts: 1481040894

View Profile Personal Message (Offline)

Ignore
1481040894
Reply with quote  #2

1481040894
Report to moderator
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
November 25, 2010, 02:59:52 PM
 #22

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 Smiley

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
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
November 25, 2010, 03:10:40 PM
 #23

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 Smiley The only sure thing is that strictly incrementing sequential keys seem to be a dying breed.



Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
ptd
Member
**
Offline Offline

Activity: 114


View Profile
December 09, 2010, 11:37:42 AM
 #24

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
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 09, 2010, 12:44:13 PM
 #25

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 Smiley

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
December 09, 2010, 01:11:20 PM
 #26

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

Activity: 1358


1davout


View Profile WWW
December 09, 2010, 01:13:42 PM
 #27

... 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
Newbie
*
Offline Offline

Activity: 8


View Profile
December 10, 2010, 06:00:08 AM
 #28

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 10, 2010, 12:49:35 PM
 #29

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.

How often do you get the chance to work on a potentially world-changing project?
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 10, 2010, 01:24:37 PM
 #30

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
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 10, 2010, 01:40:03 PM
 #31

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.

How often do you get the chance to work on a potentially world-changing project?
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
December 10, 2010, 01:55:37 PM
 #32

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

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 10, 2010, 01:57:10 PM
 #33

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 Smiley

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
Member
**
Offline Offline

Activity: 110


View Profile
December 10, 2010, 10:58:40 PM
 #34

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
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW
December 10, 2010, 11:28:06 PM
 #35

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.

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 11, 2010, 04:09:00 AM
 #36

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!

How often do you get the chance to work on a potentially world-changing project?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 11, 2010, 04:15:50 AM
 #37

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

How often do you get the chance to work on a potentially world-changing project?
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 11, 2010, 01:10:30 PM
 #38

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!

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!