2

Because there must always be exactly one directly spendable output per party, in order to avoid one party to be able to "exhaust" the carve-out. With two CPFP-ble outputs, one party could both create a chain of descendants transactions on the first outputs so that it meets the standard mempool limits and then trigger the carve-out mechanism using ...


1

I just see that BIP68 states // Time-based relative lock-times are measured from the // smallest allowed timestamp of the block containing the // txout being spent, which is the median time past of the // block prior. so, the relative timelocks for UTXOs in the block 1 (which 114 confirmations) are verified against the mediantime of the ...


1

Anthony Towns' recent draft uses CLTV, which also uses nLocktime.


1

i manage to find answer for myself. OP_CSV date consensus is based on median time past (mtp), not block's confirmed date. once funding tx above has been confirmed, it is located in block#1609592 with block MTP is 2019-11-24 09:05:26 (UTC 0). At same time, chain's MTP is 2019-11-24 09:25:27 (UTC 0) now come to spending tx, since utxo's confirmed date i ...


1

The sequence number is always 4 bytes, it is a fixed size, little endian, 32 bit integer which makes it always 4 bytes. What you are missing is the scriptSig. The scriptSig always begins with the size of the script (as a compact size unsigned integer). If the scriptSig is empty, then the size must still be there to say that it is a 0 length byte. So the ...


1

If you look at https://blockstream.info/address/bc1qdv0fk4c73fem89s708pzdny8q25d7k5nrckckp87c8alwaw803fq3mqrpz you will see that there are two transactions. The first one https://blockstream.info/tx/943f18e17aa2ba716f2d13785268a1bd6b25c39d2718f3b4785559a5eeaba883 is the funding TX to open the payment channel included in block 587093 (at least according to ...


Only top voted, non community-wiki answers of a minimum length are eligible