Topic: How to truly anonymously send coin to the Democratic Party (Read 2318 times)

That's the current model. If the new key is "published", say on a web site, it looses anonymity by becoming associated with the receiver.

The point here is that a transaction can be created between two keys, neither of which is associated with a person or business, if senders can generate keys for receivers, send coin, and never interact with the receiver in any other way.

Isn't it easier if the receiving party just generates a new keypair? or that's still not anonymous because they know someone sent coin there? How about using one of those coin mixing services?

This is correct. If we used pure public keys, rather than hashes of public keys, then the sender could make new addresses for the receiver from normal keys.


Of course.
A business could use this model. However, if you end up notifying someone that you've sent him something you could loose the anonymity of the transaction if the side channel is monitored.

Noob question.

You cannot take an address and make a new address that the same private key can use, correct? But this is just because of the hashing going on, if we used pure public/private key pairs that would actually be possible?

Regarding identifying the sender generated keys. The sender could notify the receiver out of band, right?

I have a feeling like I'm missing something.

Hell no, I just opened a tip jar on Propster for them.
It's a beautiful concept really.

Read the FAQ

You're the party treasurer, I take it?

Google search
-----------------------
Your search - 1D5yADZsb1XGE15rbBRWhe2QkRDGSv3588 - did not match any documents.

Suggestions:

Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.
-----------------------

Even Google doesn't want you contributing to them...

Here it is - 1D5yADZsb1XGE15rbBRWhe2QkRDGSv3588

Edit: Propster admin wrote this:

I will be delivering this amount, and closing this Tip Jar.  Both democrats and republicans are against laissez-fair capitalism and are ultra-religious. This policy is described in the Howto, at the end.

http://libdspace.uwaterloo.ca/bitstream/10012/855/1/jlutz2003.pdf

Dedicated hardware, sure.  Not unlikely if the market should arise.

But my point was, that the usefulness of this solution is limited to isolated cases (which are still useful cases).  Sure you can do 1,000 ECDSA ops per second, but if there are 1,000 addresses in your wallet and any of them could be used in an address-extension like this, you're at 100% CPU just to check 1 tx per second.  And we know 1 tx per second is nothing compared to the desired adoptance of Bitcoin.  The math doesn't have to add up exactly (who has 1,000 addresses in their wallet?) but the point is it's entirely possible for network volume to overwhelm even powerful computers, which puts the whole idea on shaky grounds.

I actually really like the idea for wikileaks, political dissidents, or internet gambling, if they use a single public address and dedicate systems to it... but outside of that very niche market, I don't see it working.

The server for thin clients (see my post above) would have to be scaled to deal with this problem, I agree.

My impression is processors can do 1,000's of ECDSA-DHSS per second today. I bet if you cared enough about this to dedicate processing to it, available processing power would keep up with total transactions.

As long as miners can keep up with regular transactions, Wikileaks should be able to deploy a server that can keep up as well.

I didn't say it would have to be done by miners.  I implied that doing ECDSA-DHSS calculations on 1+ million transactions per hour is not feasible.  There's not 1 million tx/hour right now, but with any degree of success in the Bitcoin world, even having a single address which you know might be used for this kind of address extension will cause you to have to do at least 1 million ECDSA ops per hour.  That's a lot of electricity, just to find out if someone sent you money.

And that's only for one address.  Now you have to do one ECDSA-DHSS calculation for every address in your wallet on every tx, at least the ones that you suspect might be used for this kind of key extension.  For an organization like wikileaks which could post a single address once and dedicate a server to searching for incoming transactions, it makes sense.  But I don't see it working for regular users in the future...

Some deterministic wallet implementations have “light” clients talking to (untrusted) servers that handle the heavy work of scanning the bitcoin block chain and linking to multiple peers.

In that scenario the server should be able to check the ownership of a new transaction without being able to spend the coins in the transaction. However, allowing this would conflict with the stated property of privacy when using Bitcoin.

The following shows how you allow a server you choose to verify that you own a transaction without allowing the server to spend your coins or allowing the whole world to know which transactions are yours. It’s an intermediate level of trust that may not make sense to people who value strict privacy but is useful to people who value the light client deterministic single key property (for ease of multiple light client deployment, for example).

The Certificate master key is really a key doublet. The master private key is still "a" as above. However, now you generate a verifier private part “b”.  b = Hash(a). Let the public part of a be “A” and the public part of b be “B”.   A = aQ and B = bQ. The doublet “(A,B)” is published in the certificate for Alice. (A,B) and the private verifier b are given to the service(s) you are using to manage the block chain for you. With b the server can verify transaction ownership but not spend.

A sender would recover (A,B)  from Alice’s certificate. The sender then generates X as follows:

     s = Hash(m,yB)

     X = sA.

The sender sends coin to X.

A server holding verifier b would have to check every new transaction for the property that s = Hash(m,bY) and X = sA to know to add the coins to the balance in the wallet. (Note yB = bY). (As I mentioned above, this is expensive. We could save time by leaving a few bytes from Hash(s) in an available field of the transaction. The server would still have to calculate an s for each transaction but after that the Hash(s) is relatively cheap.)

Note the server can verify X belongs to Alice but cannot generate the private part of X.

The thin client Alice has generates x, the private part of X, as follows:  She is given m and Y from the transaction; then  s = Hash(m,bY);  x = sa (modulo a large prime determined by the ECC);  She can check that X = xQ.

The thin client can now sign a prepared transaction using x and return the signed transaction to the server when spending.

Worse than the Democratic Party?  What would that be, the Greens?

LOL - just joking. Didn't want to say Wiki-leaks or worse.

Not true. Miners would not have to change to implement this.

This is independent of the current implementation in that the regular client does not have to change if this is implemented by some clients. Those clients willing to do the checking could implement this no problem.

I'm curious.  What is the bitcoin donation address of the Democratic Party?

True.  See

I guess I was thinking more of point multiplication on elliptic curves and trying to visualize how the geometry would work out. Thinking of it as regular multiplication with modulus involved definitely helps out.

It's a shame it doesn't scale very well, and that much of the required computing power to scan transactions is on the receiver's side. I'd imagine a large company would have the processing power to check the whole blockchain, but it's mainly the individuals with their laptops and smartphones who would benefit from the anonymity.