[Bitcoin-development] ecash and revocability
So back in 1999, in an ecash thread on cypherpunks I claimed: http://marc.info/?l=cypherpunksm=95280154629900w=2 I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. This was in the context of a discussion of digigold (e-gold stored the physical gold, digigold offered ecash backed in that physical gold). Digigold ran on Systemics payment server/sox protocol. Because of inferred regulatory concerns and patent licensing issues digigold systemics were not using blind signatures. However with systemics sox server, like bitcoin, you could create multiple accounts on demand and shuffle payments around for a degree of privacy. The bitcoin analogy would be the transaction log lived in the systemics server, so it had a central failure point, but arguably more privacy as the log was not public. Also systemics SOX protocol (Ian Grigg Gary Howland) had some aspect of bitcoins smart contract concepts - ricardian contracts. http://iang.org/papers/ricardian_contract.html (Btw the anonymous reply itself was interesting - http://marc.info/?l=cypherpunksm=95280154629912w=2 that could have been Nakamoto, the only missing thing from the parts on the discussion room floor to bitcoin is mathematical inflation control.) The thread actually started here http://marc.info/?l=cypherpunksm=95280154629912w=2 and then continues here http://marc.info/?l=cypherpunksm=95280154629900w=2 because of a subject line change and then http://marc.info/?l=cypherpunksm=95280154629916w=2 and http://marc.info/?l=cypherpunksm=95280154629948w=2 more subject line change confusion. A related thread a few days later also covers Sander Ta-Shma (which zerocoin is based on): http://marc.info/?l=cypherpunksm=95280154630167w=2 there were many more threads about various ecash technologies. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoin taint unilateral revocability (Re: ecash and revocability)
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote: Adam Back in Sep 1999, cypherpunks list: I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. So I still think that is an important point. Ecash should not be revocable. I think bitcoin currently has a partial problem because of taint. Now blinding based unlinkability, in a distributed cryptographic payer/payee anonymous system like Sander Ta Shma [1] and zerocoin has so far been based on ZKP of set membership. Of course that is somewhat expensive, though zerocoin improved the ZKP with an relatively efficient (but still cut-and-choose) proof. Bitcoins relative lack of privacy creates a problem with tainted coins risking becoming unspendable, or spendable only with some users, or at a discount. So while the policy coded says all coins are equally acceptable, the information exists so people can unilaterally reject them, depending on what the taint is. So far revocability hasnt reared it's head that I heard, nor taint inspection too much? However people have the choice and technical means to check the taint and send the bitcoins back. Another aspect is that bitcoin, like systemics sox/digigold, makes a different privacy tradeoff. Somewhat private, but not very much. But it creates the question: could the taint issue be fixed efficiently (eg even without blinding or ZKP of set membership?) One related concept is commitments. I think its relatively easy to commit to a payment and lock a coin without identifying yourself, until the commitment is released. You might do the commitment, wait 6-blocks for confirmation, then reveal the commitment. Then that is like a self-issued green coin with no need for trust, that can be immediately cleared. The recipient has to be committed to at the same time to prevent double spending. So just commit = H( input-pub ) H( transaction ) and put it in the block chain. Where transaction the is usual ( input signature, output-pub, script). (Fee for the commit would have to come from an unlinked coin or the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction (free because fee was already paid). Validators check input-pub hash against committed coins by hash, check the transaction hash, and the usual ransaction validations = sum inputs, otherwise reject. The user better pay change if any to a different public key, as the inputs public keys are one use - are after the reveal they are DoS lockable by other people reposting H( input-pub ). The input-pub coin is locked as normal transactions have their public key hash validate as not being locked. Adam [1] Sander Ta Shma Auditable, Anonymous Electronic Cash http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin taint unilateral revocability (Re: ecash and revocability)
Adam, Take a look at this privacy enhancing solution based on fair exchange implemented by bitcoin contracts and cut-and-choose. It would require a public pool of users willing to exchange in common denominations at moments in time together to ensure unlinkability. It also leave a trace of exchange activity in the chain. This could all be added to wallet software to become automatic. http://robotics.stanford.edu/~xb/fc12/index.html Simon On 05/14/2013 07:09 AM, Adam Back wrote: On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote: Adam Back in Sep 1999, cypherpunks list: I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. So I still think that is an important point. Ecash should not be revocable. I think bitcoin currently has a partial problem because of taint. Now blinding based unlinkability, in a distributed cryptographic payer/payee anonymous system like Sander Ta Shma [1] and zerocoin has so far been based on ZKP of set membership. Of course that is somewhat expensive, though zerocoin improved the ZKP with an relatively efficient (but still cut-and-choose) proof. Bitcoins relative lack of privacy creates a problem with tainted coins risking becoming unspendable, or spendable only with some users, or at a discount. So while the policy coded says all coins are equally acceptable, the information exists so people can unilaterally reject them, depending on what the taint is. So far revocability hasnt reared it's head that I heard, nor taint inspection too much? However people have the choice and technical means to check the taint and send the bitcoins back. Another aspect is that bitcoin, like systemics sox/digigold, makes a different privacy tradeoff. Somewhat private, but not very much. But it creates the question: could the taint issue be fixed efficiently (eg even without blinding or ZKP of set membership?) One related concept is commitments. I think its relatively easy to commit to a payment and lock a coin without identifying yourself, until the commitment is released. You might do the commitment, wait 6-blocks for confirmation, then reveal the commitment. Then that is like a self-issued green coin with no need for trust, that can be immediately cleared. The recipient has to be committed to at the same time to prevent double spending. So just commit = H( input-pub ) H( transaction ) and put it in the block chain. Where transaction the is usual ( input signature, output-pub, script). (Fee for the commit would have to come from an unlinked coin or the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction (free because fee was already paid). Validators check input-pub hash against committed coins by hash, check the transaction hash, and the usual ransaction validations = sum inputs, otherwise reject. The user better pay change if any to a different public key, as the inputs public keys are one use - are after the reveal they are DoS lockable by other people reposting H( input-pub ). The input-pub coin is locked as normal transactions have their public key hash validate as not being locked. Adam [1] Sander Ta Shma Auditable, Anonymous Electronic Cash http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 5:25 AM, Adam Back a...@cypherspace.org wrote: On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote: When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A destroy-by-miner fee transaction is a normal bitcoin transaction sent by any user, that might look like Input 1: 1.0 BTC Output 1: 0.5 BTC (the miner fee is implicitly 0.5 BTC, paid to whomever mines the transaction into a block) Sadly the bitcoin protocol prevents zero-output, give-it-all-to-the-miner transactions. Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. That evaluation largely depends on the needs of the service in question. In my decentralized identity (SIN) example, you merely need to prove to the cloud that you sacrificed some bitcoins to any-miner. The confirmed, in-chain, non-coinbase transaction becomes the root node for off-chain identity data. The penalty for the user withholding the sacrifice transaction is that their SIN is not created. That incentive may not exist in that way, in another service. Or do you mean to say you could have (implicit reward 25BTC) and reward transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and validation semantics? That would be close enough to give-to-miner. Also the output sum 0BTC limitation could be changed to = maybe... (just one well placed character :) Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
report: https://bitcointalk.org/index.php?topic=205349.0 Every talk will be widely witnessed and videotaped so we can get some reasonably good security by simply putting out PGP fingerprints in our slides. Yeah, some fancy attacker could change the videos after the fact, but the talks themselves will have wide audiences and a lot of opportunities for fraud to be discovered. That means it'd also be reasonable for people to sign those keys too if you are present and are convinced you aren't looking at some impostor. (of course, presenters, check that your PGP fingerprints are correct...) Remember that PGP depends on the web-of-trust. No single measure in a web-of-trust is needs to be absolutely perfect; it's the sum of the verifications that matter. I don't think it matters much if you have, say, seen Jeff Garzik's drivers license as much as it matters that you have seen him in a public place with dozens of witnesses that would recognize him and call out any attempt at fraud. Secondly remember that many of us are working on software where an attacker can steal from huge numbers of users at once if they manage to sneak some wallet stealing code in. We need better code signing practices, but they don't help without some way of being sure the keys signing the code are valid. SSL and certificate authorities have advantages, and so does the PGP WoT, so use both. FWIW I take this stuff pretty seriously myself. I generated my key securely in the first place, I use a hardware smartcard to store my PGP key, and I keep the master signing key - the key with the ability to sign other keys - separate from my day-to-day signing subkeys. I also PGP sign emails regularly, which means anyone can get a decent idea of if they have the right key by looking at bitcoin-development mailing list archives and checking the signatures. A truly dedicated attacker could probably sign something without my knowledge, but I've certainly raised the bar. -- 'peter'[:-1]@petertodd.org 016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518 signature.asc Description: Digital signature -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
On 14 May 2013 20:41, Peter Todd p...@petertodd.org wrote: report: https://bitcointalk.org/index.php?topic=205349.0 Every talk will be widely witnessed and videotaped so we can get some reasonably good security by simply putting out PGP fingerprints in our slides. Yeah, some fancy attacker could change the videos after the fact, but the talks themselves will have wide audiences and a lot of opportunities for fraud to be discovered. That means it'd also be reasonable for people to sign those keys too if you are present and are convinced you aren't looking at some impostor. (of course, presenters, check that your PGP fingerprints are correct...) Remember that PGP depends on the web-of-trust. No single measure in a web-of-trust is needs to be absolutely perfect; it's the sum of the verifications that matter. I don't think it matters much if you have, say, seen Jeff Garzik's drivers license as much as it matters that you have seen him in a public place with dozens of witnesses that would recognize him and call out any attempt at fraud. Secondly remember that many of us are working on software where an attacker can steal from huge numbers of users at once if they manage to sneak some wallet stealing code in. We need better code signing practices, but they don't help without some way of being sure the keys signing the code are valid. SSL and certificate authorities have advantages, and so does the PGP WoT, so use both. FWIW I take this stuff pretty seriously myself. I generated my key securely in the first place, I use a hardware smartcard to store my PGP key, and I keep the master signing key - the key with the ability to sign other keys - separate from my day-to-day signing subkeys. I also PGP sign emails regularly, which means anyone can get a decent idea of if they have the right key by looking at bitcoin-development mailing list archives and checking the signatures. A truly dedicated attacker could probably sign something without my knowledge, but I've certainly raised the bar. Just out of curiosity, could PGP keyservers suffer from a similar 51% attack as the bitcoin network? -- 'peter'[:-1]@petertodd.org 016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518 -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
On Tue, May 14, 2013 at 09:16:28PM +0200, Melvin Carvalho wrote: FWIW I take this stuff pretty seriously myself. I generated my key securely in the first place, I use a hardware smartcard to store my PGP key, and I keep the master signing key - the key with the ability to sign other keys - separate from my day-to-day signing subkeys. I also PGP sign emails regularly, which means anyone can get a decent idea of if they have the right key by looking at bitcoin-development mailing list archives and checking the signatures. A truly dedicated attacker could probably sign something without my knowledge, but I've certainly raised the bar. Just out of curiosity, could PGP keyservers suffer from a similar 51% attack as the bitcoin network? What guarantees do you think a keyserver provides about the keys it returns? -- 'peter'[:-1]@petertodd.org 0142ad32a203b1627bee8126fa4bcd940b0da3f32bf1b5b07a24 signature.asc Description: Digital signature -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
On Tue, May 14, 2013 at 9:16 PM, Melvin Carvalho melvincarva...@gmail.com wrote: Just out of curiosity, could PGP keyservers suffer from a similar 51% attack as the bitcoin network? Well, no, and yes. It doesn't work like that. If you have your own domain, you can store your key there as a TXT entry. $ dig +short harald._pka.schil.ly. TXT and even use it automatically: $ gpg … --auto-key-locate pka -r email@address.domain H -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote: Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. [...] [...] Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. Yes but thats inferior in the sense that it is spamming the bitcoin payment protocol slightly, to the small reward of miners, and involves actual money and traceability to real-name (where did you get the coin from to spend). If alternatively you just proof you direct mined on a block with a coinbase that immediately makes payment to future miners its better because: a) you can do that with no new traffic for the bitcoin network (except when you mine a whole block, you'll post it); and b) anyone with a reasonable verification on the blockchain head (even if the spender has to give it to them!) can verify it without any other network traffic; and c) if its micro-mined on the spot it can be bound to the service whereas if you give it to fees as an on network transaction you are limited to values above the min tx fee. So idealy I think you need to be able to simultanously mine and give reward to future block miners. What you could do with out that is d) mine for the reward of bitcoin foundation/software author/or service provider. In the last case (service provider) its an extreme form of Rivests peppercoin probabilistic payment Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
On Tue, May 14, 2013 at 09:39:46PM +0200, Harald Schilly wrote: If you have your own domain, you can store your key there as a TXT entry. $ dig +short harald._pka.schil.ly. TXT and even use it automatically: $ gpg … --auto-key-locate pka -r email@address.domain Nice. But we all kow about the security of DNS ;) Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
