Sending private keys instead of transactions

[Forp]

Maybe this has a stupid drawback or has already been discussed - but let me just put a thought on the board for discussion.

Currently we send money by sealing transactions in a block chain. This approach is higzhly susceptible to network analysis attacks. Although the bitcoin addresses are pseudonyms, all transactions are public and you can follow payment streams. I am currently doing some analyses here, but that's a different story.

Now, suppose we did different:

Alice wants to send 5 BTC to Bob. So she prepares a fresh bitcoin address, posts 5 BTC to this address and sends the private key [sic] for the address to Bob. Now, Bob can use this private key for spending this money.

Wait a minute, how can Bob be sure that Alice isn't using his money before he is. Well, this is a non-problem. Even in the traditional bitcoin protocol Bob has to wait some time until the transaction is cleared. So, in this case, Bob just uses the money to move it to yet another bitcoin address and waits until this transaction clears out. So there is no difference in this regard, but there is an important advantage: An attacker can no longer make the assumption that one bitcoin address corresponds to one person. Now, let's make it even worse for the analyst: Every 2 hours alice generates a new bitcoin address and shuffles here money from her old addresses to her new addresses. One in a while she buys merchandise from Bob and in this case she just forwards Bob the current private keys and Bob continues this address shuffling.

So...just think of bit coins to be private keys to addresses and no longer money attached to addresses, Conceptually, this becomes a different world.

And, voila, bitcoin now is really anonymous.

Feedback?

[1714193134]

1714193134

[1714193134]

1714193134

[1714193134]

1714193134

[CydeWeys]

I don't see any possible advantages here?  If you ever received a private key from someone as payment, the very first thing you would do is generate a transaction to send all the coins from that private key to one of your own addresses that you know no one else has access to.  So any time money is transferred between two people you'd have to (a) send the private key and then (b) do a transaction to a non-shared address.  Just doing a normal transaction from the get-go is simpler.

[DamienBlack]

The problem with sending a private key is that you don't know that the sender has destroyed his copy. So to be safe you would have to transfer the bitcoins to a different key anyway.

[bcearl]

Welcome back, double spending!


What was the whole point of Bitcoin, the thing that has never been achieved before? I forgot.

[JoelKatz]

Advantage: The exact same number of bitcoins can change hands any number of times without any record in the public block chain.

Disadvantage: The person who is the rightful holder of the bitcoins can be screwed at any time by anyone in the chain before him. To avoid this disadvantage, he has to put a transfer in the public block chain, negating the advantage.

Analysis: Non-starter.

[casascius]

Advantage: The exact same number of bitcoins can change hands any number of times without any record in the public block chain.

Disadvantage: The person who is the rightful holder of the bitcoins can be screwed at any time by anyone in the chain before him. To avoid this disadvantage, he has to put a transfer in the public block chain, negating the advantage.

Analysis: Non-starter.

Between trusted parties however, there's an advantage in that bitcoins can be transferred without a computer.  That's a huge advantage, it makes them within reach of more people, and that's a huge problem right now - many people who wouldn't mind owning a few bitcoins "for fun" get turned off by the idea of having to download a program or take a risk of getting hacked.

The local pawnshop, run by a completely computer-illiterate dude, could sell pre-made envelopes with 10 BTC in them for cash, prepared by someone else he trusts.  Or BitBills, with a human-readable private key instead of QR code.  He already deals in silver and gold, so the idea of looking up a current exchange rate isn't beyond his skill set.

Each BTC package contain a private key.  Maybe the Silk Road accepts private keys and the customer wants to score.  Sure, the pawnshop could steal the coins back from their own customer, but you can only do that so many times IRL before you get your ass kicked.  The recourse, in this case, is a practical one, rather than technical.

[Forp]

So any time money is transferred between two people you'd have to (a) send the private key and then (b) do a transaction to a non-shared address.  Just doing a normal transaction from the get-go is simpler.

