Bitcoin Forum
October 22, 2017, 06:46:50 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 6 7 8 9 »  All
  Print  
Author Topic: Zerocoin: Anonymous Distributed E-Cash from Bitcoin  (Read 36603 times)
mjosephs
Full Member
***
Offline Offline

Activity: 128


View Profile
April 17, 2013, 05:03:06 AM
 #41

Could you guys stop bringing Google up?

As soon as you stop accepting money from them, sure.

Nothing wrong with that, by the way.

But there is something wrong with trying to claim that you aren't influenced by your source of income.  Gavin and most of The Bitcoin Foundation explicitly disagree with that, citing it as one of the major reasons why TBF needs to exist -- to provide Gavin with a income source that isn't controlled by the profit motives of a single organization.

Look, I don't think you're going to get very far with "employers don't influence peoples' views" around here.  Try something else.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
mjosephs
Full Member
***
Offline Offline

Activity: 128


View Profile
April 17, 2013, 05:07:09 AM
 #42

Privacy and anonymity are absolutely different thing. It is possible to be anonymous and yet lack privacy. For example, if Satoshi cashed out all at once, we'd know this immediately even though we do not know anything about him.

Your boss doesn't seem to think so.  He keeps telling people that if they don't like it they can just change their name, which is basically saying that anonymity (or pseudonymity) is the only route to privacy.

So maybe this is why you have a vested interest in convincing people they don't need anonymity or pseudonymity?  I mean, obviously if you said people don't need privacy nobody would take you seriously.  But it's a lot easier to tell people that privacy is okay as long as they don't have the means to establish it.

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 17, 2013, 10:14:46 AM
 #43

You don't have any idea how Google works, do you?

Firstly, Eric Schmidt isn't my boss and hasn't been for years. The CEO is Larry Page these days. But even if he was, a throwaway "prediction" intended to provoke discussion from 3 years ago is not very compelling evidence for your point of view.

Secondly, my job for the past few years has been anti spam and nothing to do with Bitcoin. I've been allowed to work on it under the 20% time policy which is very hands-off. My management have never told me what to do or what positions to take on anything with respect to Bitcoin. My compensation isn't affected by anything I do here.

Thirdly, I don't have a "vested interest in convincing people they don't need anonymity". Why would I spend so much time working on a project created by an anonymous founder if I had a problem with anonymity? But I'm also a realist. Go talk to people in the world outside this forum echo chamber for a while. There are a LOT of people, especially older people, who are immediately very suspicious of anyone who is anonymous or uses a pseudonym. You can see similar concerns come up in the media coverage - trusting mathematics instead of people is just a totally alien way of thinking for most people. Whenever I've explained Bitcoin to my parents the thing they fixate on is "Why is the guy who made this anonymous? Why do you trust this thing he made?". They eventually came to understand that it didn't matter who he was, but even after I explained that for the Nth time, they still have an allergic reaction to it. Why? Because the most common reason for people to hide their identity is to avoid the justice system.

Anyway, you haven't got my point at all - privacy and anonymity are linked but are not the same. Satoshi's paper says as much:

Quote
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.

Neither banking nor Bitcoin provides perfect privacy or anonymity. Banks give users privacy from each other but obviously the banks and governments still know what you're doing. Bitcoin users have no authority that knows everything but routinely leak private data to each other by misusing the block chain (re-using keys, etc).
wachtwoord
Legendary
*
Offline Offline

Activity: 1624


View Profile
May 27, 2013, 05:38:03 PM
 #44

I've watched the presentation of the paper http://research.microsoft.com/apps/video/dl.aspx?id=192058 and I have one important question. First off, I'm actually an academic in computer science, but the zero-proof subject matter is all rather new to me.

So the question:

If I make a zerocoin and later want to to redeem the zerocoin back to a bitcoin what is the reason this cannot be traced back to the specific zerocoin I'm converting back to Bitcoin (and in effect my previous Bitcoin transactions)? In the talk Matthew Green mentions that proof is required to show you own the zerocoin. Why doesn't this imply this whole system isn't anonymous at all?

If anyone can explain this, thanks a lot Smiley

