3
0
mirror of https://github.com/Qortal/altcoinj.git synced 2025-02-13 02:35:52 +00:00

Update payment channel sequence numbers for time locked transactions with BIP68 and BIP125 in mind.

This commit is contained in:
mruddy 2016-03-27 14:01:32 -04:00 committed by Andreas Schildbach
parent 9505227616
commit 8d6d0e2ebc
3 changed files with 11 additions and 10 deletions

View File

@ -151,7 +151,9 @@ public class PaymentChannelV1ClientState extends PaymentChannelClientState {
// in future as it breaks the intended design of timelocking/tx replacement, but for now it simplifies this
// specific protocol somewhat.
refundTx = new Transaction(params);
refundTx.addInput(multisigOutput).setSequenceNumber(0); // Allow replacement when it's eventually reactivated.
// don't disable lock time. the sequence will be included in the server's signature and thus won't be changeable.
// by using this sequence value, we avoid extra full replace-by-fee and relative lock time processing.
refundTx.addInput(multisigOutput).setSequenceNumber(TransactionInput.NO_SEQUENCE - 1L);
refundTx.setLockTime(expiryTime);
if (totalValue.compareTo(Coin.CENT) < 0 && Context.get().isEnsureMinRequiredFee()) {
// Must pay min fee.

View File

@ -125,9 +125,9 @@ public class PaymentChannelV1ServerState extends PaymentChannelServerState {
// Verify that the refund transaction has a single input (that we can fill to sign the multisig output).
if (refundTx.getInputs().size() != 1)
throw new VerificationException("Refund transaction does not have exactly one input");
// Verify that the refund transaction has a time lock on it and a sequence number of zero.
if (refundTx.getInput(0).getSequenceNumber() != 0)
throw new VerificationException("Refund transaction's input's sequence number is non-0");
// Verify that the refund transaction has a time lock on it and a sequence number that does not disable lock time.
if (refundTx.getInput(0).getSequenceNumber() == TransactionInput.NO_SEQUENCE)
throw new VerificationException("Refund transaction's input's sequence number disables lock time");
if (refundTx.getLockTime() < minExpireTime)
throw new VerificationException("Refund transaction has a lock time too soon");
// Verify the transaction has one output (we don't care about its contents, its up to the client)

View File

@ -119,13 +119,12 @@ public class PaymentChannelV2ClientState extends PaymentChannelClientState {
contract = req.tx;
// Build a refund transaction that protects us in the case of a bad server that's just trying to cause havoc
// by locking up peoples money (perhaps as a precursor to a ransom attempt). We time lock it so the server
// has an assurance that we cannot take back our money by claiming a refund before the channel closes - this
// relies on the fact that since Bitcoin 0.8 time locked transactions are non-final. This will need to change
// in future as it breaks the intended design of timelocking/tx replacement, but for now it simplifies this
// specific protocol somewhat.
// by locking up peoples money (perhaps as a precursor to a ransom attempt). We time lock it because the
// CheckLockTimeVerify opcode requires a lock time to be specified and the input to have a non-final sequence
// number (so that the lock time is not disabled).
refundTx = new Transaction(params);
refundTx.addInput(contract.getOutput(0)).setSequenceNumber(0); // Allow replacement when it's eventually reactivated.
// by using this sequence value, we avoid extra full replace-by-fee and relative lock time processing.
refundTx.addInput(contract.getOutput(0)).setSequenceNumber(TransactionInput.NO_SEQUENCE - 1L);
refundTx.setLockTime(expiryTime);
if (totalValue.compareTo(Coin.CENT) < 0 && Context.get().isEnsureMinRequiredFee()) {
// Must pay min fee.