Multi-signature transaction interface suggestions

[finway]

It would be awesome if we succeeded at this -- and it's completely within the spirit of Bitcoin to have a system that can be usable without third-parties, even if most users will end up using one.

I dont' think third party can't play a part in bitcoin, when bitcoin can play without third party.

There are third party everywhere: 
SilkRoad is a third party
MtGox is a third party
Bittorrenz is a third party
GLBSE is a third party

[1714175201]

1714175201

[1714175201]

1714175201

[1714175201]

1714175201

[etotheipi]

Why isn't this machine readable?  I find this very easy to parse, and would consider writing code to parse it very elementary.

All of the lines are of the following construct:

Name: Value

Parsing the block is as simple as splitting it on CR/LFs, discarding the comments, looking for a colon on each line, taking everything before the colon as name, taking the rest as value.  And if the line starts with a space, treat it as a continuation of the previous value.

Your suggestion isn't that hard to parse, I agree with you.  But it could be easier -- just think of C++ using ">>" operators to read the data in:  there's going to be a lot of "dead" strings, where the implementer is going to have to count how many fields to skip to get to the next useful field...for every field.  I just think we'd be best to prefer compact and dirt-simple to parse, and let the client make it human-readable.

However, I do like the idea of having comment lines in the TxDP, then the person reading it can just preprocess the block by throwing out all lines beginning with '#' (or whatever comment character is chosen). 

Cutting and pasting text is so much safer than having people open file attachments.

I technically agree with you, but like Mike Hearn said-- that's not going to be the standard use case.  I definitely think the standard should support all ASCII, clipboard-able data (which you have), to support all use cases.  But it should be tailored towards the most common one, which is that average users won't ever be seeing these code blocks.  They will be parsed by client software and presented to the user in the client-specific way.  It may be less safe, but it's going to be by far the most common way for users to interact with it.

It would be awesome if we succeeded at this -- and it's completely within the spirit of Bitcoin to have a system that can be usable without third-parties, even if most users will end up using one.

I dont' think third party can't play a part in bitcoin, when bitcoin can play without third party.

There are third party everywhere: 
SilkRoad is a third party
MtGox is a third party
Bittorrenz is a third party
GLBSE is a third party

I am not saying that third-parties won't be involved, I just want to make sure that it's possible to use this system without third-party services and without needing 3 months experience developing Bitcoin to do it. 

[casascius]

Your suggestion isn't that hard to parse, I agree with you.  But it could be easier -- just think of C++ using ">>" operators to read the data in:  there's going to be a lot of "dead" strings, where the implementer is going to have to count how many fields to skip to get to the next useful field...for every field.  I just think we'd be best to prefer compact and dirt-simple to parse, and let the client make it human-readable.

So you would rather make the data completely unreadable to humans for the benefit of saving about 20 lines of code in the source?

I technically agree with you, but like Mike Hearn said-- that's not going to be the standard use case.  I definitely think the standard should support all ASCII, clipboard-able data (which you have), to support all use cases.  But it should be tailored towards the most common one, which is that average users won't ever be seeing these code blocks.  They will be parsed by client software and presented to the user in the client-specific way.  It may be less safe, but it's going to be by far the most common way for users to interact with it.

So what you are saying, is that because the most common use case doesn't involve looking at this data, we should make looking at it (without an external tool) totally impossible?

If you want the world to buy off on this, it's best to make it user friendly.  Apple and Microsoft didn't get where they got by making things needlessly obscure and geeky.  These are NOT good reasons to intentionally choose a data format that REQUIRES a tool to interpret, versus one that does not.

[etotheipi]

Wow, you took my statements to an extreme that doesn't match what I have been promoting.  I wrote the spec to have human-readable components to it.  I think it's critically important that the block is not entirely opaque.  But I think ease of implementation by developers and handling blocks to be highest priority, with the ability for a human to visually parse it be next.  No matter what, it is still going to have to be signed by a computer, which means it will be parsed by a piece of software that will be presenting it in a much more human-readable form, anyway.  To me, it's not critical to make it "pretty," and we can respectfully disagree about that. 

I'd actually prefer it look a little more code-like and encourage only advanced users examine it by eye.  Not only will humans-reading it never be the norm, but trying to make that the norm opens up small issues with the encodings.  With arbitrary symbols/words in the format, it can lead to deceptive practices of giving people TxDPs that look like one thing to the eye, but turns out to encode something else.

In reality, none of this is critical.  Your way would work fine as long as we add line-wrapping to fit it into 80 columns.  Because I think it's important that it doesn't force horizontal scrolling if it is posted inline in an email or in a forum post. 

 

[casascius]