This would be done automatically by a client(extension), so no additional work.

Advantage is that an attacker has MUCH more difficult task when tracing payments.

[Forp]

So to be safe you would have to transfer the bitcoins to a different key anyway.

Of course. That was an essential part of the procedure.

If the client does so for me automagically, it makes no difference for the user - but provides more anonymity.

[Forp]

Welcome back, double spending!

No. The difference is just the moment in the protocol where this is prevented.

Suppose Alice double spends a coin to Bob and Carol in the traditional Bitcoin protocol. Where will this be found? When forming and stabilizing the block chain, so Bob will know some 20 - 25 minutes later. Therefore, Bob will wait 20 - 25 minutes to make sure, everything is fine.

Now have a look at the proposal. Suppose Alice keeps a copy of the private key. Alice sends the private key to Bob. In order to make sure the money is his Bob immediately uses the private key to forward the money to a fresh address where he is the only one to have access to. Suppose Alice tries to cheat by transfering the money before Bob has done so. Bob will know 20 - 25 minutes later.

So in both cases Bob will wait some 20 - 25 minutes later.

Welcome back careful reading of forum proposals. 

[Forp]

Advantage: The exact same number of bitcoins can change hands any number of times without any record in the public block chain.

Not the only advantage.

Right now you can do pretty much of somce decent network analysis just by following payment patterns. You can safely assume that one bitcoin address is one person.

In the new pattern it means that a bitcoin address can be two persons.

Once you have realized the mechanism, you can easily extend the scheme: Bob receives the private keys and immediately passes them on to Carol for one of his payments (can be done by a bot automatically). So one key / address could belong to 10 persons or more. it just means a bit more of patience for the block chain to settle.

Disadvantage: The person who is the rightful holder of the bitcoins can be screwed at any time by anyone in the chain before him. To avoid this disadvantage, he has to put a transfer in the public block chain, negating the advantage.

I always can be screwed at any time by anyone in the chain before me. Always. The only thing which protects me is a bit of patience, waiting for the transaction to "sink in" deep enough in the block chain. So, I will always wait a number of blocks before assuming that a payment has been made.

We can pass the private key of an address along, to two, three, four, five people and more. Then, before sending the merchandise I have to check if all these facts are confirmed by the block chain. It's just as in consensus protocols: Being a bit patient and not always insisting on a pessimistic protocol can pay off one in a while.

It is just a trade-off between waiting time, security and privacy. If we wait long enough the proposed variant still is secure, but it certainly offers more privacy.

Analysis: Non-starter.

Yes? You can find out very interesting things with a network analysis of the block and transaction chain. I would not bet on bitcoin privacy without protocol amendmendts 

[aral]

I don't see any anonymity here.  Alice receives the BTC from teh exchange on address A1.  She transfers from A1 to A2, sends the private key to Bob who can then transfer from A2 to B1 and then, to the exchange through an address B2 that is tied to him.  So there is still a link between Alice and Bob. 

[Forp]

The local pawnshop, run by a completely computer-illiterate dude, could sell pre-made envelopes with 10 BTC in them for cash, prepared by someone else he trusts.  Or BitBills, with a human-readable private key instead of QR code.  He already deals in silver and gold, so the idea of looking up a current exchange rate isn't beyond his skill set.

Nice idea !

The recourse, in this case, is a practical one, rather than technical.

Exactly.

Moreover: It speeds up turn around of bitcoin.

Alice spend 2 BTC to Bob by passing the private key of her 2 BTC address. Bob sends them to Carol. Carol to Daniel. Daniel to Eve. And Eve finally to Oscar.

This all is done without any checking, waiting for a new block or two or three to be generated. It is very fast and accomplished within 2 minutes.

In the mean time, Bob starts to get those new socks ready for shipping to Alice, Carol gets those pens reads for shipping to Daniel and so on. And, before they ship, they all check the block chain. They have to wait for two or three blocks anyhow.

