From bitcoin-dev at rgrant.org Mon Nov 23 20:12:55 2015 From: bitcoin-dev at rgrant.org (Ryan Grant) Date: Mon, 23 Nov 2015 16:12:55 -0400 Subject: [Lightning-dev] crowdfunding with SIGHASH_ANYONE_CAN_PAY Message-ID: Alice intends to pledge to Bob's crowdfunded project, and will create a one-input, one-output, anyone-can-pay transaction, valid for one month. Bob publicized his address, anchored to an open channel on the Lightning Network. Alice has already received Bob's hashed preimage R. They plan to use an intermediary node run by Hubab. / the problem / Alice needs some special Lightning protocol option to indicate that only the final hop should be rewritten and signed as anyone-can-pay. All other anyone-can-pay donors need to pay to the same output. However, Lightning does not normally reuse public keys for fresh Commitment Transactions. Bob's Lightning software needs to leave all anyone-can-pay fragments alone until they are valid together. Crowdsourcing initiatives usually deal in larger amounts of money than the initiators can raise beforehand, which would preclude matching the amount in an initial Funding Transaction. / routed option / Alice sends Hubab a normal channel transaction, using the HTLC, to cover the cost plus fees. Alice can then send Hubab special instructions on how to create a SIGHASH_ANYONE_CAN_PAY for Bob, using the HTLC. Hubab does so. Bob can receive transactions of arbitrary complexity. Once Bob receives the pledge transaction from Alice, it should not be revoked, as in normal bidirectional use of Lightning channels. It should lie out-of-band until the anyone-can-pay output is claimed. Bob does not update any related Commitment Transactions, until the anyone-can-pay is fulfilled. Hubab will be able to spend her normal channel transaction when Bob reaches his goal. Bob's crowdfunding software will concatenate scriptPubKeys of the pledges delivered by Hubab, with their HTLCs, to claim the anyone-can-pay output, releasing R. / other issues / Crowdfunding events could lock up money for a long time, since execution is not handed over to the network when the HTLC commitment is initiated. Lightning Network nodes will price their fees accordingly. When fee discovery comes about, it should be aware of the different transaction types. Pledges have longer lives than payments, and it's not an error to change one's mind about them. The protocol needs an update_revoke_pledge_htlc, to revoke accepted pledges that have not yet expired or caused other errors. Hubab may need to route further, to Carol. Hubab needs to be aware of more in the route than her handoff address, such as whether the next destination is final. Hubab (or Carol), when signing the SIGHASH_ANYONE_CAN_PAY transaction, needs to select an input matching the exact amount. Did I get this right? Is there a simpler way to do crowdfunding with the Lightning Network?