mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

Consistently use 'transaction' instead of 'tx'

Browse Source
This commit is contained in:
Christopher Jämthagen 2016-12-08 09:39:04 +01:00 committed by Pierre-Marie Padiou
parent c5ca57b853
commit 6e4f7f0cc2
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
03-transactions.md
View File

@ -59,7 +59,7 @@ This output sends funds back to the owner of this commitment transaction, thus m
It is spent by a transaction with nSequence field set to `to-self-delay` (which can only be valid after that duration has passed), and witness script `<local-delayedsig> 0`.
If a revoked commit tx is published, the other party can spend this output immediately with the following witness script:
If a revoked commitment transaction is published, the other party can spend this output immediately with the following witness script:
<revocation-sig> 1
@ -74,7 +74,7 @@ This output sends funds to a HTLC-timeout transaction after the HTLC timeout, or
<remotekey> OP_SWAP
OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To me via HTLC-timeout tx (timelocked).
# To me via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To you with preimage.
@ -95,7 +95,7 @@ This output sends funds to the remote peer after the HTLC timeout, or to an HTLC
<remotekey> OP_SWAP
OP_SIZE 32 OP_EQUAL
OP_IF
# To me via HTLC-success tx.
# To me via HTLC-success transaction.
OP_HASH160 <ripemd-of-payment-hash> OP_EQUALVERIFY
2 OP_SWAP <localkey> 2 OP_CHECKMULTISIG
OP_ELSE

6
05-onchain.md
View File

@ -79,7 +79,7 @@ A and B each hold a *commitment transaction*, which has 4 types of outputs:
4. _B's offered HTLCs_: Zero or more pending payments (*HTLCs*) to pay A in return for a payment preimage.
As an incentive for A and B to cooperate, an `OP_CHECKSEQUENCEVERIFY` relative timeout encumbers A's outputs in A's *commitment transaction*, and B's outputs in B's *commitment transaction*. If A publishes its commitment tx, she won't be able to get her funds immediately but B will. As a consequence, A and B's *commitment transactions* are not identical, they are (usually) symmetrical.
As an incentive for A and B to cooperate, an `OP_CHECKSEQUENCEVERIFY` relative timeout encumbers A's outputs in A's *commitment transaction*, and B's outputs in B's *commitment transaction*. If A publishes its commitment transaction, she won't be able to get her funds immediately but B will. As a consequence, A and B's *commitment transactions* are not identical, they are (usually) symmetrical.
See "BOLT #3: Bitcoin Transaction and Script Formats" for more details.
@ -127,9 +127,9 @@ Similarly, when node A sees a *commitment transaction* from B:
1. _A's main output_: No action is required; this is a simple P2WPKH output.
This output is considered *resolved* by the *commitment tx* itself.
This output is considered *resolved* by the *commitment transaction* itself.
2. _B's main output_: No action required, this output is considered *resolved*
by the *commitment tx*.
by the *commitment transaction*.
3. _A's offered HTLCs_: See "On-chain HTLC Output Handling: Our Offers" below.
4. _B's offered HTLCs_: See "On-chain HTLC Output Handling: Their Offers" below.