An external observer doing network analysis just sees the money vanishing from Alicens address and he sees the money popping up at Oscar's address. The observer will even have the IP addresses of Alice and of Oscar. But the people in between, Bob, Carol, Daniel and Eve exchange their informaiton just by passing the private key in PGPencrypted email - they are completely protected from every kind of monitoring whatsoever.

[Forp]

Alice receives the BTC from teh exchange on address A1.  She transfers from A1 to A2, sends the private key to Bob who can then transfer from A2 to B1 and then, to the exchange through an address B2 that is tied to him.  So there is still a link between Alice and Bob. 

Alice sends the private key to Bob using Tor or i2p or whatever. Nobody sees this. If there are intermediaries (such as in my last posting) it gets just better. Think of it as a remixing cascade for bitcoins, if you wish.

If Alice uses the bitcoin client to send money to Bob, everyone sees it in blockexplorer.

[bitlotto]

It's great when the sender doesn't care who receives it:

-key written on something and given to a winner at a party
-physically giving someone a pre-loaded account they can use
-geo caching - rather than leaving usb sticks or whatever all you do is write down the code
-scratchcards
-you could even have meet-ups where everyone gets a card where inside everyone has a code. Some are worth 0.01 some are worth 1. It would be kind of fun to use.

I think it's useful when you want to exchange value in a non-digital way.

For example. I don't care what happens to 0.05 BTC here:
1GX4zUSao2YDy2k6YdWqoHVhT4C66AGnxh (it will be there soon)
Whoever spends it first using this private key:
5Hri33arpk1BmhDaHwJw8HiwzTxi9PWtidTWBhCEBuEtHgDcVJM
Gets it.

Key's made with my BOTG script.

[befuddled]

Same thing as a Bitbill, without the paper.

[MoonShadow]

Feedback?

A future feature that would allow a person to 'withdraw' a particular public/private keypair from their wallet.dat and use that as cash directly has been discussed.  The problem is only when the receiver doesn't trust the sender.  Bitbills are based upon this concept.  This is also somewhat how an online wallet service such as Mybitcoin.com works, as the funds sent to your receiving address are almost certainly not going to be used by yourself.  Thus, an online wallet service adds to the anonimity of the group.  The problem with such online wallet services is that, because this kind of service requires a large group to contribute meaningfully to anonimity, the wallet service then becomes a primary target for government leverage to be applied.  But what if such a wallet service were to pop up that was, itself, anonymous.  Such as on Tor as a hidden service, with no connections to real world individuals.  Well, the trust level would necessarily be lower, due to the fact that if someone were to steal the coins, including the site owner, there would be even less recourse for users to pursue the thief than there is with regard to MtGox.  Still, I could imagine myself putting small sums into such a service, risk of theft would still be a limiting factor.

[JoelKatz]

This could work if a trusted party sealed private keys inside a tamper-evident holder. They could print the denomination where it's visible and seal the private key where you have to break the holder open to get to it. I seem to remember somebody already doing this for Bitcoins.

So if I want to give you 5 BTC in person, I could hand you a 5 BTC note. You can exchange the physical note with someone else if you want. If you want to redeem the note's Bitcoins, you simply rip it open to extract the private key. I'd put the private key both in text and as a QR code. You'd need to make sure it was effectively impossible to extract the private key without physically damaging the note.

Update: Yep, that's exactly what Bitbills are, like to the last detail. Awesome. (Except I didn't think to print the card's address where it's visible without opening it. That's even more awesome.)

[casascius]

