Re: [bitcoin-dev] A BIP for partially-signed/not-signed raw transaction serialization; would it be useful?

[Chris Priest <cp368202@ohiou.edu>]

I approve of this idea. Counterparty has the same problem. Their API
returns a unsigned transaction that is formed differently from how
other unsigned transactions, which causes friction. Someone needs to
write up a specification that is standardized so that all unsigned
transactions are of the same form. Basically the signature section of
the should contains all the information required to make the
signature, and it needs to be encoded in a way that the signing
application (a blockchain library like BitcoinJ or BitcoinJS) can tell
that it is unsigned.

On 1/9/17, 木ノ下じょな via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> I have been seeing issues like the following many times on all the
> different projects that support multisig with users responsible for partial
> transaction transport.
>
> https://github.com/OutCast3k/coinbin/issues/73
>
> I would like to gather opinions before proposing a BIP, (like whether we
> need one or not) so please let me know what you think.
>
> Basically, Electrum, Copay, Coinb.in, Bitcoin Core, etc. all have different
> methodology for serializing partially signed multisig raw transactions, as
> well as not-signed raw transactions regardless of scriptPubkey.
>
> I think we should all be on the same page when serializing not-signed and
> partially signed transactions so that the person could look at the data
> alone and know what is necessary and how to manipulate it to sign and
> complete the transaction.
>
> - Jon
>
> --
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Comment: http://openpgpjs.org
>
> xsBNBFTmJ8oBB/9rd+7XLxZG/x/KnhkVK2WBG8ySx91fs+qQfHIK1JrakSV3
> x6x0cK3XLClASLLDomm7Od3Q/fMFzdwCEqj6z60T8wgKxsjWYSGL3mq8ucdv
> iBjC3wGauk5dQKtT7tkCFyQQbX/uMsBM4ccGBICoDmIJlwJIj7fAZVqGxGOM
> bO1RhYb4dbQA2qxYP7wSsHJ6/ZNAXyEphOj6blUzdqO0exAbCOZWWF+E/1SC
> EuKO4RmL7Imdep7uc2Qze1UpJCZx7ASHl2IZ4UD0G3Qr3pI6/jvNlaqCTa3U
> 3/YeJwEubFsd0AVy0zs809RcKKgX3W1q+hVDTeWinem9RiOG/vT+Eec/ABEB
> AAHNI2tpbm9zaGl0YSA8a2lub3NoaXRham9uYUBnbWFpbC5jb20+wsByBBAB
> CAAmBQJU5ifRBgsJCAcDAgkQRB9iZ30dlisEFQgCCgMWAgECGwMCHgEAAC6Z
> B/9otobf0ASHYdlUBeIPXdDopyjQhR2RiZGYaS0VZ5zzHYLDDMW6ZIYm5CjO
> Fc09ETLGKFxH2RcCOK2dzwz+KRU4xqOrt/l5gyd50cFE1nOhUN9+/XaPgrou
> WhyT9xLeGit7Xqhht93z2+VanTtJAG6lWbAZLIZAMGMuLX6sJDCO0GiO5zxa
> 02Q2D3kh5GL57A5+oVOna12JBRaIA5eBGKVCp3KToT/z48pxBe3WAmLo0zXr
> hEgTSzssfb2zTwtB3Ogoedj+cU2bHJvJ8upS/jMr3TcdguySmxJlGpocVC/e
> qxq12Njv+LiETOrD8atGmXCnA+nFNljBkz+l6ADl93jHzsBNBFTmJ9EBCACu
> Qq9ZnP+aLU/Rt6clAfiHfTFBsJvLKsdIKeE6qHzsU1E7A7bGQKTtLEnhCCQE
> W+OQP+sgbOWowIdH9PpwLJ3Op+NhvLlMxRvbT36LwCmBL0yD7bMqxxmmVj8n
> vlMMRSe4wDSIG19Oy7701imnHZPm/pnPlneg/Meu/UffpcDWYBbAFX8nrXPY
> vkVULcI/qTcCxW/+S9fwoXjQhWHaiJJ6y3cYOSitN31W9zgcMvLwLX3JgDxE
> flkwq/M+ZkfCYnS3GAPEt8GkVKy2eHtCJuNkGFlCAmKMX0yWzHRAkqOMN5KP
> LFbkKY2GQl13ztWp82QYJZpj5af6dmyUosurn6AZABEBAAHCwF8EGAEIABMF
> AlTmJ9QJEEQfYmd9HZYrAhsMAABKbgf/Ulu5JAk4fXgH0DtkMmdkFiKEFdkW
> 0Wkw7Vhd5eZ4NzeP9kOkD01OGweT9hqzwhfT2CNXCGxh4UnvEM1ZMFypIKdq
> 0XpLLJMrDOQO021UjAa56vHZPAVmAM01z5VzHJ7ekjgwrgMLmVkm0jWKEKaO
> n/MW7CyphG7QcZ6cJX2f6uJcekBlZRw9TNYRnojMjkutlOVhYJ3J78nc/k0p
> kcgV63GB6D7wHRF4TVe4xIBqKpbBhhN+ISwFN1z+gx3lfyRMSmiTSrGdKEQe
> XSIQKG8XZQZUDhLNkqPS+7EMV1g7+lOfT4GhLL68dUXDa1e9YxGH6zkpVECw
> Spe3vsHZr6CqFg==
> =/vUJ
> -----END PGP PUBLIC KEY BLOCK-----
>