The offline double-spend of Chaum reveals identity.  Brands also has a mechanism to do that (reveal private key and all attributes, one of which could be identity).

Other than these advanced ecash protocols, the one-show signature idea is quite simple and somewhat general (eg can be applied to an ECDSA signature) and can reveal the private key if the user double spends.  That would be an alternative mechanism to deter double spending (rather than one coin coming first as voted by miners), you can go ahead and double spend, and the miner will take your coin (because anyone can compute your private key if you double spend, they can create a third spend where the miner pays himself, and mine that.

All you have to do is with ECDSA there is Q the public key and r,s the signature; to leak the private key on double spend if you define the public key as Q,r and the signature as s, the signer is forced to reuse k (as R=kG, r=R.x) and if you reuse k with different messages you reveal a simultaneous equation allowing the private key to be computed.

s=k^-1(h(m)+rd)
s2=k^-1(h(m2)+rd)

=> sk = h(m)+rd, s2k = h(m2)+rd => (s-s2)k = h(m)-h(m2), k=(h(m)-h(m2))/(s-s2).
then sk=h(m)+rd => d=(sk-h(m))/r

An address would then be addr=H(Q,r) signature would be Q,r,s and signature is not valid unless addr=?H(Q,r) and sR =? h(m)G+rQ  

The main problem with doing that in bitcoin is if you accidentally send twice (because your client crashes) you lose money.  And people keep reusing addresses.  These extended addresses would "discourage" address reuse (which some would say is a good thing:)

But there is a concept of a limited-show signature where you can spend n times but not more, just define r1,r2, ... rn and you are allowed to use any of those; but if you use one twice your private key leaks.

For bitcoin also you could put the recipients r choice in the transaction (allowing Q to be reused, across different tx, but a single r to be used once for the tx).  Unfortunately that inconvenient as the recipient must choose r.

Adam

Well starting with n-of-n Schnorr, the difference is no k^-1 value complicating the math.  DSA is a complexification of Schnorr, probably as an attempt to avoid Schnorr's now expired patent.  Schnorr is simpler, has better security proofs (possible because its simpler) and makes weaker assumptions about the hash function (ie tolerates a weaker hash, or more slips in hash function properties without breaking the signature, aka DSA stresses the hash function more).

The simplicity makes it easier to do blind signatures, and n of n, k of n etc.

Comparing ECDSA and ECSchnorr (with relabeling to highlight similarities):

ECDSA: R=kG, [r=R.x, s=(H(m)+rd)/k], Q=dG verify: sR=?H(m)G+rQ
ECS:     R=kG, [r=R.x, s=k+H(r,m)d],    Q=dG verify: sG=?R+H(r,m)Q
ECS-alternate: R=kG, [c=H(R,m), s=k+cd], Q=dG, verify: c=?H(sG-cQ,m)
(because kG=sG-cQ)

(And both ECDSA and ECS can use deterministic variant where k=H(m,d)).

so with ECS if you have users with pub keys A=aG and B=bG (priv keys a,b) they can make a sig with  their combined key Q=A+B simply as

R1=k1G, r1=R1.x    ->r1
                              <= r2,s2       R2=k2G, r2=R2.x, s2=k2+H(r1+r2,m)b
s1=k1+H(r1+r2,m)a, r=r1+r2, s=s1+s2

as r1+r2=k1G+k2G=(k1+k2)G, s1+s2=(k1+k2)+H(r1+r2,m)(a+b)

QED.  (That was just figured out from scratch, maybe there are some other nuances).  k of n would have to look up or think harder.

So then unlike with the blind ECDSA method you proposed by choosing a public key relating to k, (and I was thinking ok with that you can 2 of 2 most likely, and sure enough https://bitcointalk.org/index.php?topic=511074.0 the OP put that together), with ECS
you can do it more simply and with normally chosen pre-existing keys (and without having to do one-use signatures.)  

A risk with R=kG being fixed that is a one-show signature, meaning if you accidentally (eg due to non transactional storage on the client) sign two different messages, you leak the private key, and allow miners to take your coin.  (Considering one-show signatures, where Q'=(R=kG,Q=dG) so k is pre-committed as a double-spend model ie then you cant double spend without giving both spends to the miners has the same problem with accidental double-spend and transactional client storage requirement to avoid).

Adam

I moved this question about risks with turing complete scripting to this thread on turing complete / ethereum and added some comments.

https://bitcointalk.org/index.php?topic=431513.new#new

Adam

From another thread:


They address halting by fee paying for interpreter cycles.  When the fee runs out the contract is stopped.

But there are obviously interpreter escape dangers, which are harder to contain for a stateful, looping, low level (byte code like) language.  Look at the history of java sandbox escapes.  People say that was mostly due to call outs to complex native library have to look through the (large!) CVE database on JVM to figure out the stats.  Also the pressure may have been lower.  If you get real money under it all kinds of resources and unrevealed 0-days can leak out of the woodwork and create the new target for grey and black hats some of whom are world class at this stuff.  Or even from national security network intrusion insiders with Snowden-level access or the people developing and selling grey market 0-day to the intelligence community etc.  Those people are fallible humans too - they may succum to the financial motive, or the people who developed and sold them the 0-days may find a new monetization model, or second use for them (they cant "forget" them after sale).

There have also been VM escapes from full hw abstraction vms (i mean not just API sandbox light linux-in-linux virtuozzo but actual whole OS in the container).

And finally bitcoin scripting is functional, stateless and non-looping (non TC in fact also) for a reason.  Bitcoin doesnt (and I think its intentional) have even extrospection.  There are grey-goo outcomes if you are not careful with even something as constrained as an extrospection op code to existing language.   There will be whole classes of not yet imagined grey goo opportunities lurking in a full TC language.  You cant easily systematically defend against whole classes of such issues without intentional constrained language.

Here's a thread started by Greg to explore grey-goo outcomes from extended scripting:

https://bitcointalk.org/index.php?topic=278122.0

Greg Maxwell also noted the elevated risk of forks developing.  If there is any deviation in script outcome and being more complex there is more risk there also.  eg tracking how many cycles through a JIT executed/CSE optimized etc version as super-majority of nodes MUST interpret the script to the same byte code instruction, or one version can return true, another false etc.

I discussed these risks with Vitalik and he is a very smart guy, so obviously they'll try to do what they can to contain them, but you know bitcoin is the highest assurance sw dev and QA risk on the planet by orders of magnitude.  So it maybe a time for risk containment rather than risk LoC and API size expansion, I am already worried on bitcoin about base band-processors hacks, 0-day OS and CPU hacks, and thinking a more zero-trust more air-gap model needs to be the objective.

If hypothetically ethereum grew to large adoption (litecoin level say) and then there was enough motivation and something failed hard, there are potential whole system value loss, hard fork and other failure modes.  It seems to have by design, ongoing higher surface area security & value safety risk

Also btw Dan Kaminsky said he spent 4 months trying to hack bitcoin (network stack, overflow on messages, the usual host-security 0-day discovery process) and he failed.  He's one of the best host security guys and the experience impressed him.  Its not a simple thing to make a network stack that bullet proof, most even hard core programmers cant do it.  You probably have to practice 0-day development to some depth to even understand fully the risks and defense landscape.  Bitcoin got there with a really solid start from Satoshi and a bootstrap period where other bugs were fixed before the pressure built up to $10b.

I am not going to comment for now on the funding model  They are somewhere between the others and I am sure Vitalik has his eye on actual innovation as well, because knowing him he lives for tech challenge.

I think anything that needs to be done, can be done in a bitcoin centric backwards compatible evolutionary way using eg 1-way peg and other related features while maintaining value firewalls between long term holders and people using newer features.

But clearly other than the security containment, zero-defect in flight once live, and grey-goo risks, Ethereum can create some fun self-extensibility with a loose analog of like introspection, late binding, eval and dynamically loadable code languages.  We do have to be clear that the cost is the towards opposite end of the spectrum, though lower than activeX and executing native code delivered over the network.  Fun possibilities but a big security job.

Adam

I see I dont think I realized that aspect of how bloom query works.  So you then with IBE-based filtering could send multiple keys, one for each block; but you are implicitly linked by being in one query, so you'd just as well mark your key with your preferred epoch size and sender uses epoch number in the query.

I think Greg is pointing out on IRC that by having a fairly small epoch you can choose later to go down to that epoch size or scale up by sending multiple epoch keys in a batch, a privacy/network round-trip trade off.

Re my other problem with epochs ("In practice you might need an epoch not block or overlapping test because the user does not have full assurance of their tx ending up in the pending block") I think that maybe fixable, if the blocknumber is chosen by the sender, and communicated in enough bits to be mostly unambiguous in the message.  Then the node can index them by sen block num and no ambiguity.

It could be that another way to partly obscure ownership of queries would be to relay queries and responses and mix other peoples queries with your own in a batch, however as we are considering the SPV client case relaying other peoples queries seems hard to gather query traffic on demand and to use more bandwidth than it saves relative just issuing smaller batches.

You could have relaying in the network eg using the embedded Tor but waiting for queries to mix with adds latency, and suffers flood attacks on mix-nets (send fake encrypted query traffic to flush out a tx, that has no-anon set vs the person doing the flooding who can distinguish their own queries).

Adam

So have been talking with Greg Maxwell, Peter Todd, Jeremy Spillman, Mike Hearn, Bytecoin and others about reusable addresses.

There is a summary of the situation here http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03792.html and I had posed th question of whether it was possible to do better at all with Peter Todd:


and Peter proposed also the related problem of proving something about that existence or not of a solution to that problem. 

I think I have a proof-of-concept solution that proves by example we can do better in space efficiency, linkability defense and non-interactivity than my bloom bait, Peter Todds related prefix; and Greg Maxwell's extended bloom bait described http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03705.html.

So the idea is to use an IBE scheme as a building block in analogous way to my 1996 problem statement for NIFS and 1998 observation that a novel use for an IBE scheme can provide a generic solution to NIFS, and the arrival in 2001 of the first efficient / sensible trapdoor steepness (*) IBE with the introduction of the Weil Pairing problem by Dan Boneh and Matt Franklin described here http://en.wikipedia.org/wiki/Boneh%E2%80%93Franklin_scheme.

Greg summarized IBE as follows on IRC:


Basically as Greg said your public key is your address (an email address, a block hash, whatever is convenient and unique) and from that and the master public key of the IBE server, the server can compute a private key corresponding to that.  The master public is usually considered to be a system-wide domain parameter.   Naturally enough because a side effect of this is that the IBE server can decrypt everyones email people were never too excited about the prospect.

However my 1998 NIFS observation is by acting as your own IBE server (each user creates their own master public server key) they can create a sequence (NIFS) or set (bitcoin reusable address) of public keys with interesting and publicly derivable properties!

It is my conclusion from 1996 that to solve this with DL directly at least in the NIFS case appears to be not possible.


So basically the reusable address becomes an IBE public key, the existing public derivation via DH or EC Elgamal/ECIES or whatever variant (bytecoins, mine, Peter Todd/Amir Taaki's) arrives at a factor that can be recovered.  So with my variant (random sender generated multiplication factor encrypted with ECIES) you could encrypt the factor with a pub=IBE-extract(master pub, id=previous block hash) using the previous block hash as the "identity" and the users own self-owned IBE "server". 

For Bytecoin & Peter Todd/Amir Taaki EC DH version using input or auxilliary addresses to save space its not even necessary to send the factor, its already sent.  So then you send a separate message to do with secure delegatable filtering, a more secure/more space efficient bloom filter/prefix replacement, and this is a more flexible structure.

So the secure delegatable filter is you separately add an encrypted bloom bait Greg suggested (eg 1byte prefix communicated with public address.)  And you can even combine that with Greg's extended bloom bait above to add anonymity set within the block.

Consequently you can now securely and very network/space efficiently securely delegate searching a block by computing the private key for the IBE pub key that any sender would use for that block, and sending it as a query to a random (or node-capture defended random selected node).  The node can decrypt the encrypted bloom baits with it, but remains powerless to correlate with bloom baits to other payments received by the same user in bother blocks.

(In practice you might need an epoch not block or overlapping test because the user does not have full assurance of their tx ending up in the pending block).

About weil pairing, and new hardness crypto risk, this is also the hardness assumption under some ZK-SNARKs as I think used in zerocash, and while ZK-SNARK introduces its own complexity/crypto system risk on top; in my view weil pairing is slightly lower assurance/review not so widely used relative to EC DL problem.  Anyway the interesting thing to say about that is in the event this scheme got broken in the future it falls back to the scheme that is being proposed using prefix.  Ie its no worse than that from linkability and likely would retain some cost even if broken-- asymmetric crypto breaks are usually somewhat gradual.

This looks more expensive and non-indexable though I didnt look to see if there is any ciphertext only or batch precomputation that could be squeezed out of it.

Obviously its more CPU intensive and some eg fee mechanism to prevent node DoS could be nice, but it seems to demonstrate a proof by existence that it is possible to do better.


Finally I think it maybe within possibility to do further than this because it is not technically necessary to delegate decryption, only to delegate filtering, which can be a simpler requirement.

Adam

(*) There was an earlier scheme by Maurer et al if I recall, but to get a 1024-bit security margin you had to perform a discrete log attack on a 512-bit prime, so the key generation cost was immense, hence "sensible trapdoor steepness" thats very shallow in tems of work difference between setup cost and crypto system strength.

Forgot to link that topic.  You can see the comments yourself below threads (positive).  1-way peg doesnt need any bitcoin main protocol changes we could do it now.

A new even better but bitcoin-main change-requiring variant figured out since.  And someone who can comment if they wish said on #bitcoin-wizards IRC (about the hard fork of this variant) that a) maybe it can be done without a hard fork, and b) anyway its the "one change to rule them all".  Ie after you've done it, other changes can happen on a pegged merge-mined side chain with no bitcoin main security risk.

Bitcoin-dev threads see comments for yourself (thread comments are at visible at the bottom of the pages):


Dont think there is a forum thread on the specific subject of the long list of EdDSA (EC Schnorr) security/flexibility/compactness advantages, though Greg Maxwell has been exploring it for those and performance reasons.  There were some open questions for Dan Bernstein which he hasnt replied to yet.


and as I said EC Schnorr (EdDSA) also supports blind signatures, which are not so far known to be possible with ECDSA.  CoinJoin uses blind signatures based on RSA I think, so it'd be nicer, faster, more compact, to use the native EC Schnorr blind sig.

EC Schnorr also makes possible wallet with observer (Stefan Brands concept) which allows a hardware wallet to be made subliminal channel free (wallet prevents offline double spend up to tamper resistance but cant mark coins nor leak private key).  But I spoke about a more advanced wallet observer, what I described (on the podcast) is actually a use of Brands issuing protocol to extend wallet observer so the wallet can sign a transaction and has a ZKP that the subliminal channel free signature it is making is bound to the message it can then display on the bigger hw wallet screen.

Subliminal channel free means the wallet has no way to leak the private key even if it is malicious (short of having a radio emitter inside it)

Adam

A podcast from letstalkbitcoin where I am talking with Andreas Antonopulous: maybe a better summary of the committed tx & homomorphic value, the threads here were full of crypto-math and perhaps hard to decipher, also fungibility/red-list & tx-cost and how that relates to indentity and privacy; also hashcash, decentralization, coinjoin/payment protocol, zerocoin/zerocash, some history.  1h45 of "light" listening

http://letstalkbitcoin.com/e77-the-adam-back-interview/

Some bitcoin talk links to the topics discussed:

Committed transactions (that really needs a summary top post, too much design evolution through it):
homomorphic values:

fungibility, identity & privacy

hashcash


coinjoin

zerocoin

Mentioned some 1998/1999 cypherpunks posts by Wei Dai, Hal Finney & anonymous (Satoshi or not unclear).  The links are at the bottom of this:
Enjoy

Adam

Apparently forum user bytecode proposed something related to this in the past.

Some update on this.  I had discussed on IRC the idea of using a 'bloom-bait' to make this a little more SPV friendly, eg by including the last byte of the public key, but it does erode the anonymity set though.

Alternatively one could make a separate pairing message with no inputs (other then anonymous unlinkable fee for anti-DoS) to send E.  In this way the pairing message sends E(Q,c') (actually deterministic c' for idempotency/crash recovery reasons).  And c' becomes the shared chaincode for a normal BIP 32 HD sub-wallet specific to sender-recipient pair and secret to them.  There is some risk of time correlation of pairing and first payment are made immediately, and some risk of failure due to non-communication of the pairing message, meaning the recipient does not know c'.  This part is not ideal, sending a single combined message is preferable but incurs trial-decryption and a full node, or a delegation to a full-node that learns the chain-code and does the trial decryption.  Probably one could delegate trial decryption to a full node, and the payload is a super-encrypted chain-code.

I am not sure if its analogous to bytecode's idea or not (didnt find the original), but retep also proposed on idea another variant of this same idea: to use static DH for the encoding instead of EC Elgamal (aka ECIES), which is basically centered on the artefact that the paired users dont care to choose a chaincode, a random, negotiated one would do.  For that eg the sender has a public key from an input say P=eG, and the recipient has public key Q=dG, then they use ECDH to arrive at shared code c'=H(eQ)=H(dP).  retep called this a stealth-address, so using BIP 32 it creates a sequence of HD addesses as Si=M(c',i), and the recipient compressed address is S'i=H(Si) so the recipient with a full node can scan for these.  Or delegate scanning to a full node.

Again an explicit bloom-bait tag could be used to reduce scanning at the cost of anonymity set.  To make it backwards compatible retep suggested to grind the address to give it a prefix with the added bonus that many tools already keep address prefix indexes.  (Address grinding might modify BIP32 to add a grinding counter: Si=M(c',i,ctr)).  That does imply some grinding cost which slows things down, but its somewhat backwards compatible and arguably indistinguishble to some extent.  Ground address prefixes, or explicit bloom-bait tags, may have adverse effects on CoinJoin as the tag/mark is visible and anonymity set reducing.

To my way of thinking therefore there are still gaps in the viability of this approach.  While it is quite attractive to have a safe way to have static base addresses with sender derived addresses or chain codes, it is not so far scalable to light nodes.  But if a way can be found to make this scale to light nodes without introducing an anonymity set problem it could be a big step forward as seemingly users on a recurring and on going basis dont understand and dont like single-use addresses on the receiving end.  Clearly single use addresses are problematic.

This approach above could work for recurring business things like exchanges, payment processors etc as those entities are typically running full nodes anyway.  You could say those entities anyway
have the infrastructure and communication pattern to support HD sub-wallet addresses.

There is one additional advantage of sender derived addresses: the recipient has a global shared static address so it can act as a trust anchor to ward off diversion attacks in a simple and space efficient way without signatures.  It can act like an SSH TOFU (trust on first use) fingerprint.  Users can compare fingerprints, call up the company, expect the fingerprint advertised on all official emails, SSL static content web site, business cards, trust directories, PGP signed by key employees etc.  (Diversion attack meaning where someone hacks a server and replaces the addresses with their own).   Furthermore people can check that fingerprint in their offline wallet for investment level amounts.

Adam

[edit: NB for this general scheme to work, the recipient needs to advertis an uncompressed address, ie the x-coord of Q, rather than H(Q).  That might even be compatible with older uncompressed BTC addresses, I am not sure]

I mentioned a few times that there were 1997 (hashcash) and 1998/1999 (b-money) posts and discussion about how to build digital scarcity and control inflation on the cypherpunks list.

I was just reading some of them, hadnt notice this one last time I looked and it is quite nice (anonymous):

http://marc.info/?l=cypherpunks&m=95279521221935&w=2


(Anon seems to take as a given that b-money would be able to technically solve inflation - the way Wei Dai described it the servers would vote on how much money to create and the cost of creating it per time-interval.  Personally I found that prone to human gaming & abuse, eg might people with limited money at stake vote for "lots" and "cheaply" for the two parameters)

So he is referring to the b-money property of supply being increasable by vote amongst servers, but assumes that will remain low and benign.  I am not sure this confidence is justifiable - it depends on the motives and interests of the server operators.  Maybe he is assuming server operators would be unlikely to agree on > 1% supply side inflation or greater than human population growth %, in a mature deployment.

This one also appears bullish that b-money can be improved:


http://marc.info/?l=cypherpunks&m=95280154630156&w=2


(Again as stated b-money would have allowed on-going supply side inflation according to an average of server voter-for rate at a creation cost based on average vote-for difficulty).

(Found those with search term b-money from http://marc.info/?l=cypherpunks which finds several threads).

Adam

I didnt so far find a way to do it with ECDSA, but that is not a proof.  Also there exist other crypto schemes that are self-reblindable (without knowing the private key).

But it seemed to be rather than relying on this additional and perhaps not designed for property of signatures non-malleability (of the anti-malleability-canonicalized serialization) that maybe longer term bitcoin could include the public key in the hashed data rather than the signature.  By definition the signed data must also be unique as txins are spent in full.

We were also talking at the physical meetup about possibility to fix the malleability before forwarding and Greg had mentioned this as a work-around used by blockchain.info as they were unable to modify their wallet due to apple's regressive policies.

Adam

I am not sure.  One thing you could say is if amounts are encrypted maybe you dont so much need lots of addresses.  However I think encrypted amounts isnt quite enough, you probably need like to hide who is paying as well as hide the amount before that becomes convincing enough to say you only need one address.  Then it could save some UTXO space as you only need one unspent address per user for privacy.

Adam

I think eg if you read the original zercoin paper and I said similar things on bitcointalk that anonymity is the ideal building block.  What you can build with it is many permutations of desired and useful privacy levels.  It doesnt have to be full payee & payer anonymous just because the building block supports that.  And there are many reasons in the real world that you dont get that privacy in practice.  IP logging, IP geolocation, physical shipping address, knowledge of you by the person you are paying/receiving from, privacy mistakes etc.



Kind of odd if you are sitting on the holygrail crypto and not publishing for some kind of ethical considerations?  Really?  Technology is neutral and this technology can add many useful permutations of privacy to bitcoin.  I'd sure publish it immediately if I had figured it out and feel I did a good thing for society.

Maybe you want also to read this post by Greg Maxwell explaining why privacy is important for society and commerce.

https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908

I think you get that also because as I understood it you explored anonymity because of your interest in card gaming to prevent collusion being used to cheat.

ps Personally I think gambling has far more ethical worries than users being able to transact privately with something approaching the analogous already existing levels of privacy in other systems.  For some people gambling becomes a near ruining addiction.

Adam

Yes you are right.  It was written in great haste as I was leaving, figured this out shortly afterwards.

The problem is the network can be expected to cache your correct password result after KDF.

Therefore the only thing this could be good for is a one use signature (eg a big stash that you dont touch except once to sell it).

Or if you have a seed encrypted 1000 times with each different salt and the same password, and you securely delete the respective encrypted seed after each use.

50 choose 100 doesnt seem to help that picture.


I think the Rivest & Wagner time-lock puzzle (which I extended with blinding) might be somewhat memory hardenable if one used bigger RSA key than necessary for security.  Not really tried to analyse it from that perspective so far, there may also be some parallelization opportunities or TMTOs.

The basic RSA blind signature is rather simple, eg used in the coinjoin protocol right.  The blinding variant I use for blinding the time-lock puzzle is quite similar.  Maybe it wouldnt be so bad if a simple reference implementation in OpenSSL were provided.

Adam

But I think you can do it by making 100 KDFs, and add 50 of them together mod n.  Then you shuffle them send all 100 to the network, it does the KDF stretching which is expensive, sends the 100 back to you.  You pull out the 50 that are correct combine and decrypt.

https://bitcointalk.org/index.php?topic=330819.msg3548144#msg3548144

what makes it hard is the network doesnt know which 50 of 100 which is work ~2^128.  There is no closeness metric so you have to brute force.

Adam

You do have the key.  My point is you can do it fast before you delete the salt.  After you delete the salt it becomes hard as you have to search for the salt.

You do not need to do work when you create the key.  Only when you decrypt it.


Replying to gmaxwell now I have another idea.  Secure offload with symmetric crypto no blinding.

Adam

Ilja Gerhardt & Timo Hanke's Pay-to-Contract Protocol http://arxiv.org/abs/1212.3257 is something else that could be done which is somewhere in between signed addresses and payment protocol.  I think signed addresses could be used in both protcols.  The point is the signed address can be more offline and control that the payment at least goes to the right entity with offline security.

Adam

Bitcoin irrevocability & fungibility is cool and one of the main benefits of bitcoin.  However the cost is stealing them constitutes the perfect virtual crime, and so the level of APT attacks will surely rise to new proportions against both user machines, and bitcoin processors.

Now one step towards making bitcoins hard to steal is offline wallets (armory & trezor) where the remaining remote threat is almost removed (subject to very few lines of code in usb drivers and the attack vector of the protocoin sent to the offline device for verification and signing).  Given the stake the lines of critical code can be minimized and audited.  This is  robust starting point.

However the remaining issue is, while you can receive bitcoins securely over an air-gap, and pay from an offline wallet using usb or QR code, your ability to securely communicate addresses for receipt via the users online computer is questionable.  Targeted bitcoin malware can win this race (show you what you want to see, but send a different address to the sender via local SSL backdoor, app patches, OS patches etc).

Similarly security of the online payment processor's environment is in question.  They can use host security experts, best practices etc.  But still there is the 0-day and the APT attack, but surely it will escalate to a new level.  And the payment processor despite hot-wallet / cold-wallet trade-offs is an increasingly valuable target.  Malware on the payment processor can send users the attackers address for "deposit".  It can steal the hot-wallet.  It can replace users "withdraw" addresses.  They'll notice but it maybe too late.

The payment protocol https://en.bitcoin.it/wiki/BIP_0070 helps, however that has to be part of the online merchant app because its not just signing the merchant invoice address, its signing the transaction details also.  Likely it will be signed by the SSL web site, though it could be signed with a separate sub-domain.  Lack of a hard requirement for this to be the case makes that assurance weak - an attacker who gains control of the merchant site can sign with the SSL cert key and users wont consider anything amiss.

Also even without breaking into the merchant, SSL certs can and have been hacked, and absent cert pinning, the entire system is as weak as the weakest CA.

So what could we do about this.  

We need to rearchitect for the bitcoin offline wallet security model.  Its fine for the web app layer to best-effort sign the transaction, if one values it for what it is - an assertion by an at risk web app with at risk keys.  (Hardware security modules dont help that much, the app layer still obtains no-restriction signatures from the HSM).

So one more thing that could be done is to use hierarchical deterministic wallets to make a sub-wallet with a shared chain code between the user and the merchant.  For repeat custom or a bitcoin exchange this could make sense.  Then if both the merchant and user keep the chain code off the online machine they can at least be assured that the address is unique to them.  Use out of band security to set this up.  Or use TOFU (trust on first use) so that both sides abort of something changes about the security context.

Secondly it seems to me we could do with something end to end authenticated between the sender and the receiver.  Signed addresses?

Then the sender and the receiver dont need a secret (shared chain code of sub-wallet), they only need an authenticated signing address from the respective online wallet.

Maybe you derive identity assertion keys deterministically from the offline wallet, derived from the receiving parties identity (domain name, email address etc).  And send those to the receiving party during setup, or use out of band for one off.

Privacy, fungibility?  The signatures are not part of the bitcoin transaction, they are just to convince the relying party.  They are not receipts like payment request ack messages, they just show you that the person you expect is the owner of the address with offline hardware assurance.

Because the addresses are not user specific the merchant can upload batches of them from the offline computer.

Could you use abuse the payment request protocol to encapsulate a second signature on an address?  Probably but that seems like a protocol layering violation to me.  Payment protocol is an app level protocol, authenticated addresses are simple, have no external references and gives a stable public handle to authorize.  The hash of chain code of a sub-wallet could do something similar.

In terms of concepts and terminology you could consider the signing address (that signs the one-use addresses) to be an account number.  And the one-use addresses as transaction or invoice numbers that are signed to prove they are owned by the account number.  You can use a different signing address for each recipient to add privacy.  Or a different signing address for each time if its not an identified ongoing relationship.

You can wrap these signing addresses with X509, PGP, SSL, phone call to check, offline address signing key fingerprint on company business cards etc.

Adam

You rely on the custodian who holds the asset as backing for the colored coin (xcc)/mastercoin (msc).  However if the asset represents a bearer share in a company you dont trust anyone.
You know that share buy backs and fresh share issues are not the normal way that you redeem company stock - you redeem it by selling it to someone else.


You are not thinking for enough ahead.  The company transacts entirely in bitcoin, its shares are represented in color coin.  The dividend payment subject to shareholder approval (holding colore shares gives you the right to vote proportionally) and measured against the share prospectus shareholder vote threshold, defines the dividend.  Ownership of the shares definitionally grants you authority over the dividend amount.  The company is powerless to renege.

Same for the entire banking & finance ecosystem and governmental policy.  Its in the constitution (a countries prospectus) they cant change it without a super-majority vote defined as part of the constitution.

This is why smart-contracts are the future.

Obviously second and third generation of scripting is required for such things, but thats the direction IMO.  So you have to architect to that assumption.

Adam

Yifu also responded via tweet.  Now Waters via reddit.  I responded to them on reddit and tweeted also.

https://twitter.com/adam3us/status/402370818232958976

http://www.reddit.com/r/Bitcoin/comments/1qmude/yifu_guo_is_conspiring_to_make_his_own_coins/cdgn3fu

Here is what I put on reddit.


Adam