Topic: Sending private keys instead of transactions (Read 3188 times)

Those that are designated "strange" in block explorer. 

What we need is a bitcoin client that can support multiple, possibly "tainted" wallets. "Tainted" wallets should be transferred to a new wallet as soon as possible. The bitcoin client should also let you choose which wallet you move the funds to. Any encryption should be set on a per-wallet basis.

OK, could be interesting.  But can you give an example of one of the strange transactions?

I really like your ideas. I was thinking about things like the geocaching idea before. The major problem at the moment is the difficulty of importing the keys back into the bitcoin client. I was mulling over some ideas in this thread and I think that putting some Bitcoin in a newly created instawallet and then giving that instawallet address to the recipient, whether as straight text url or a QR code that can be scanned into a smart phone,  may allow you to achieve some of the above applications (assuming you trust instawallet).

That's the point. If.

Currently, it looks like, there are three types of transactions. People using the satoshi client, special institutions like miners, Mt Gox, exchanges and stuff - and a rest consisting of "strange" transactions directly fed into the system.

I am not interested in what could be done with the current system but what IS done with it. I have not yet reached all conclusions, but you can see quite a bit more in network analysis than I feel comfortable with. That's why I am concerned.

I hope, if I have a bit of time and in a few weeks, I can be more specific.

If you do it like that, where is the advantage? Who cares whether Alice or Bob starts the transaction?

If Bob creates a fresh address and Alice sends money to it, nobody is going to know it's Bob's address until he associates himself with it.  He could create it offline and it could never have been seen by the network.  You already can't get more anonymous than that and there is no need for Alice to know the PK. Whatever you do, though it can be made obscure, the transaction will be somehow linked to Alice through the exchange records. 

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.

Great idea, casascius.


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.

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

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.

Same thing as a Bitbill, without the paper.

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.

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.

Nice idea !


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.

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. 

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.


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.


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 

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. 

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.