Bitcoin Forum
March 28, 2024, 09:29:44 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 [All]
  Print  
Author Topic: Single address accounts  (Read 2089 times)
codemojo (OP)
Jr. Member
*
Offline Offline

Activity: 35
Merit: 4


View Profile
July 11, 2011, 12:07:53 AM
 #1

Hi,

suppose there was an online wallet service with a patched version of the official client:

The patch would:
- prevent the client to generate a new address every time it needs to put the money change somewhere
- instead, it would always put the change back to the source address

The benefit would be for the users to be able to check their total balance by simply checking their address on blockexplorer.

My question is, would this have any serious drawbacks, other than loss of anonimity?
1711661384
Hero Member
*
Offline Offline

Posts: 1711661384

View Profile Personal Message (Offline)

Ignore
1711661384
Reply with quote  #2

1711661384
Report to moderator
1711661384
Hero Member
*
Offline Offline

Posts: 1711661384

View Profile Personal Message (Offline)

Ignore
1711661384
Reply with quote  #2

1711661384
Report to moderator
1711661384
Hero Member
*
Offline Offline

Posts: 1711661384

View Profile Personal Message (Offline)

Ignore
1711661384
Reply with quote  #2

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

Posts: 1711661384

View Profile Personal Message (Offline)

Ignore
1711661384
Reply with quote  #2

1711661384
Report to moderator
1711661384
Hero Member
*
Offline Offline

Posts: 1711661384

View Profile Personal Message (Offline)

Ignore
1711661384
Reply with quote  #2

1711661384
Report to moderator
patvarilly
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
July 11, 2011, 12:21:01 AM
 #2

My question is, would this have any serious drawbacks, other than loss of anonimity?

The current system of change isn't even very anonymous to begin with.  Take a look at any block in blockexplorer, and you'll find that it's terribly easy in most cases to pick out, with reasonable certainty, which output is change and which is a real transfer from A to B.  I've boiled it down to a set of three rules that work almost all of the time here: https://forum.bitcoin.org/index.php?topic=27472.msg346658#msg346658.  It's only a matter of time before somebody puts together an alternative block explorer that works around the supposed anonymity of "change" being sent to a new address.
davux
Sr. Member
****
Offline Offline

Activity: 288
Merit: 263


Firstbits.com/1davux


View Profile WWW
July 11, 2011, 12:39:55 AM
 #3

Should the title be "single address wallets" instead, or would multiple-account wallets with single-address accounts work with your idea?

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
codemojo (OP)
Jr. Member
*
Offline Offline

Activity: 35
Merit: 4


View Profile
July 11, 2011, 12:42:26 AM
 #4

Should the title be "single address wallets" instead, or would multiple-account wallets with single-address accounts work with your idea?

Yeah, the idea is to have one wallet with multiple "accounts", as the client calls them. And only one address per account.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 05:44:00 AM
 #5

Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use.  We don't think that our current systems have any serious weaknesses in this department, but virtually every cryptosystem in history has been weakened and then broken because keys were used multiple times.

Best practice for security: use each key once, and only once.
Not best practice, but still pretty good: allow multiple uses, but discourage.
Worst practice: design a system that keeps using one key over and over and over again.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416
Merit: 277


View Profile
July 11, 2011, 01:27:31 PM
 #6

Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use.

Such concerns are not relevant for the security of modern cryptosystems. In particular, public key cryptography relies on the public key being published and used multiple times. Please cite any modern technical publications which claim otherwise.

Codemojo's scheme is simple, viable and secure.

ByteCoin
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 02:12:06 PM
 #7

Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use.

Such concerns are not relevant for the security of modern cryptosystems. In particular, public key cryptography relies on the public key being published and used multiple times. Please cite any modern technical publications which claim otherwise.

Codemojo's scheme is simple, viable and secure.

I already said that we don't think the our modern systems have this problem, but every other PK cryptosytem goes to great lengths to minimize usage of the actual private key, just in case.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 11, 2011, 02:31:34 PM
 #8

I already said that we don't think the our modern systems have this problem, but every other PK cryptosytem goes to great lengths to minimize usage of the actual private key, just in case.
Bitcoin only uses the actual private key when something has to be signed to prove it was generated by the owner of that private key. I can't imagine how you could minimize it further or why you would want to.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
bitlotto
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500


BitLotto - best odds + best payouts + cheat-proof


View Profile WWW
July 11, 2011, 02:48:22 PM
 #9

