Use cases.
Навеяно этой статьёй.
В данном посте мультисигнатурные адреса буду обозначать так: {A1,...,An}m или просто {A1,...,An} если n == m.

1. Наследство/резервный вывод.
Создаём и подписываем транзакцию
Транзакцию передаём получателю сразу. При приближении текущего времени к TxR0.nlocktime переводим средства на любой свой адрес (хоть на тот же самый):
и выпускаем новую резервную транзакцию
Для последующих переводов:
Т.к. идентификатором непотраченных средств является (txid,vout), а не адрес, то текущая транзакция TxR[ i ] в момент очередного перевода средств становится недействительной, и после каждого перевода нужно выпускать новую резервную транзакцию.
Получатель не сможет задействовать резервную транзакцию до времени разблокирования; нам остаётся лишь следить за тем, чтобы не пропускать моменты TxR[ i ].nlocktime.

2. Хранение биткоинов на разных адресах (принадлежащих разным кошелькам) одновременно.
A1 и A2 находятся на разных кошельках и на разных компьютерах. Для кражи этих средств злоумышленнику потребуется взломать оба.
При необходимости можно выпустить резервную транзакцию к Tx1
Например, во избежание потери средств при поломке/краже одного из устройств и отсутствии бэкапов (что не отменяет необходимости бэкапить ключ адреса F). Или если вы опасаетесь, что не сможете при первом знакомстве с программой правильно перевести средства на мультисигнатурный адрес и боитесь их потерять — в этом случае не публикуйте Tx1 сразу, а сначала выпустите TxR и убедитесь в её корректности.

ВНИМАНИЕ: в связи со свежевсплывшей уязвимостью bitcoin-протокола не гарантируется стопроцентная безопасность для покупателя последующих схем (с транзакцией возврата).

3. Покупка/обмен по предварительной договорённости без ожидания подтверждений и без доступа в интернет.
As1,...,Asn (start), Ap (participant), Af (final) — адреса покупателя, в частном случае могут быть одинаковыми; Bp, Bf — то же самое для продавца. TxR — reserve transaction, TxP — payment transaction, Tx1 — транзакция пополнения баланса.
Покупатель создаёт и подписывает транзакцию
но пока не публикует её. Также покупатель создаёт резервную транзакцию возврата
(delay может быть равным, допустим, неделе)
Подписывает своим ключом транзакцию TxR (она подписывается лишь наполовину, нужна ещё подпись продавца). Передаёт TxR_part продавцу. Продавец проверяет TxR_part, доподписывает её и возвращает полностью подписанную TxR покупателю. Покупатель проверяет TxR и в случае её корректности публикует Tx1.
На данный момент ситуация такова, что покупатель свои средства не теряет — даже если продавец исчезнет, покупатель сможет получить свои деньги обратно после TxR.nlocktime.
Одновременно с подписью TxR_part продавец формирует транзакцию оплаты
подписывает свою часть и передаёт TxP_part вместе с TxR покупателю. Покупатель проверяет TxP_part, доподписывает её своим ключом и, не публикуя TxP, едет за покупкой/обменом. В момент совершения сделки покупатель просто передаёт TxP продавцу. Продавец проверяет TxP и публикует её (ему необязательно публиковать её сразу, это лишь нужно сделать до TxR.nlocktime).
Double spend с адреса {Ap,Bp} (точнее, с (id(Tx1),0)) невозможен, т.к. для него требуется подпись ключами и продавца, и покупателя. Поэтому, а также из-за того, что TxR временно заблокирована, публикование TxP можно отложить, а ожидание подтверждений вообще отбросить. Теоретически возможен лишь double spend с адресов As1...Asn вместо транзакции Tx1, но предполагается, что от момента предварительной договорённости (включения Tx1 в блокчейн) до момента покупки прошло достаточно много подтверждений.