A future feature that would allow a person to 'withdraw' a particular public/private keypair from their wallet.dat and use that as cash directly has been discussed.  The problem is only when the receiver doesn't trust the sender.  Bitbills are based upon this concept.  This is also somewhat how an online wallet service such as Mybitcoin.com works, as the funds sent to your receiving address are almost certainly not going to be used by yourself.  Thus, an online wallet service adds to the anonimity of the group.  The problem with such online wallet services is that, because this kind of service requires a large group to contribute meaningfully to anonimity, the wallet service then becomes a primary target for government leverage to be applied.  But what if such a wallet service were to pop up that was, itself, anonymous.  Such as on Tor as a hidden service, with no connections to real world individuals.  Well, the trust level would necessarily be lower, due to the fact that if someone were to steal the coins, including the site owner, there would be even less recourse for users to pursue the thief than there is with regard to MtGox.  Still, I could imagine myself putting small sums into such a service, risk of theft would still be a limiting factor.

I had an idea of how this could work effectively with no trust needed, no risk of theft, only minimal trust required that the person running the anonymizer won't "out" you.

Suppose 100 people wanted all their coins anonymized at a pre-determined time next Saturday, and ran an open-source anonymizer client that could peek in their wallet.dat and sign transactions proposed by the server.

The server's job is to coordinate all 100 of these clients to simultaneously mix-in and mix-out their coins into a single gigantic transaction.

Come that time on Saturday, each of those 100 clients identifies, to the server, the transaction inputs they intend to anonymize.  Each of those 100 clients also generates a bunch of spare receiving addresses so they can get their coins back, and sends those to the server too.  (No private keys nor signatures are shared).

The server constructs one HUGE transaction that combines all the funds from everybody seeking anonymity.  It then, in random order and in the same transaction, spends the funds back out to the spare addresses provided by the clients, always in fixed denominations example: (50 BTC, 25, 10, 5, 1, .5, .1, .05, .01 etc), and only one output per address.  Now the catch is, the server doesn't have any private keys and can't sign this transaction, it can only propose it to the clients.

So the server proposes this monster transaction to each of those 100 clients.  The clients automatically look at it and make sure they are not being cheated, that every spend they are authorizing is balanced by incoming coins to the spare addresses.  When all clients concur, they all produce the signatures needed.  If all of the clients sign off on the transaction, the server packages it into a complete transaction and it's sent to the p2p network and block chain and the Saturday party is then over.

If not all the clients sign off (e.g. suppose 3 of them got disconnected), then the transaction is forgotten and the process is repeated with the remaining 97 clients.  Importantly, new destination addresses are selected and the outputs rescrambled so as to minimize any attack advantages from comparing the proposals.  If the server is unable to get signatures from all clients, the offending clients are removed and the proposal process repeats in a loop until eventually a full consensus of signatures is achieved on the remaining activity.

Once done, anonymized funds can clearly be traced back to the anonymizing transaction, but no further.

It would be impossible for anyone to connect the input amounts with the outputs.  For example, someone sending 444.13 BTC into the anonymizer would receive outputs of 50, 50, 50, 50, 50, 50, 50, 50, 25, 10, 5, 1, 1, 1, 1, .1, .01, .01, .01... to nineteen different addresses... all of which would be randomly jumbled up with hundreds or thousands of other outputs in the exact same denominations.

If these anonymizing transactions were only done once every Saturday, they would result in a significantly large pot, as compared with daily frequency or greater.  When mixed, all coins coming out of the pot are completely indistinguishable from one another, perhaps almost as good as freshly mined coins if the pot is large enough.

[johanatan]

Great idea, casascius.

If not all the clients sign off (e.g. suppose 3 of them got disconnected), then the transaction is forgotten and the process is repeated with the remaining 97 clients.  Importantly, new destination addresses are selected and the outputs rescrambled so as to minimize any attack advantages from comparing the proposals.  If the server is unable to get signatures from all clients, the offending clients are removed and the proposal process repeats in a loop until eventually a full consensus of signatures is achieved on the remaining activity.

I would suggest enforcing a lower bound here.  Either X% of original clients remain or Y% of original funds committed, etc.  Would probably never happen in practice and I suppose that even if it did happen there'd be no danger except the remaining clients leaving with a higher expectation of anonymity than they should.

