Topic: Proposal : standard transactions for security/backup/escrow - page 2. (Read 5423 times)

So part of the discussion is about the length of acceptable keys, which would help drive the format for these multi-sig addresses.     Casascius... you mentioned in another thread that you actually type some addresses in by hand.  What is the reason for this?  So far, I have never needed to do it myself, and was wondering if you have special requirements, or if we anticipate a common scenario that people would be copying by hand (i.e. typing).  If so, then perhaps it's not ideal to push the multisig approach with long addresses.  It's okay if it's done occasionally, but if there's a common scenario that most users would run into semi-frequently, we probably should focus on keeping them short.

Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
2 KeyA KeyB 2 OP_CHECKMULTISIG OP_DUP OP_NOTIF KeyBackup OP_CHECKSIG OP_ENDIF

Yep, it's a great idea.

I could see a case for limiting it to very specific syntaxes - such as (A AND B) OR C plus a few others with specific identified uses - so that the flowchart for deciding "is this payment mine" doesn't become infinitely complex.  For example, the client who receives this transaction and only has key A needs some way to clearly display to the user these funds are "yours" but are encumbered.

In addition to (A AND B) OR C (wallet protection scenario), I could also see (A AND B) OR (C AND D) being useful.

Phew.  Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.

All the rest (new address format?  send to old addresses and immediately resend?  etc etc etc) can be argued to death later.

I think it does help, in general, to consider how users could/would use these transactions, and then the message formats can be designed to accommodate.  But, upon rereading the original thread, I see that I slightly mis-understood the original intent of Gavin's proposal.  He's looking more for how these transactions will be encoded in the blockchain, not how people will use them.  So yes, my post was a little off-topic.   Feel free to ignore it then.  I'll recycle those mock-ups for a more-appropriate thread.

I see Casascius' point about changes to the OP_CHECKSIG improving the original request, but I don't think it precludes us from needing to have to come up with standard formats that don't use casascius' improvement.  Casascius' suggestion simplifies a lot of things, but does require all parties to be manually notified that they are part of a given transaction.  This may not always be preferable, and I think we have to accommodate more-explicit transaction types that are already possible, anyway (and to be used sooner than we can implement Casascius' suggestion).