4. Модификация предыдущей схемы для множественных покупок/обмена по частям без отправки промежуточных транзакций в блокчейн.
{Ap,Bp} теперь рассматриваем как некий счёт покупателя в магазине (у продавца, в обменнике).
Точно так же генерируем, подписываем, обмениваемся и публикуем Tx1 и TxR, как в предыдущем варианте (только, возможно, стоит отодвинуть TxR.nlocktime на более дальний срок, особенно если планируется длительное сотрудничество). Но теперь продавец запрашивает трату лишь части средств покупателя транзакцией
Можно использовать, например, delta == 3 часа.
Продавец отправляет TxP[1]_part, покупатель получает её, проверяет, доподписывает и отправляет TxP[1] продавцу.
Для новых покупок/траншей:
Аналогично для последующих. Обратите внимание, что ни одна из вышеперечисленных транзакций кроме Tx1 в блокчейне не публикуется.
На данном этапе средства обоих участников «виртуальны» (их ещё нельзя потратить ни продавцу, ни покупателю). Однако, если сейчас сотрудничество прекратится, то продавец опубликует TxP[last] в момент времени TxP[last].nlocktime, и каждый участник получит свою долю в единоличное распоряжение.  Единственный момент — продавцу следует публиковать транзакцию TxP[last] сразу после наступления TxP[last].nlocktime, иначе через некоторое время у покупателя появится возможность опубликовать предыдущую транзакцию TxP[last-1] или даже TxP[last-k], которые отменят оплату k последних покупок.
В случае, если нужно снять средства, то очередную транзакцию оплаты TxP[ i ] выпускаем без nlocktime и публикуем её в блокчейне.
Для пополнения баланса можно просто перевести сумму пополнения на {Ap,Bp}
Tx2 также стоит публиковать только после выпуска TxR2
Для последующих покупок:

5. Модификация предыдущей схемы для случая, когда возможно движение средств в обе стороны.
- средства вносит один участник («покупатель»):
Действия те же, что и в предыдущей схеме, только подписывает TxP[ i ] первым тот, кто в данный момент собирается принимать биткоины. Ну и следить за приближением currtime к TxP[ i ].nlocktime теперь должны оба.
- средства вносят оба равноправных участника:
То же, что и в предыдущем варианте. Единственный нюанс — теперь возникает новая транзакция Tx2, переводящая средства от участника B на общий адрес. Для этой транзакции участником A (который на данной стадии играет роль продавца) подписывается транзакция возврата TxRB, TxRB.nlocktime = TxRA.nlocktime. Ну и теперь все TxP тратят средства с выходов как Tx1, так и Tx2 (аналогично варианту с пополнением баланса):

Для гарантированного получения своих средств назад обоим участникам необходимо хранить лишь последнюю TxP, а также все TxR, выпущенные после последней TxP (после очередной TxP, включающей соответствующие входы, все TxR становятся неактуальными).