PS: As the first half hour was really slow and simple to follow for the uneducated I hoped he would continue with this when he reached the difficult cryptographic portion of the talk but then he went into overdrive not even introducing the concept of an accumulator. He could have skipped the first half an hour for me and took twice as long for the second part for me, but it must have been on a cryptography conference or something.

mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
May 27, 2013, 05:41:41 PM
 #45

You can't trace the proof back to the specific coin, all you can see is that to a high degree of probability the person redeeming the zerocoin possesses the secret trapdoor associated with one of blinded coins.

ROI is not a verb, the term you're looking for is 'to break even'.
wachtwoord
Legendary
*
Offline Offline

Activity: 1624


View Profile
May 27, 2013, 05:58:39 PM
 #46

You can't trace the proof back to the specific coin, all you can see is that to a high degree of probability the person redeeming the zerocoin possesses the secret trapdoor associated with one of blinded coins.

Okay, is there a way for me to comprehend this without venturing into the world of digital commitments, one-way accumulators and zero-knowledge proofs? I mean, I can explain the inner working of Bitcoin to quite a level of detail (at least to anyone with a technical degree) before someone has to take my word for it. Is it possible to explain how I can prove I own 'some unredeemed Zerocoin in the blockchain' without specifying which one without a PhD is cryptography?

I want to believe but I need to be convinced I guess Wink

mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
May 27, 2013, 06:01:51 PM
 #47

Yeah, I'm afraid you would have to delve into zero knowledge proofs. There are some good papers on the internet, but I can't say I fully grasp how it works just yet.

ROI is not a verb, the term you're looking for is 'to break even'.
wachtwoord
Legendary
*
Offline Offline

Activity: 1624


View Profile
May 27, 2013, 06:09:22 PM
 #48

Haha, well thanks anyway.

adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
May 28, 2013, 04:38:52 PM
 #49

Btw I made a summary of the zerocoin paper here.  

http://www.mail-archive.com/cryptography@randombit.net/msg04117.html

Not sure it helps understand it or not, but there you go.

About ZKP of set-membership the first thing to understand is the RSA accumulator of Benaloh.  

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf

Its like a commutative hash function but using RSA.  With discrete log (or EC discrete log) if i give you A = xG (G is base point x some random number) I can prove I know the discrete log by showing you x and G is fixed.  But if you are allowed to use any generator H then you can start with A divide it by some random number x and call the result H.  Now you can prove xH = A but that doesnt prove anything as anyone can do that if they can prove the discrete log to some random base its an x-th root not a discrete log, which is easy .  How you "divide" A by x is multiply by x^-1 mod n (n is the order of the curve a public known value for a EC parameter set).  And you can compute x^-1 mod n easily with euclidean algorithm (normal modular math, no EC).

However the analogous division is not possible with RSA, in RSA computing x-th roots is also hard (as well as discrete log).  eg If I give you A you cant compute A^(x^-1) because x^-1 has to be mod phi(n) = (p-1)*(q-1), and in the case of RSA phi(n) is secret and in the case of an accumulator p, q, phi(n) are supposed to be deleted after setup so no-one knows them.  So if I can show you H and x and H^x = A that proves you I had an influence in producing A.  

each step is done by the user after receiving the previous accum set.  Users can go in any order as exponentiation is commutative.

