Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions bip-0010.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,13 @@ The style of communication is taken directly from PGP/GPG, which uses blocks of

A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line. If that is the last signature required, they can broadcast it themselves. Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP. However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.

== Changelog ==

* 2014-11-26:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2014-12-09 was the date of merge, if that is preferable

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the Changelog entry had been proposed along with the pull request, it would have had the date of when the PR was opened and signed-off by the BIP owner. I don’t think it makes sense for BIP Editors to update a Changelog date before merging a PR to the date of when they get around to merging it — that’d just be busywork. So, the date here feels natural to me as is.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, makes sense. I had understood from other pulls that you were preferring the date of merge, like here: #2167 (comment).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big deal either way

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’s possible that I have not been consistent across my updates in this regard. In that specific case the author had announced a planned date for the merge in advance, though.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. In some cases, like for activation of a process BIP, or if there is a large difference between dates of opening and merging, it may also make sense to focus on merge date?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, in cases where they diverge greatly, merge date seems more reasonable.

** Withdrawn after Armory stopped using BIP10 and no other projects were known to implement support (see [https://github.com/bitcoin/bips/pull/125 bips#125]).
* 2011-10-28:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the only commit or pull I found was 4261991 on this date

** Original Draft published.

== Reference Implementation ==

This proposal was implemented and tested in the older versions of ''Armory'' Bitcoin software for use in offline-wallet transaction signing (as a 1-of-1 transaction). Implementation can be found in https://github.com/etotheipi/BitcoinArmory/blob/v0.91-beta/armoryengine/Transaction.py under the class PyTxDistProposal. However, as of version 0.92 released in July 2014, Armory no longer uses this proposal for offline wallet transaction signing and has moved on to a new format.