Предупреждение: для каждого совместного счёта следует использовать отдельный адрес-участник. Если используется один адрес (Bp), возможна такая ситуация:
- участник A говорит, что Ap принадлежит ему, генерирует и подписывает TxA, просит магазин подписать
и публикует TxA;
- участник E говорит, что Ep == Ap принадлежит ему, якобы генерирует и якобы подписывает TxE == TxA, просит магазин подписать
(желательно TxRE.nlocktime < TxRA.nlocktime, зависит от разрешения магазина выбирать delay самостоятельно), а затем получает средства после TxRE.nlocktime (если до этого момента в блокчейне не будет опубликована TxRA или TxP[ i ]).
Если же адреса BAp и BEp будут разными, то для кражи злоумышленнику придётся подбирать Eup такой, чтобы {Eup,BEp} == {Ap,BAp} (т.е. чтобы хэши их redeemScript'ов совпадали), что на данный момент практически нереально.

6. Модификация п.4 для множественных покупок/обмена с участием централизованного посредника.
C — адреса посредника.
Каждая из сторон (покупатели и продавцы) независимо друг от друга и в разное время заключают соглашения с посредником, перечисляют средства на совместные с ним адреса и генерируют транзакции возврата. Покупатель совершает покупку, продавец формирует транзакцию оплаты (перевод части средств с совместного с посредником счёта)
подписывает её своим ключом и отправляет TxPB_part[ i ] посреднику, дополнительно указав, какому покупателю отправить счёт. Посредник принимает её, генерирует транзакцию оплаты для покупателя
подписывает её своим ключом и отправляет TxPA_part[j] покупателю. Вместе с этим посредник формирует документ, в котором указаны TxPB_part[ i ] и TxPA_part[j], подписывает его (например, с помощью PGP) и отправляет продавцу. Этот документ в дальнейшем будет являться доказательной базой, если посредник вздумает принять оплату от покупателя, но не вернуть эту оплату продавцу.
Покупатель проверяет TxPA_part[j] (в т.ч. её соответствие тому, что получил продавец в документе), доподписывает её и возвращает TxPA[j] посреднику. Посредник, проверив TxPA[j], доподписывает TxPB[ i ] и в свою очередь передаёт последнюю продавцу.
Риски, вносимые централизованным посредником:
- блокировка средств. Возможна лишь временная, т.к. у всех подписавших договор есть транзакции возврата.
- приём оплаты от покупателя (TxPA) и отсутствие передачи связанной TxPB продавцу. В этом случае покупатель передаёт полностью подписанную транзакцию TxPA продавцу, а тот выкладывает в общем доступе претензию (где указаны TxPA и подписанный документ с TxPB_part и TxPA_part) с требованием выпустить TxPB. В этой ситуации посредник либо уступает требованию, либо теряет репутацию, и клиенты переходят к другим посредникам. Если же сумма оплаты столь велика, что её потеря будет чувствительна для покупателя, то можно либо переводить её частями, либо перечислить напрямую от покупателя продавцу без посредников (необходимость ожидания подтверждений — меньшее зло в данном случае).

Пока всё.

Само собой. Я имею в виду, чтобы клиент сам извлекал приватный ключ, соответствующий этому публичному ключу или адресу, если этот пубкей/адрес в кошельке есть. Примерно как createmultisig поступает:

Я старался Правда, есть ещё что исправлять — sighash пока никак не учитывается, ну и checkonly работает только с разблокированным кошельком (пароль нужно ввести), хотя по смыслу этого требоваться не должно. Надо себя заставить
Да, я в курсе, но root-доступ кошельку и не нужен. Впрочем, лично я LXC не использую — это так, умозаключения.

UPDATE. checkonly исправил, пароль больше не нужен.

Вообще я не реализовывал самостоятельное подписывание транзакций, а лишь делегировал это команде «bitcoind signrawtransaction», но, судя по описанию, нужно просто повторить шаги 3-7 по количеству инпутов, а затем подписывать каждый инпут, повторяя шаги 15-18 (хэш из шага 14 не изменяется). Правда, что такое «hash code type» из шагов 13 и 19 (имеет ли он какое-нибудь отношение к sighash, и если имеет, то почему он один на всю транзакцию), я пока не понял. Завтра попробую код официального клиента почитать.
Да, на всякий случай могу порекомендовать почитать это, особенно разделы «Procedure for Hashtype SIGHASH_*», вдруг что прояснится.

У меня есть подозрения, что это ни разу не так. Т.е. это вполне адекватный алгоритм для SIGHASH_ANYONECANPAY, но не для дефолтного SIGHASH_ALL, при котором, насколько я понял, должны подписываться не только все выходы, но и все входы.
Я доберусь-таки завтра до кода
Пункт 9 — это про выходы, во входах amount нигде не указывается. Так что 10к, если он у нас один. Впрочем, тут стоит иметь в виду, что если это вся транзакция, то для её принятия сетью потребуется указать комиссию, минимально допустимое значение которой в нашем случае будет как раз 10к В общем, стоит добавить инпут покрупнее.

Да, действительно. Расследование показало, что для каждого инпута создаётся отдельная «упрощённая» транзакция
script.cpp:
Здесь txTmp — упрощённая транзакция (без п.13), ss — полная упрощённая транзакция (с п.13), параметр scriptCode — это fromPubKey (как в п.6), параметр nIn — номер входа, для которого эта транзакция формируется. Помимо самих данных к упрощённой версии дописывается nHashType («ss << txTmp << nHashType», п.13); этот «hash code type» имеет самое прямое отношение к sighash, но то, что он один на всю транзакцию — не проблема, т.к. для каждого входа создаётся отдельный вариант.
Далее, тоже script.cpp:
Для SIGHASH_ANYONECANPAY (fAnyoneCanPay) сериализуем (записываем в транзакцию) только один вход, в противном случае все входы. Ещё можно обратить внимание, сколько сериализуется выходов в зависимости от SIGHASH («unsigned int nOutputs = fHashNone ? 0 : (fHashSingle ? nIn+1 : txTo.vout.size());»).
Теперь входы (файл тот же):
Здесь стоит обратить внимание на строку «if (nInput != nIn)» — для того выхода, для которого мы составляем упрощённую транзакцию, записываем scriptPubKey («SerializeScriptCode(s, nType, nVersion);»), для остальных — пустышку («::Serialize(s, CScript(), nType, nVersion);»).

P.S. В процессе расследования наткнулся на замечательное:
Оно, конечно, понятно, что это для преобразования одного из вариантов {0, SIGHASH_ANYONECANPAY} в {0, 1} соответственно, но выглядит красиво

Написание скрипта несколько застопорилось, а вот генерация идей нет, поэтому выложу своё ви́дение дальнейшей разработки здесь, чтобы не пропало даром. Итак, sighash.

Beginners.
Что такое sighash? Это некий маркер, который позволяет устанавливать, что именно подписывает данная подпись, и в определённых случаях комбинировать выходы и входы вместе с подписями, собирая их из разных транзакций.
Принимает следующие значения:
SIGHASH_ALL (значение по умолчанию; в подавляющем большинстве случаев мы имеем дело именно с ним): подписываются все входы и все выходы.
SIGHASH_SINGLE: подписываются все входы и только один выход, чей номер равен номеру подписываемого входа. Означает, что «я готов потратить свои средства, если остальные потратят такие-то средства (на таких-то непотраченных выходах) и на выход, соответствующий моему входу, придёт столько-то монет; куда будут потрачены остальные монеты, мне безразлично».
SIGHASH_NONE: подписываются только входы (все). Означает, что «я готов потратить свои средства, если остальные потратят такие-то средства, и мне всё равно, куда пойдут монеты».
Все три вышеперечисленных значения можно комбинировать со значением SIGHASH_ANYONECANPAY, которое означает «из всех входов я подписываю только свой вход, остальные могут добавлять или изменять другие входы при желании». Естественно, на подпись выходов данный флаг не влияет.

Intermediate.
sighash — это маркер, относящийся именно к подписи, а не ко входу. Это означает, что несколько подписей, тратящих средства с мультисигнатурного адреса и относящихся к одному и тому же входу, в общем случае могут иметь разные sighash.
Для ручного формирования подписи с недефолтным sighash можно использовать команду «bitcoind signrawtransaction», 4-й параметр (sighashtype) отвечает именно за него.

Advanced.
Для подписывания каждого входа создаётся отдельная упрощённая транзакция, хэш которой, собственно, и подписывается. В эту упрощённую транзакцию попадают те или иные поля из реальной транзакции в зависимости от sighash. Остальные поля либо заменяются пустышками (или некоторыми условно-посторонними значениями), либо вообще выбрасываются.
Распишу покрытие подписи для каждого значения sighash. Допустим, у нас для каждой транзакции имеются две таблицы, одна для входов, другая для выходов. У таблицы выходов одно поле — «value/scriptPubKey» (в реальной таблице их следует разделять, но подписываются они всегда вместе, поэтому для упрощения объяснения буду считать их единым целым). Далее по тексту буду называть это поле просто «output». А вот у таблицы входов 3 поля: «pos», «txid/vout» (тоже единое; в дальнейшем «prevout») и «nsequence». «Pos» — это номер входа в транзакции; поле виртуальное, в самой транзакции в явном виде не присутствует, однако в некоторых случаях «подписывается» (влияет на подпись), а в некоторых нет. Для единообразия буду считать, что значения «pos» идут с нуля.
Есть ещё 2 подписываемых поля, общих для всей транзакции: «version» (версия транзакции, пока только 1) и «nLockTime». Они входят в покрытие при всех вариантах sighash (за одним исключением, являющимся багом протокола), дальше по тексту на этих полях заострять внимание не буду.
Теперь собственно варианты sighash.
ALL: в покрытие входят все «prevout» (вместе со всеми «pos»), все «nsequence» и все «output». Подписывание всех входов («prevout») автоматически означает, что подписываются и все «pos», т.е. порядок следования входов в такой транзакции менять нельзя. В противном случае изменится хэш упрощённой транзакции, и подпись станет некорректной.
У ALL самое строгое покрытие.
ALL|ANYONECANPAY: только свой «prevout», свой «nsequence» и все «output». «Pos» не входит в покрытие (т.е., если у вас все подписи с таким sighash, то входы — но не выходы — можно будет произвольно перетасовывать).
SINGLE: все «prevout» (+ все «pos»), только свой «nsequence» и только «свой» «output» (тот, чей номер равен номеру своего входа). Обратите внимание — «nsequence» подписывается тоже только один.
SINGLE|ANYONECANPAY: только свой «prevout», свой «nsequence», свой «output» и свой «pos». Последнее кажется странным, учитывая то, что более, казалось бы, строгое значение ALL|ANYONECANPAY не включает «pos» в покрытие, однако этот факт следует из алгоритма формирования упрощённой транзакции для SINGLE, в которую включаются pos+1 выходов, из них pos пустышек и только свой соответствует реальному. Т.е. скомбинировать две транзакции, каждая из которых состоит из одного входа и одного выхода и подписана SINGLE|ANYONECANPAY, в одну не получится — каждый вход должен сохранять свой номер. Зачем было выбрано такое решение — не знаю; если это была попытка защиты от Transaction Malleability, то, как видно, она не удалась (по другим причинам).
Ещё раз напомню про связанный с SINGLE баг в протоколе, когда у входа нет выхода с таким же номером (число выходов меньше числа входов).
NONE: в покрытие входят все «prevout» (+ все «pos») и только свой «nsequence» (аналогично SINGLE). Выходы не подписываются.
NONE|ANYONECANPAY: свой «prevout» и свой «nsequence». Самое либеральное покрытие, если не считать вышеупомянутого бага.

Теперь касательно реализации. Для скрипта список входов (строк, начинающихся с "i") и выходов ("o") будет считаться эталоном (заготовкой финальной транзакции); nLockTime из строки, начинающейся с "l", тоже будет считаться эталонным (но nSequence из той же строки — лишь рекомендательным). Далее, будут добавлены строки, начинающиеся, скажем, с "p", после которых идут транзакции-поставщики подписей. Примерно как "t", только для "t"-транзакций будет обязательным совпадение всех входов и выходов с эталоном, а для "p" нет.
Сам процесс: отбрасываю те транзакции, у которых nLockTime не соответствует эталонному. Из всех оставшихся транзакций (и "p", и "t") вырезаю подходящие подписи, проверяя для каждой из них соответствие их покрытия эталону. После этого шага для некоторых входов теоретически возможно появление нескольких конкурирующих подписей-кандидатов из разных транзакций (я сейчас про обычные, не только про мультисигнатурные адреса). Подбираю значения nSequence для всех входов (возможно, разные) так, чтобы корректным осталось максимальное количество подписей (конкурирующие подписи считая за одну), записываю эти подписи в транзакцию и тогда уже передаю получившийся результат команде «bitcoind signrawtransaction».

P.S. Добавил предупреждение в use cases в связи с текущей атакой.