Ryan Grant [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-23 📝 Original message: Alice intends to pledge ...
📅 Original date posted:2015-11-23
📝 Original message:
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?
📝 Original message:
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?