[MoonShadow]

A future feature that would allow a person to 'withdraw' a particular public/private keypair from their wallet.dat and use that as cash directly has been discussed.  The problem is only when the receiver doesn't trust the sender.  Bitbills are based upon this concept.  This is also somewhat how an online wallet service such as Mybitcoin.com works, as the funds sent to your receiving address are almost certainly not going to be used by yourself.  Thus, an online wallet service adds to the anonimity of the group.  The problem with such online wallet services is that, because this kind of service requires a large group to contribute meaningfully to anonimity, the wallet service then becomes a primary target for government leverage to be applied.  But what if such a wallet service were to pop up that was, itself, anonymous.  Such as on Tor as a hidden service, with no connections to real world individuals.  Well, the trust level would necessarily be lower, due to the fact that if someone were to steal the coins, including the site owner, there would be even less recourse for users to pursue the thief than there is with regard to MtGox.  Still, I could imagine myself putting small sums into such a service, risk of theft would still be a limiting factor.

I had an idea of how this could work effectively with no trust needed, no risk of theft, only minimal trust required that the person running the anonymizer won't "out" you.

Suppose 100 people wanted all their coins anonymized at a pre-determined time next Saturday, and ran an open-source anonymizer client that could peek in their wallet.dat and sign transactions proposed by the server.

The server's job is to coordinate all 100 of these clients to simultaneously mix-in and mix-out their coins into a single gigantic transaction.

Come that time on Saturday, each of those 100 clients identifies, to the server, the transaction inputs they intend to anonymize.  Each of those 100 clients also generates a bunch of spare receiving addresses so they can get their coins back, and sends those to the server too.  (No private keys nor signatures are shared).

The server constructs one HUGE transaction that combines all the funds from everybody seeking anonymity.  It then, in random order and in the same transaction, spends the funds back out to the spare addresses provided by the clients, always in fixed denominations example: (50 BTC, 25, 10, 5, 1, .5, .1, .05, .01 etc), and only one output per address.  Now the catch is, the server doesn't have any private keys and can't sign this transaction, it can only propose it to the clients.

So the server proposes this monster transaction to each of those 100 clients.  The clients automatically look at it and make sure they are not being cheated, that every spend they are authorizing is balanced by incoming coins to the spare addresses.  When all clients concur, they all produce the signatures needed.  If all of the clients sign off on the transaction, the server packages it into a complete transaction and it's sent to the p2p network and block chain and the Saturday party is then over.

If not all the clients sign off (e.g. suppose 3 of them got disconnected), then the transaction is forgotten and the process is repeated with the remaining 97 clients.  Importantly, new destination addresses are selected and the outputs rescrambled so as to minimize any attack advantages from comparing the proposals.  If the server is unable to get signatures from all clients, the offending clients are removed and the proposal process repeats in a loop until eventually a full consensus of signatures is achieved on the remaining activity.

Once done, anonymized funds can clearly be traced back to the anonymizing transaction, but no further.

It would be impossible for anyone to connect the input amounts with the outputs.  For example, someone sending 444.13 BTC into the anonymizer would receive outputs of 50, 50, 50, 50, 50, 50, 50, 50, 25, 10, 5, 1, 1, 1, 1, .1, .01, .01, .01... to nineteen different addresses... all of which would be randomly jumbled up with hundreds or thousands of other outputs in the exact same denominations.

If these anonymizing transactions were only done once every Saturday, they would result in a significantly large pot, as compared with daily frequency or greater.  When mixed, all coins coming out of the pot are completely indistinguishable from one another, perhaps almost as good as freshly mined coins if the pot is large enough.

This is an awesome idea, but pretty much requires that users produce a clean second wallet so that it's not possible for their original wallet to mix the clean coins back into the unclean transactions.  The downside would be that it would be impossible to obscure the intent to launder coins.