I was thinking that perhaps in the future it becomes plausible to brute force some keys. When it occurs it could be some time to switch to different encryption. So if it took say 100,000 USD of computer resources to brute force an address and **IF** Cheesy I was a Bitcoin millionaire I'd rather having many addresses with 1,000 than 1 with a million. 

*Next Draw Feb 1*  BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR
TOR2WEB
Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 03:13:35 PM
 #10

I already said that we don't think the our modern systems have this problem, but every other PK cryptosytem goes to great lengths to minimize usage of the actual private key, just in case.
Bitcoin only uses the actual private key when something has to be signed to prove it was generated by the owner of that private key. I can't imagine how you could minimize it further or why you would want to.

You minimize it further by not needing to sign multiple transactions with the same key.

Again, I'm not saying that an attack is likely from this direction, I'm just saying that key reuse is considered harmful in general, and should be minimized unless there is a very compelling reason.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
imperi
Full Member
***
Offline Offline

Activity: 196
Merit: 101


View Profile
July 11, 2011, 03:26:44 PM
 #11

Pick up any book on cryptography, open it to any page, stab your finger into any paragraph, and you will find a warning about key re-use.  We don't think that our current systems have any serious weaknesses in this department, but virtually every cryptosystem in history has been weakened and then broken because keys were used multiple times.

Best practice for security: use each key once, and only once.
Not best practice, but still pretty good: allow multiple uses, but discourage.
Worst practice: design a system that keeps using one key over and over and over again.

What if we don't care about secrecy with transactions?
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 03:45:29 PM
 #12

What if we don't care about secrecy with transactions?

Secrecy isn't the issue.  The issue is attackers gradually learning bits of your private key.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 04:02:25 PM
 #13

What if we don't care about secrecy with transactions?

Secrecy isn't the issue.  The issue is attackers gradually learning bits of your private key.
an attacker is learning nothing, that the whole point of publickey-cryptography.

go look it up on Wikipedia, before talking about anything you don't know anything about.
or go read some bruce schneier, he have made a good heavy book, about cryptography.
(you know the big red one, with a ufo on the front)

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 04:43:26 PM
 #14

I've read it, thanks.

You may want to flip through it again so that you can see how every other cryptosystem other than bitcoin takes great pains to minimize and obfuscate use of the private key, and how every PKI system in the world, again not counting bitcoin, insists on using expiration dates for keys.

Bitcoin private keys have no expiration date, and are used to sign plaintexts that are partially repetitive and predictable.  If these factors don't make your sphincter tighten, you missed some big lessons from the history of cryptanalysis.

We can't expire keys, and we can't compress ( =randomize) scripts.  The one thing that we do is discourage key re-use.  We should not abandon the one good practice that we are capable of doing without a damn good reason, even though we are pretty confident that we are safe doing so.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 05:51:26 PM
 #15

Quote
I've read it, thanks.
you does not sound like you have.

Quote
You may want to flip through it again so that you can see how every other cryptosystem other than bitcoin takes great pains to minimize and obfuscate use of the private key, and how every PKI system in the world, again not counting bitcoin, insists on using expiration dates for keys.
example please.

Quote
Bitcoin private keys have no expiration date, and are used to sign plaintexts that are partially repetitive and predictable.  If these factors don't make your sphincter tighten, you missed some big lessons from the history of cryptanalysis.
LOL! expiration date! the only reason for them is for 512 bit RSA keys, and for CAs to earn money.

512bit RSA was secure in 1990 and broken(practicaly) in 1999.
samething thing now:
bitcoin private keys today are secure. in 10 years they may not be.

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

it has nothing to do with key reuse.

Quote
We can't expire keys, and we can't compress ( =randomize) scripts.
which is good.

Quote
The one thing that we do is discourage key re-use.  We should not abandon the one good practice that we are capable of doing without a damn good reason, even though we are pretty confident that we are safe doing so.
Abandon good practice? did you ever hear of X.509?
i would like to abandon it, as fast as possible.


"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
codemojo (OP)
Jr. Member
*
Offline Offline

Activity: 35
Merit: 4


View Profile
July 11, 2011, 05:56:10 PM
 #16

We can't expire keys, and we can't compress ( =randomize) scripts.  The one thing that we do is discourage key re-use.  We should not abandon the one good practice that we are capable of doing without a damn good reason, even though we are pretty confident that we are safe doing so.

Thanks for your insight, very interesting. The way I see it now is, if the person holding the single-address account doesn't care that much about his money being stolen (like maybe he only keeps small amounts there), then this approach would be sane. I mean, I'm mostly concerned about this patch having a negative impact on some other unrelated bitcoin user, or the network as a whole. For example, could this behavior make another user less anonymous, or make some other client break (because there is a direct cycle - an input is the same as an output), etc...
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 06:21:30 PM
 #17

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
dinox
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
July 11, 2011, 06:58:29 PM
 #18

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.

