Topic: Idea-improving btc fungibility (Read 1952 times)

Me baffled.
And anxious to see what you've been working on.

Good find. The beat goes on ...

Alternate protocols do not hurt Bitcoin as Bitcoin can evolve and incorporate these new ideas. Bitcoin value lies on the community size, not on the protocol itself.

Wow!

I really hope that your ideas can also be ported to the actual Bitcoin protocol

I'm working on a cryptocurrency where miners mix transactions without the need of private keys. I use something like universal re-encryption and a new cryptographic construct that I called "Trapdoor Shuffles".

Also the coin allows coin subdivision and combination without disclosing the amounts (I think it's the first e-cash system with this property).

I will post the paper when it's ready. It already has a name: PAPCash (Practical Anonymous Peer-to-peer e-cash)

Bye! Sergio.

Any news about this topic?

They were talking about it also here:
http://sourceforge.net/mailarchive/forum.php?thread_name=CACsn0cm6wgPdNvVr6Q4yS%2BcGP-kpUJxtXsL1mZS502UTOx8t0g%40mail.gmail.com&forum_name=bitcoin-development

Hmmm, I think you could use blind signing for doing something like this ....

There is also this post by Watson Ladd that claims to have a scheme to include a blinding signature into the protocol with new script OP 'SIG_FUNGIBLE'

http://wbl.github.com/bitcoinanon.pdf

would be interested to get some thoughts on that, and the general question "Can the Bitcoin protocol be made more untraceable (fungibililty improved)?"

Take a look at this post about oblivious mixing transactions.

You don't send the private keys, you signed the transaction created by the server, just like a lightweight client.

let's assume that user A wants to send money to address A1 and A2(change).
user B sends to B1 and B2(change)

1. each one creates is own transaction but doesn't sign it and send it to the server.

2. server creates 1 transaction unsigned from these 2.

3. he then send this to user A who verifies his own inputs and outputs and then signs it.

4. I don't know the inner workings of bitcoin protocol and cryptography so I don't know what user B need sto sign (the sign transaction from user A or the unsigned transaction from the server and after that the server append both signatures to transaction).

5. At this point server has 1 bigger transaction signed by all parties. he send it to bitcoin network and deletes individual unsigned transaction which were never meant to be signed.

Sure however you are sending your private key to a third party and hoping they don't suddenly rob you (and everyone else at the same time).  Also you would need to ensure to never use that private key again even for change again. 

probably this could be implemented with a modified client.
Clients connected to a central location, all clients send their transaction unsigned, server creates 1 transaction, clients sign it after each verifies that is ok, server sends this to the bitcoin network and deletes individual unsigned requests.

Can something like this be implemented? The money never touch the central location.

Thanks to everyone for your thoughtful replies! Indeed,if we desire transactions to be combined(or inputs separated from outputs) after they were emitted, we get into trouble. But what if we can do it before transaction gets published? Two or several neighbor nodes can put together bigger mixed transaction with more inputs/outputs, after this is done it can be processed normally. Something like Diffie-Hellman key exchange where two parties without prior information can agree on encryption key over untrusted connection, so here network nodes can agree on one compound transaction. So that individual transactions could be visible only to small part of the network.

It can't be done with Bitcoin we are talking about a comprehensive change to how transactions are handled.

It could potentially done with a new cryptocurrency.

The main issue with the proposal in OP is that the information between sender & receiver is already known.  It has to be known.

Transaction: I have 10 BTC in A and I want to send 5 to Y and 5 to Z.  

If I submit that to the network then anyone on the network knows that (even if it isn't included in the block).

Say the block ends up looking like this...
Inputs
A -> 10 BTC
B -> 1 BTC
...

L -> 4 BTC

Outputs:
M -> 0.2 BTC
...
Y -> 5 BTC
Z -> 5 BTC

Now to anyone who ONLY has the block there is no way to know which input(s) went to which output(s).  However anyone could simply have kept a copy of my original transaction.  If they do looking at transactions submitted to the network AND the blocks it is trivial to reconstruct the original transaction.

One would need to devise a system where the transactions are hidden from everyone except those who solve the block and only hash of transaction submitted to entire network.  

Thus unless you solved the block you would only be able to see
a) the block level view.
b) the hashes of transactions.

Alternatively one would need a method where inputs and outputs are completely disconnected. 

Something like:
1) You submit input only and it gets hashed to a block.
2) you submit output only and it gets hashed to a block.
3) there is some cryptographic system linking outputs to a prior block (not input).

I am not even sure such a system is possible or even desirable just brainstorming to show the criticial "issue" (delinking inputs and outputs) isn't accomplished by the OP and is a non-trivial problem.

That can't be done now, but I wonder about a system that let a tx essentially say. "This input can be used for any tx as long as the coinbase transaction of that block has an output to [recipient address] equal to [amount].

Feels like there might be problems with it. Multiple people paying the same address in the same block...?

I doubt miners can do this (changing transactions) without the original private keys. I definitely don't want anyone able to tamper with my txs.

-coinft

Hello,

I am certain somebody already thought about it - but can't find it. Why cannot be transactions in block mixed together to make individual transactions indistiguishable? I can think of these strategies:

1. Create 1 big transaction per block from all submitted ones by just adding them together
2. split big transactions into more blocks or amounts
3. Nodes can generate decoy transactions between addresses inside one wallet,to increase noise.

Receiver won't know which sender address(es) were used for its transaction..but it's really a prob'lem?