In other words, I am siding with both, here:  I'd like to see casascius' change vetted and implemented if it seems secure (although nested scripts might open some very creative security problems, I don't know for sure).  But I think the original proposal Gavin presented still needs to be addressed.  In that regard, I'm not concerned about long strings.  Unless someone has a specific, common use-case that I'm not familiar with, addresses are almost always communicated via copy-and-paste into email/IM, or through QR code scans.  In this case, I don't see how it's really relevant how long it is, probably as long as it doesn't exceed half the length a QR code can handle (which is about 3 KB).

In the interests of my being critical in an unbiased fashion, I must mention that I think etotheipi and theymos' most recent posts on this thread are also offtopic.


To quote Gavin again
He specifically mentions that the implementation may require a new address format which is outside the scope of this discussion.


In that case, you have nothing, apart from your approval to contribute to this thread.
The thread is about what you term "the first proposal", as what you term "the second proposal" was never proposed.

If you look at the comments on the document Gavin linked to, you can see that there was plenty to talk about and correct regarding his proposal which you deem uncontroversial.

This thread is intended to attract more critical attention to the proposal so that any problems are corrected.

Your suggestions with regards to an a new address format would be welcome but probably more appropriate on another thread.

ByteCoin

With reference to Gavin's first post on this thread
I think that casascius' recent post is offtopic for this thread and should be moved to casascius' "Modify OP_CHECKSIG" thread

I will delete this message after the move.

ByteCoin

Just for comparison's sake, here is what the user experience would be if the modified OP_CHECKSIG proposal were accepted.

Jimbob, who is just an average guy using a wallet protection service, would give out a normal-looking well-formed Bitcoin address to Sally and would receive payments just like normal.

Jimbob is using a version of the Bitcoin client that knows that his funds are encumbered by keypairs A, B (never mind C for now), and that it only possesses the private key for A.  It knows that private key B is managed by a 3rd party through a web service.

When he goes to spend his funds, his client signs the transaction with key A, and ships the incomplete transaction off to the web service for verification.  The web service does its due diligence, example, this particular service sends an SMS to JimBob's cell phone, "You are sending 57.00 BTC to 1xyzabcdABCD123... Reply 1 if OK".

JimBob replies 1, and the webservice signs with B and forwards his transaction on to the network.

Safe for JimBob?  You bet.

Easy for JimBob to understand?  You bet.

Will it pass the media scrutiny and calm them down about how bitcoin is rife with hacking and fraud?  You bet!

Now, key C is what Jimbob printed and stuck in his safe when his wallet was generated.  It is his failsafe against his computer crashing or the webservice going out of business.

I think this is an arbitrary distinction.  Users themselves will need to communicate with their own clients to execute 1-of-2, 2-of-2, etc, transactions.  Providing a standard "code" for these will allow the users to know what they're doing.  If I'm telling my wife to put money in our 1-of-2 or 2-of-2 account, I give her the long code.  If I'm selling stuff on the internet, I use your suggestion (give buyer reg address, move it myself).  The key is to create the language.  People will use it as they feel is appropriate.

For these more complicated transactions, we'll need to come up with terminology and methodology for executing them.  We not only need to create the transactions, but also make an intuitive interface for spending them.   I suggest we make a "proposal" msg that users can import and choose to sign.  Each person can sign and pass the result to the next party.  Once the last party signs it, the client will tell them "This is a valid proposal!"  and be presented with a button for "Broadcast now!" or something like that


Click here for the full-sized image:  http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogs.png

I left off the "save to file" button so it can be attached to emails instead of inline.  Of course, the Base58 there would be the exact serialization of the proposed Tx, with the single input and the proposed outputs.  Don't pry too deep into the details of the attached images:  they're just notional.  

Gavin,

My suggestion to modify OP_CHECKSIG was moved to https://bitcointalksearch.org/topic/m.476689 and is incorporated herein by reference, along with your reply suggesting the idea is incompatible with the desired release schedule and that the expectation of a blockchain fork (presumably by the proportion of solo miners who simply won't ever upgrade) is an unacceptable consequence.  I feel this reply is more relevant, however, to the ongoing discussion.  But feel free to move this reply as well if you feel it's misplaced.

If the idea (or any similar idea with similar consequences) has merit and solves the problem, why not just put it in now, but just not provide any UI for anybody to use it for six months?  Right now, security is the achilles heel of Bitcoin - the user expectation that the client evolve to incorporate useful practical security is vastly greater than the expectation that one should be able to solo mine with a client 4 versions ago.

Creating a new address format - especially a longer one - is going to add to the mental workload of every future user of Bitcoin, and is going to force everyone to upgrade all the same anyway.  Every joe blow user will now have to ask why every other user is giving out two bitcoin addresses, one to stay compatible and one to stay safe.  It will also break the withdrawal routine of every website that dispenses Bitcoins (or again force people to maintain two flavors of addresses).  At some point, a client replacement is going to be inevitably necessary even without changes, because the amount of time it takes to initially populate and validate the blockchain is already growing exponentially, well past inconvenient, and on to the point of becoming monumental and infeasible sort of like CPU mining.

Changing OP_CHECKSIG may not be the particular answer to the problem, but I'd like to submit to you that while this software is labeled as being in beta, the possibility that everyone might have to upgrade their client shouldn't be a dealbreaker, and pales in terms of "social cost" when compared to introducing a new address format. My understanding is the current client allows you to trigger a message informing users an upgrade is needed?  There will never be a better time and we're begging to upgrade.

I don't think it's reasonable to put the burden on the sender (in the general case, at least). The large addresses will be annoying to work with, and fees will be higher due to larger data sizes. There may even be programs made to transform "expensive" addresses into "cheap" addresses by changing the version and removing all but one address.

The recipient should receive on a normal address and then resend to himself with the odd transactions. Then the recipient pays the extra fees, and no one will have to deal with huge addresses. There will be a short period of time when the funds are unprotected, but I don't think this will usually be a problem, and it's worth the benefits.

Clients could make c the base for a deterministic key; derive a series of keys from c, and use them in subsequent transactions.  (given full public key for c, you can derive a series of public keys without having the private key)

Same could be done for the 'wallet protection service' key b -- every time you use b, contact the protection service and ask for a b' derived deterministically from b.  Then b'', b''', etc...

The multi-device use-case I'm imagining:

I sign up with Acme Bitcoin Security Solutions, Inc.  They give me a WalletProtection public key (or bitcoin address, doesn't matter) and a unique-for-me URL.  I put the address/pubkey into my bitcoin client as "Second factor off-device Send Authentication." Or something.
(ABBS also sends me the private key in the mail and tells me to keep it safe in case they go out of business)

Now I want all coins sent to me to require signatures from keys in my wallet AND the ABBS key to spend.

What bitcoin address do I give to people so that all coins going into my wallet have that property?

If it is raw CHECKMULTISIG, then I need to give out addresses containing 2 full public keys.  Which would be 186 characters in base58 and look something like this:
LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3

Using 20-byte hashes and the more complicated 2-of-2 transaction i'm proposing, the address is a more reasonable 61 chars:
2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK

I don't see why it's necessary to support addresses for backup and secure-device transactions. Bitcoin can remember the public keys before they are exported to the backup or device.

With an additional device:
KeyA is a local key known by Bitcoin. KeyB is probably remembered from previous use; if not, it can be transferred in a QR code without much trouble (~90 base64 characters is fine).

With a backup:
KeyBackup is static, remembered by Bitcoin. KeyNormal is a local key.

Excuse me for mangling the quote system somewhat...
The unfortunate thing about this construction is that the emergency key c, kept offline and hopefully never used is likely to be constant over a very long period of time. This results in a dramatic loss of transaction anonymity.

It would be nice to have a ScriptPubKey for c from which it is computationally infeasible to determine whether another similar transaction has the same key c.

Perhaps the funder knows the public key for c, encrypts a random nonce with the key and stores it in the ScriptPubKey with an OP_DROP. The rest of the ScriptPubKey for c requires that the redeemer provide a signature and public key for the concatenation of the random nonce and the redeeming transaction. Could something like this be implemented in the scripting language?

ByteCoin

Sunday at the bitcoin conference I led a little brainstorming session on extending the set of 'standard' transaction types, and I've been picking people's brains via email and IRC chat (and pull request comments) to work through the details.

My motivation for wanting to do this NOW is because it will allow features like:

+ Multi-device confirmation of spends, so if your computer is infected by a trojan it cannot spend all of your coins.

+ Master-key emergency backup, so if you lose your wallet (and all of its backups) you can get the master key from your safe deposit box and recover all of your coins

It will also enable third-party escrow and some other nifty features that aren't as important to me.  The first step in doing all of these things is to work out the lowest-level transaction format and to allow those transactions to be relayed and included in blocks.  That is ALL I am proposing right now (actually implementing something like multi-device spend confirmation will require a little protocol for the devices to communicate, a new kind of bitcoin address that people will send into, etc etc etc).

Working out a common way of doing (for example) 1-of-2-keys-required transactions will make it much easier for sites like blockexplorer to display them intelligently, and will generally make life happier for anybody writing tools that look at the blockchain.

I'd rather not have this turn into a "lets get rid of the IsStandard() check" or "lets re-enable a bunch of currently disabled opcodes", so if you want to talk about that start a new thread.

Current draft proposal is here:
  https://gist.github.com/39158239e36f6af69d6f