Dude. Bitcoin never encrypts anything with the user's private key. Never.

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 07:09:53 PM
 #19

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.
partly true.

but it is used(to sign) in the key-exchange protocol, to prevent a 3. party for modifying the protocol messages.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 07:15:17 PM
 #20

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.

Dude. Bitcoin never encrypts anything with the user's private key. Never.

Like the signature?  Are you going to quibble that the ECDSA step isn't technically an encryption because it can't be reversed?

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 07:25:06 PM
 #21

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.
partly true.

but it is used(to sign) in the key-exchange protocol, to prevent a 3. party for modifying the protocol messages.

No, it isn't.  In SSL, the client encrypts the premaster secret (a number used to derive the symmetric session key) using the server's public key.  The server decrypts it using the private key.  At no time does the server ever emit anything directly derived from its private key.

SSL uses symmetric encryption for the payload.  PKC is only used to securely exchange that session key, and the entire exchange protocol was designed to protect the server's private key from re-use.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 07:27:37 PM
 #22

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.
LOL! TROLL!

then what is it used for, please enlighten us with your superior knowledge.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 07:31:29 PM
 #23

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.
LOL! TROLL!

then what is it used for, please enlighten us with your superior knowledge.

Already answered in the post just above yours.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 07:43:32 PM
 #24

on a busy SSL server, things gets signed and encrypted, 1000 times per second. with the same 1024/2048 bit key. they are not broken (yet).

Dude.  SSL never encrypts anything with the server's private key.  Never.
partly true.

but it is used(to sign) in the key-exchange protocol, to prevent a 3. party for modifying the protocol messages.

No, it isn't.  In SSL, the client encrypts the premaster secret (a number used to derive the symmetric session key) using the server's public key.  The server decrypts it using the private key.  At no time does the server ever emit anything directly derived from its private key.

SSL uses symmetric encryption for the payload.  PKC is only used to securely exchange that session key, and the entire exchange protocol was designed to protect the server's private key from re-use.
the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 08:07:41 PM
 #25

the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.

Reference?

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 08:17:32 PM
 #26

the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.

Reference?
http://www.ietf.org/rfc/rfc5246.txt

p. 91-92
F.1.1.3.  Diffie-Hellman Key Exchange with Authentication

Quote
When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSA or RSA certificate.

also every certificate is signed by an CA.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
July 11, 2011, 08:42:46 PM
 #27

the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.

Reference?
http://www.ietf.org/rfc/rfc5246.txt

p. 91-92
F.1.1.3.  Diffie-Hellman Key Exchange with Authentication

Quote
When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSA or RSA certificate.

also every certificate is signed by an CA.

I stand corrected.  SSL implementations that ignore all the SHOULDs and warnings in that section do actually have the option to use their private keys directly.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 09:01:05 PM
 #28

the client can often force a DH key-agreement to happen. it requires the server to sign with the private key.

Reference?
http://www.ietf.org/rfc/rfc5246.txt

p. 91-92
F.1.1.3.  Diffie-Hellman Key Exchange with Authentication

Quote
When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSA or RSA certificate.

also every certificate is signed by an CA.

I stand corrected.  SSL implementations that ignore all the SHOULDs and warnings in that section do actually have the option to use their private keys directly.
apache has it enabled by default.
it only requiers the client to only allows DH in the ClientHello message, and the server supports DH.

anyway it does not matter. signatures are useless for the propose of getting information about the private key.
signatures only gives proof that the other party have access the the private key.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
ampkZjWDQcqT
Member
**
Offline Offline

Activity: 70
Merit: 10


GNU is not UNIX


View Profile
July 11, 2011, 09:46:30 PM
 #29

[...]

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.

If not to perform cryptographic operations, what do you think it's the purpose of a cryptographic key?.

If you found my comment useful please express your gratitude by doing an action of similar magnitude towards a better society. Thanks you!.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
July 11, 2011, 09:57:39 PM
 #30

[...]

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.

If not to perform cryptographic operations, what do you think it's the purpose of a cryptographic key?.

hey! don't step on him!

he said:
client gets the server cert.
the client encrypts a random key he/she choses, with the public key from the cert.
and sends it to the server.

the server decryptes the random key
the server responses with an encrypted message, to proof that he/she knows the private key.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Pages: 1 2 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!