G and n is published, p, q deleted
step0: accum set = {G}
user1: private x1, accum set = {G,A"=G^x1}
user2: private x2, accum set = {G^x2,G^x1,A'=G^x1^x2}
user3: private x3, accum set = {G^x2^x3,G^x1^x3,G^x1^x2,A=G^x1^x1^x3}

The accum set is broadcast by each user and each user raises every element except the last to his private exponent xi, and appends the last element raised to his private exponent xi.

You notice that the base of each user is missing the exponent of his respective xi, user1 base is missing x1 (first item in set), user 2 is missing x2 (second item in set), user 3 is missing x3 (third item in set).  Consequently a user can raise his private base call it Bi for user i, to power xi and get A the global accumulator Bi^xi = A.  Because discrete log and x-th roots are hard in RSA he cant do that unless he was involved in this process.

That involves a lot of sending of sets.  If alternatively each user broadcasts his xi, everyone can compute his own Bi and the final A, however now anyone can compute any Bi and all xi are public.  Its a lot more communication efficient however.  To combat the fact that xi are public, xi has to be chosen eg as xi = H( yi ) where yi is secret.  Then a user can prove that by revealing yi and having the verifier check xi = H( yi ) and Bi^xi = A.

Or as its hard to efficiently make ZKP about (symmetric) one way hash functions a discrete log "hash" function could be used eg xi = H^yi.  Now the user could prove knowledge of yi without revealing yi (via a Schnorr signature see below).

So lots of people compute and pass those messages around then they can prove simply that their zerocoin is in the set until there is a final A that includes contributions from all users who produced zerocoins in this time period.  And each user knows a Bi such that Bi^xi = A for the single A value so they can prove membership.  The order is commutative so it doesnt matter which comes first.  A is small - just 2048 bits = 256bytes no matter how any serial numbers are provable against it.  Bi is also small 256bytes as well as is xi.  And the user need only store Bi and xi because he can compute A from it.

So that provides a proof that you had an influence on an accumulator (some non-secret value of yours was included "hashed" into an accumulator).  Its rather like a merkle tree except that you dont need to provide log n path in the three to prove, just prove you know Bi^xi = A.

So far thats not private as all Bi values are recognizable to anyone who saw them.  However using an extended blind schnorr signature like proof where you can prove you must know such an xi and Bi without actually revealing them.  Its ZKP because the verifier could even create a fake if he choose the challenge himself so therefore you can argue he couldnt learn anything about Bi nor xi from something he could've created yourself.  

A schnorr proof of knowledge to get an idea how you could prove something similar is related to a DSA signature and relatively simple eg here.  http://en.wikipedia.org/wiki/Schnorr_signature and its the same concept as DSA, ECDSA etc - ie you can prove you know the discrete log of something, without actually revealing the discrete log!

A schnorr proof only hides xi, the zerocoin enhanced proof also hides Bi but the basic idea is the same.

The efficiency problem in zerocoin is that each run of the ZKP has a 1/2 chance of being unconvincing.  So you have to run it like 128-times to get probability 1/2^128 kinds of cryptographic assurance.  This repetition is called cut-and-choose.  Fortunately it can be made non interactive (by fixing the challenges based on a one-way hash of the parameters), but thats still 128 x 2048-bit RSA things which is like 10s of kB.  Probably they are doing a bit less than 128 cut-and-choose rounds because they say that proof size is 45kB for 2048-bit and I presume a proof includes at least 2x 2048-bit values.  Actually I see they say 80x, so that comes out to 2.2 so maybe there is some auxilliary info, eg the serial number?

To prevent double spending they just keep a public list of spent zerocoin serial numbers, and you cant influence the serial number after the fact.

So I guess the other thing you can do if that is unnecessarily complicated is just say ok there's a ZKP of set membership which proves your coin is one of that set, but not which one and trust that people have figured out how to make that work.

btw Benaloh's accumulator paper is quite readable

[edit: fix error about xi vs Bi and give a small example]
[edit2: more communication efficient public xi = H^yi, secret yi or xi = H( yi ) version]

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
May 30, 2013, 10:49:10 AM
 #50

the RSA accumulator of Benaloh [is] like a commutative hash function but using RSA.  

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf

So if I can show you H and x and H^x = A that proves you I had an influence in producing A.  

[..]each user broadcasts his xi, everyone can compute his own Bi and the final A, however now anyone can compute any Bi and all xi are public.  Its a lot more communication efficient however.  To combat the fact that xi are public, xi has to be chosen eg as xi = H( yi ) where yi is secret.  Then a user can prove that by revealing yi and having the verifier check xi = H( yi ) and Bi^xi = A.

So one thing you could think of and I think it has been mentioned a few times is that you could replace the merkle tree in bitcoin with an accumulator based tree.  Now a problem with accumulators is someone or some set of n people only 1 of whom has to be trusted, have to create n = p*q two primes p, q and then delete p, q; which is not great but could be entertained perhaps if accumulators made some big saving.

Consider accumulator hashes: then an SPV client can be convinced a coin is in a block by receiving Bi and xi.  Each Bi is 384 bytes (3072bit RSA n is about the same security margin as the rest of bitcoin, considered about as secure as 128-bit symmetric keys and 256-bit EC keys).  Then a proof of membership within a block is 384 bytes + the hash say 20 bytes + the transaction detail whatever that is a hundred bytes say 512bytes.  

The merkle tree approach requires log2(k) hashes each 32 bytes, k the number of transactions in a block.  I guess a block could hold ~10,000 transactions best case with 1MB blocks.  However this page https://en.bitcoin.it/wiki/Scalability says transactions per second is currently limited to 7 = 4200/block.  log2(4200) ~12 and 12*32=384 bytes.  No saving for accumulators!

However another trick could be to not start a new accumulator with each block, just keep going, then you only need the last block in the chain.  (SPV clients download all blocks, or some set of recent blocks for confidence?)   So with accumulators to catch up an SPV client just download the latest block, cross-check a few peers agree its the latest block.  However someone (each full node?) would have to update Bi for all unspent coins.  Updating Bi is a 3072-bit to a 256-bit modexp operation which has some cost.   That might start to get unreasonably CPU expensive, unless the network shares out the work.  The benefit would be faster catchup for SPV clients.

I suppose alternatively blocks themselvs could be placed into a sorted merkle tree, and then SPV clients could download blocks as needed (log2(b) blocks where b is 23866 blocks so far http://blockexplorer.com/q/getblockcount) ~15 blocks to test a given block.  But its probably not a big saving because transactions are made from multiple outputs and an SPV client if it does a few transactions per day will soon have to download all blocks anyway.

Or you could have an accumulator tree of blocks, with the accumulator hashed in the latest block.  Then you can download any historic block and instantly check it belongs in the history of the current block without downloading the rest of the block chain, nor 15 blocks for log2(b) verification if the block were organized as a merkle tree.  Cost is each full node needs to update (or fullnodes cooperatively update) the Bi values for all 23866 blocks every block (10mins).

Some possibilities in there but nothing very impressive, plus the problem of there temporarily existing an accumulator private key that must be deleted (spread across the RAM of n users during accumulator genesis/generation, only one of which needs to be trustworthy).

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 30, 2013, 01:15:54 PM
 #51

I've started and then stopped writing about Zerocoin three or four times now; my thoughts about it are still muddled.

It adds a whole lot of complexity to transaction creation/verification to solve one problem:  how to mix coins/transactions with zero trust in the mixing process.  That's technically nifty, but I wonder if it is the best engineering solution.

I wonder if just using a couple of semi-trusted mixers would be a lot faster/smaller/simpler.

And then I start thinking about "tainted coins" in general. If we imagine a world with either mandatory or voluntary "taint tracking" (I have no idea whether or not that will ever happen), then it seems to me any mixing scheme that isn't "always on" is likely to fail in practice-- all coins coming out of the mix will be considered tainted.

Why? I assume that most users (if you are reading this are NOT "most users") don't care much about privacy/anonymity. So I would assume most people would choose the lowest cost, fastest, most convenient method for their transactions. Anybody using a mixer will be either a weirdo, principled privacy nut (like us) or a criminal. I don't see other "privacy first" projects taking over the world, but do see lots of big, successful "quick and easy and free" projects.

Then my thoughts get muddled, because "it is hopeless, just give up" is not an answer I'm willing to accept. But it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer. Making your network connection more private is the other piece of the puzzle, though, and all of the solutions for that (either route through a couple of semi-trusted proxies or use Tor or i2p) add significant convenience/speed/financial costs.

How often do you get the chance to work on a potentially world-changing project?
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
May 30, 2013, 01:29:49 PM
 #52

I have a feeling that anything on this front that will work in the end will:1. require no change to the code of the Bitcoin client;2. interoperate seamlessly with the current infrastructure;3.have adjustable level of paranoia/usability ;4. backed by competent and transparent developers.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
apetersson
Hero Member
*****
Offline Offline

Activity: 666



View Profile
May 30, 2013, 02:14:46 PM
 #53

my thoughts in response to "doubting gavin's" post:

i think this idea has merit for these reasons:

Today taint is irrelevant for 99,99% of transactions. if someone tips you would you go back and try to trace that and will you try to "remove" that money from your wallet? i guess not. likewise most payment processors would not care. i don't know if mtgox performs any checks, but i would guess yes.

it improves fungibility of coins - if a block includes a valid input it should not matter where they come from. having zerocoin out there working removes all doubt about fungibility and "solves" this issue.

I see many valid use cases why someone would love to use zerocoin.

Just one example: in the year 2023 Gavin and family want to go to vacation to Mexico. Books a 4* hotel for 3 mBTC for two weeks using his desktop wallet.
The wallet of the hotel is of course a HD Wallet where Los Zetas control the master private seed. Thanks to trivial blockchain analysis and entity merging they are informed that someone with 10+ Bitcoins *gasp* is coming, and know their exact location and time.

Once he arrives access to his wallet is obtained via rubber-hose cryptanalysis.

If there was Zerocoin you could trivially create a "holiday spending" identity it would be very hard to estimate someone's net worth in bitcoins just by obtaining one transaction. Put 10 mBtc there and have two nice weeks.


Yes the proofs might be large and therefore most transactions would be expensive - this is why fees are calculated by KB. i would say, we should let the a free fee market decide if it is worth using and worth of inclusion in blocks.

hopefully we can explore this interesting topic further reducing the overhead further. i am still trying to understand the details of how it works but so far - i think it is absolutely worth including something like zerocoin into the mainline client, once we have a "good enough" solution.
adam3us
Sr. Member
****
expert
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
May 30, 2013, 02:22:38 PM
 #54

Zerocoin [...] I wonder if just using a couple of semi-trusted mixers would be a lot faster/smaller/simpler.

Yes I had the same thought - seems awfully expensive for a mix.  You can view zerocoin as a private keyless p2p mix.  Several people have proposed non-p2p mixing protocols where the mix cant steal your coins.  Whats wrong with that?  I guess the main limit is the mix disappears and your coins get locked.  Probably that could be fixed with smart contracts/multisig.

Greg Maxwell also and others proposed taint mixing using multiple coin inputs.

(Other than mixing you may also aim to taint all, equally as a protocol).

about "tainted coins" [...] all coins coming out of the mix will be considered tainted.

I agree that is likely the end game for mixes.

it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer.

The committed coins idea that temporarily keeps the taint decision private allows people to at least retain p2p decisions about taint without any a priori restrictions.  However the privacy is either short-lived (fairly immediately decommit the coin) or the privacy shrinks over time (if you keep spending the coin in committed form) as more people get to see the transaction history, as each recipient must see all details prior for validation.  A posteriori sanctions after decommit may come into play to if the user is identifiable - if your IP address is logged as posting the reveal of a tainted coin, maybe that matters also.

Fairly efficient/low overhead but still some limitations there.

Making your network connection more private is the other piece of the puzzle, though, and all of the solutions for that (either route through a couple of semi-trusted proxies or use Tor or i2p) add significant convenience/speed/financial costs.

It seems like users who are doing high value bitcoin things should be using ToR to hide their IP address which geolocates them.  And servers also should to add resistance to network split types of attacks.  Maybe in a 2.0 bitcoin it might include the minimal defenses of encryption, tunneled relaying and hard to influence remote connections for double-checking local claims.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
Martin404nitraM
Newbie
*
Offline Offline

Activity: 27


Vi Veri Veniversum Vivus Vici


View Profile
May 31, 2013, 12:37:00 PM
 #55

I have a weird question...what happens to password protected wallet of dead person or person who forgot his password? Are these bitcoins lost forever?
apetersson
Hero Member
*****
Offline Offline

Activity: 666



View Profile
May 31, 2013, 05:36:16 PM
 #56

I have a weird question...what happens to password protected wallet of dead person or person who forgot his password? Are these bitcoins lost forever?
this question does not really belong to this thread because exactly the same happens with zerocoin or without.
if you lose the password of a protected wallet and it is the only backup - the money is gone. with zerocoin or without.
Stampbit
Full Member
***
Offline Offline

Activity: 182



View Profile
June 01, 2013, 09:16:17 PM
 #57

Whats taint?
iddo
Sr. Member
****
Offline Offline

Activity: 360


View Profile
June 02, 2013, 10:50:14 AM
 #58

... it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer.

Greg Maxwell also and others proposed taint mixing using multiple coin inputs.

Not sure what's the proposal that you have in mind, I remember others talking about such ideas in 2011 in #bitcoin-dev (link), and these ideas could be a lot more efficient than using ZK proofs.

I believe that the idea is that instead of how blocks are created now for the blockchain, the network nodes will create "mixed" blocks in 3 rounds of communication, instead of 1 round. Suppose Alice wants to send 5 bitcoins to Bob, Carol wants to send 4 bitcoins to Dave, Ellen wants to send 3 bitcoins to Frank, and we now wish to construct the next block with these three transactions. So in round 1 Alice broadcasts a message that declares that she intends to send 5 bitcoins to Bob's address (without signing this message with her privkey), and Carol and Ellen do the same. Now in round 2 the miners prepares a single transaction with the inputs of Alice,Carol,Ellen (12 bitcoins in total) and the outputs of 5 bitcoins to Bob's address, 4 bitcoins to Dave's address, 3 bitcoins to Frank's address, and broadcast this single transaction. In round 3 Alice signs this single transaction and broadcasts her signature, and Carol and Ellen do the same. Now the miners can do PoW work on a block that contains this transaction, and finally broadcast the valid block that they solved. This way the block is created in a mixed fashion, in the sense that the data that resides in the blockchain doesn't specify whether Alice's (possibly tainted) coins were sent to Bob or Dave or Frank. After iterating this same process with the next blocks, it would be practically impossible to tell where Alice's tainted coins ended up at. An attacker can eavesdrop on the network and know that Alice sent her coins to Bob, but he cannot prove anything because Alice's message in round 1 isn't signed and therefore can be forged by anyone.

Problems with this idea:
1) Alice must send a fee as a secondary signed transaction in round 1, otherwise if Alice is malicious then she could refuse to participate in round 3 to carry out a denial of service attack, because the single mixed transaction is valid only if both Alice and Carol and Ellen sign it. On the other hand, malicious miners could now collect fees without including txns in blocks. Maybe it can work if the fee in round 1 is smaller than the fee that Alice would pay for the actual transaction where she transfer her coins Bob, so the miners will have an incentive to generate non-empty blocks (i.e. not to generate blocks that contain only the fees of round 1) ?
2) When the miners are working on the PoW, if other transactions (with high fees) were broadcasted in the meanwhile, then in order to include the extra transactions they'd have to prepare another single mixed transaction (because the signatures for the first mixed transaction have already been provided). So it appears that this process will work in batches, where a block could contain several such mixed transactions. We should be careful that the default behavior of nodes is to prefer signing mixed transactions with many inputs, otherwise malicious miners could attempt to reduce the overall privacy.

Any suggestions on how to improve this idea?

Edit: Looking at another thread (link), I see that here too we'll have to do the knapsack-style random value splits. I suppose that it means that Alice should request several receiving addresses from Bob before she sends her coins to him? Or maybe just one pubkey and chaincode, if Bob is using type-2 deterministic wallet.
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
June 02, 2013, 12:32:55 PM
 #59

Could we simplify this by creating a new hash type combining the effects of SIGHASH_SINGLE and SIGHASH_ANYONECANPAY? It would mean "as long as my output is included, I'll release my input". A further step would be to require valid blocks to consolidate all such transactions into a single transaction.

ROI is not a verb, the term you're looking for is 'to break even'.
mmeijeri
Hero Member
*****
Offline Offline

Activity: 714

Martijn Meijering


View Profile
June 02, 2013, 12:59:31 PM
 #60

Maybe this could even be combined with homomorphic encryption to obscure the incoming amounts and to consolidate chains of transactions? The combined effect would be netting of transactions with obscured incoming amounts.

ROI is not a verb, the term you're looking for is 'to break even'.
Pages: « 1 2 [3] 4 5 6 7 8 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!