Published on: 2013-08-08T18:20:14+00:00
In a mailing list conversation, Peter Todd discusses the importance of careful handling of incoming funds in a multi-party wallet to prevent attackers from deceiving users into sending funds to the wrong address. He suggests that funds sent to the wallet should be divided into separate authorization amounts by all parties involved in authorizing outgoing payments. Todd also mentions that providing customers with a physical private key, such as on a sheet of paper, could be legally desirable for transferring large amounts of Bitcoin.Todd further explains that with multi-factor wallets, the customer provides one or more keys, while the final key is given to them on a sheet of paper with instructions to scan it on their phone via a QR code. Another method could involve using one-time passwords, with the final approval done over the phone by sharing certain "magic words" with the customer to unlock their funds. Although there is still a risk of funds being locked due to an error, there isn't a financial incentive for it to happen. Todd expresses disappointment that OP_EVAL was not implemented, as it would have allowed customers to provide a P2SH script to easily unlock funds.On July 28, 2013, a discussion was held on the Bitcoin development mailing list regarding minor scripting language additions to implement merklized abstract syntax tree (MAST) support. Peter Todd proposed a version where scriptPubKey's can be reused by verifying the path. He also highlighted the drawback of large storage requirements for wallets. In response, another user suggested that the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller, and nested IF statements can be replaced by creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the provided nonce_i matched the precommitted tree.The author introduces a new implementation of P2SH outputs that allows for the reuse of scriptPubKeys. This implementation involves a merklized abstract syntax tree (MAST) and the use of short 6-word strings as authorization for payment. However, one disadvantage is the large storage requirements for wallets. Nonetheless, both tables can be stored in a distributed hash table in the cloud without compromising security. The security level remains at 2^64, making it difficult for attackers to find a 64-bit pre-image.Gavin Andresen proposed a new design for a wallet that utilizes two-factor authentication through one-time passwords with a third-party service to counter-sign 2-of-2 protected wallets. However, involving a third-party introduces privacy and availability risks. An alternate design eliminates the need for a third-party and offers other advantages and disadvantages. In this design, the user has a wallet with separate balances for savings and day-to-day spending. Transactions from the day-to-day balance do not require authorization, but spending from the savings balance necessitates the use of one-time passwords. When the day-to-day balance becomes low, the user can authorize the movement of discrete multiples of a specific amount from savings to spending using one one-time password per multiple being moved. Savings utilize P2SH outputs that match HASH160 EQUALVERIFY CHECKSIG spent with pubkey/seckey generated deterministically using a counter-based one-time password scheme. Nonces are generated deterministically using RFC2289, and a security level of 64 bits is considered sufficient.It is interesting to note that in certain cases, it may be preferable to have authorization solely focused on spending without any additional involvement. In such cases, the party acting as an oracle does not need to know where the funds are going and can even authorize the spend in advance without two-way communication, potentially prior to the funds being received in the first place. Funding the wallet requires the participation of all parties involved in authorizing an outgoing payment. Additionally, the protection only works if funds sent to the wallet are divided into the discrete authorization amounts desired by the user. These systems, aimed at fund splitting, require further research and development, as they have not received as much attention as payment protocols between customers and merchants. The basic idea is to have multiple devices participate in generating a payment request that is somehow signed. For fund splitting, the request can specify that the funds are paid to multiple transaction outputs simultaneously.
Updated on: 2023-08-01T05:26:19.294015+00:00