I wrote the spec to have human-readable components to it.

I may have missed it.  The only human-readable components I could perceive would suffice to inform me that it was a proposed transaction, but would offer no idea what the transaction was.  It looked more like a PGP message.  I see no problem with a PGP message being un-human-readable, since that's the purpose of PGP.  I don't think that virtue applies here.

...With arbitrary symbols/words in the format, it can lead to deceptive practices of giving people TxDPs that look like one thing to the eye, but turns out to encode something else...

Can you provide an example of what a deceptive one might look like?  I suppose the comments could be deceptive, but that could be handled by eliminating or forbidding them.

The transaction block would only contain specific words that are defined by its spec, and only in the sequence permitted by the spec.  Arbitrary words would only belong in comments, if allowed, where they would be ignored.

At a glance, one could read the transaction and quickly see what was proposed.  They would see what is signed and unsigned.

Upon pasting it into their application, a user would see one of only a few possible responses:

1. This is not a well-formed transaction.
2. This is a transaction awaiting signatures.  You can sign it, and then it will be complete and can be executed.
3. This is a transaction awaiting signatures.  You can sign it, but it needs further signatures to be complete.
4. This is a transaction awaiting signatures.  You do not have any of the keys it requires, and cannot sign it.
5. This transaction contains signatures that are not valid.  The transaction may have been changed since it was signed.  Remove the invalid signatures?
6. This transaction is complete but has not been submitted to the network.  Submit it now?
7. This transaction is void because one or more of its funding sources has already been spent or redeemed.

[etotheipi]

I wrote the spec to have human-readable components to it.

I may have missed it.  The only human-readable components I could perceive would suffice to inform me that it was a proposed transaction, but would offer no idea what the transaction was.  It looked more like a PGP message.  I see no problem with a PGP message being un-human-readable, since that's the purpose of PGP.  I don't think that virtue applies here.

...With arbitrary symbols/words in the format, it can lead to deceptive practices of giving people TxDPs that look like one thing to the eye, but turns out to encode something else...

Can you provide an example of what a deceptive one might look like?  I suppose the comments could be deceptive, but that could be handled by eliminating or forbidding them.

My biggest concern is redundant information:  an attacker could lie about the type of input transactions, and/or the output amounts and addresses (among other things).  I can construct a TxDP that has encoded all the outputs going to me, but the human-readable part suggests they're all going to you.  Or, I manipulate the amounts so the number of output transactions look the same, but I've shifted two of the decimal places in the actual transaction to redistribute the outputs more to myself -- hoping you won't notice, because you based your decision to sign it on the human-readable parts forget to examine it closely in your client before signing.

You can avoid this by removing all serialized data, and requiring the developer to reconstruct the output based on just the human-readable parts, but that leaves open the possibility of some clients re-constructing (and thus signing) slightly different transactions, not to mention it requires them to implement more logic to implement TxDP handling.   My proposed serialization contains the exact scripts/tx that we want signed, and the developer only has to blank out the other input scripts to sign their part of it.

I think the human-readable parts should solely be for developers and advanced users that are interested in "debugging" or casually inspecting them, but no one should be trusting the human-readable parts of it if it comes from another party that is untrusted.   

If you look more closely at my serialization, nearly every part of it is identifiable to someone by eye who takes a minute to figure it out.  Most importantly, its "block" form makes it easy to identify where the TxDP starts and ends, fitting into the least amount of vertical space possible.

[casascius]

My biggest concern is redundant information:  an attacker could lie about the type of input transactions, and/or the output amounts and addresses (among other things).  I can construct a TxDP that has encoded all the outputs going to me, but the human-readable part suggests they're all going to you.  Or, I manipulate the amounts so the number of output transactions look the same, but I've shifted two of the decimal places in the actual transaction to redistribute the outputs more to myself -- hoping you won't notice, because you based your decision to sign it on the human-readable parts forget to examine it closely in your client before signing.

My idea is that the human readable part is the machine readable part - what you see is what you get.

The human readable part would be parsed and would deterministically produce a single transaction.  It would have to serialize predictably, otherwise the signatures would have no meaning.  Someone who moved a decimal place would be creating a different transaction and would invalidate all of the signatures.

The only thing that would require mandatory validation in the client is the keys and signatures themselves.  One cannot determine just from looking whether or not they are valid, but the worst case scenario is that a funding source that looks "signed" really is not.

I am not sure there is a specific benefit to saving vertical space in this case, especially if it's information relevant to the transaction.  In my mind, I'm willing to actually waste vertical space in the form of whitespace to add clarifying section breaks - but these would be completely optional and not a mandatory part of the spec.  (In the spec the way I imagine it, blank lines would be ignored).