Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-07 📝 Original message: I was thinking about ...
📅 Original date posted:2016-03-07
📝 Original message:
I was thinking about something similar, the big problem is that everyone
has to be online. What is needed is a way to do consensus enforced
sequence numbers.
The principle is that the locktime would lock the transaction outputs (like
with the coinbase outputs) rather than prevent the transaction from being
included in the blockchain. Transactions could double spend these
transactions (and make them invalid) as long as they had higher sequence
numbers. Once the locktime is hit, then the last one is locked.
Thinking more about it, this could be done by a soft fork, if the locked
transactions list was committed to in the coinbase. You could only replace
transactions in the "pending" list if they have higher sequence numbers.
At this point, it could need a new field, since sequence numbers are being
used for relative CLTV. Transactions which double spend transactions in
the pending list would not be allowed in the main blocks.
This means that broadcasting an expired state of the channel will just have
someone else broadcast one with a higher sequence number and have your
transaction removed from the pending list. It doesn't protect against a
party broadcasting early, but at least the final state is the one that ends
up as the channel close transaction.
There would be fees to pay to get into the pending list too, and it doesn't
change when the final locktime is anyway.
I think the ideal situation would be where only those who are negatively
affected have to sign to change the state. Moving money from A to B would
only require A's signature on the state change.
For example, a join-channel could have a "moderator" and normal
participants. To sign a state change, you need the moderator's agreement
and anyone who would lose money by the change. The moderator is
responsible for making sure each sequence number is only signed once. Any
of the participants can poll the moderator to get the current state of the
channel after they have been offline for a while. The hub would probably
act as moderator and there would have to be a penalty if the moderator
signs the same state number twice.
Ideally, the users would sign the updates periodically even if they aren't
trading to reduce clutter. If someone signs state 180, then they are
signing all previous states too. This means that you don't even need to
have any state that everyone has signed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/5c7734e5/attachment.html>;
📝 Original message:
I was thinking about something similar, the big problem is that everyone
has to be online. What is needed is a way to do consensus enforced
sequence numbers.
The principle is that the locktime would lock the transaction outputs (like
with the coinbase outputs) rather than prevent the transaction from being
included in the blockchain. Transactions could double spend these
transactions (and make them invalid) as long as they had higher sequence
numbers. Once the locktime is hit, then the last one is locked.
Thinking more about it, this could be done by a soft fork, if the locked
transactions list was committed to in the coinbase. You could only replace
transactions in the "pending" list if they have higher sequence numbers.
At this point, it could need a new field, since sequence numbers are being
used for relative CLTV. Transactions which double spend transactions in
the pending list would not be allowed in the main blocks.
This means that broadcasting an expired state of the channel will just have
someone else broadcast one with a higher sequence number and have your
transaction removed from the pending list. It doesn't protect against a
party broadcasting early, but at least the final state is the one that ends
up as the channel close transaction.
There would be fees to pay to get into the pending list too, and it doesn't
change when the final locktime is anyway.
I think the ideal situation would be where only those who are negatively
affected have to sign to change the state. Moving money from A to B would
only require A's signature on the state change.
For example, a join-channel could have a "moderator" and normal
participants. To sign a state change, you need the moderator's agreement
and anyone who would lose money by the change. The moderator is
responsible for making sure each sequence number is only signed once. Any
of the participants can poll the moderator to get the current state of the
channel after they have been offline for a while. The hub would probably
act as moderator and there would have to be a penalty if the moderator
signs the same state number twice.
Ideally, the users would sign the updates periodically even if they aren't
trading to reduce clutter. If someone signs state 180, then they are
signing all previous states too. This means that you don't even need to
have any state that everyone has signed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/5c7734e5/attachment.html>;