15

It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed Time-Locked Contract (HTLC) output used for routing a payment. At the default minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000 USD/BTC). As fees rise, larger and larger micropayments ...


15

Lightning forwards payments using a construction called a "hashed timelock contract" (HTLC), which allows the payee to redeem the transaction if they know the preimage to a given hash, or allows the payer to redeem the transaction after a given timeout. So eg if I'm selling you something for $2 over lightning, I might say "I'll tell you the sha256 preimage ...


13

In the image below from Rusty Russell's Deployable Lightning paper, you can see a visualization of the commitment transactions and their outputs: For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob. Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although ...


8

A very low value output in Bitcoin (or any similar system) has zero actual value because the cost in fees to spend it would be equal to or greater than the coins it provides. Like someone writing you a check for $0.01, you'd be best off throwing it out because the time it takes to handle it (much less the tiny risk that it bounces and causes you a bounced ...


5

First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle ...


4

The HTLC isn't really a specific type of bitcoin transaction, it is more a specific output script with the required spend conditions. Thus to make an HTLC, you really need to create a custom script which the bitcoin core command line tools don't really accomplish. You could construct the script by hand or perhaps find another tool which allows more easy ...


4

An htlc is a small output in the commitment transaction. As with any output it needs to be bigger than the dust limit. In particular if the amount is smaller than the expected on chain transaction transaction fee to spend it it becomes economically unviable.


4

One reason to use HTLCs for single-hop payments in the Lightning Network would be to make them indistinguishable from multi-hop payments to the receiver. This way, the receiver does not know whether it was their direct peer who initiated the payment, or whether they are merely forwarding the payment on for somebody else. Since they look identical to the ...


4

Bitcoin needs approximately sundial time accuracy to operate. Computers have their own free running clocks which provide more than enough accuracy in the absence of other references, and NTP sources which are terrestrial rather than GPS based. nLockTime and other internal tools are not based on local clocks, as there’s absolutely no guarantee that anybody in ...


3

First of all I think there seems to be a small confusion about the notation. One does not spend a transaction but transaction outputs. In the case of offered htlcs the output is only one (of potentially many others) output. Also I understand the timelock slightly different. If you publish the commitment transaction it can be mined and verified directly. It ...


3

How is it possible? Does the HTLC is not written on the blockchain? In the Lightning Network, HTLCs are part of the commitment transactions which are not broadcast to the network. This means that the HTLCs do not go onto the blockchain unless some fraud has occurred or someone is unresponsive. None of the conditions of a commitment transaction (all of the ...


3

I haven’t played the whole HTLC thing through, but was starting easy: try to create a redeem script, and the condition shall be, that a hash is checked with „equal verify“. Only play on testnet/regtest! My example below is on unixoide systems, at the command line with bitcoin in regtest mode. I have done this with "bitcoin_cli -version": v0.15.1 Attention, ...


3

The funds in the respective HTLC's get stuck for a time-out period if the payment_pre-image doesn't propagate back along the route to your originating channel. There is no guarantee beforehand that this propagation will be successful. That is why HTLC(sent)'s are always signed together with a respective time-out transaction, with a signed input that spends ...


3

The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners. Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions. There's not much sense in listing and analyzing ...


3

My first instinct was to write that we don't know this as we don't know how the exact protocol for PTLCs looks like but then I realized that unless someone finds a cool trick it will probably be hard to combine them for the following reason: With HTLCs we basically create an output in the commitment transaction that can be spend by the receiver if the ...


3

Yes, assuming James sends Bob two outputs with the following spending conditions: pk($bob) || (pk($alice) && older(10)) pk($bob) || (pk($carol) && older(10)) Bob can spend these UTXOs together in one transaction by unilaterally satisfying the first spending conditions just with his signatures. Once either of the two UTXOs has ten ...


2

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange? Either way will work, but hashlocks are simpler. They're described in section 4 of the paper you linked. In a private key exchange-based system, you need to store every breach remedy transaction, (about 250 bytes) but in a hashlock ...


2

The dust limit is an externality to lightning wich the protocol has to respect. In fact if a commitment transaction would encode an htlc below the dustlimit you could not force close the channel as the Bitcoin network would not accept that particular transaction. When it comes to htlcs below the dustlevel we work with a little trust in the payment channel. ...


2

There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout. Redeemed using a valid pre-image by remote node: The stack starts at <remotehtlcsig> <payment_preimage> Since the ...


2

Such a functionality is currently not implemented and as far as I understand not intended. You can look at Discreet Log Contracts which where intended to solve CFD (Call for difference) contracts for example with cross asset swaps and changing exchange rate within the timelock period. We have a proposal how they could be transfered to lightning. That being ...


2

Why isn't the signature for the entire commitment transaction enough? Because the htlc_signature field contains the signature for the HTLC transactions spending from the htlc output(s) (either received or offered) of the commitment transaction. To expand a bit, some paths of the HTLCs scripts (timeout for an offered htlc output and success for a received ...


2

In order for you to see these scripts you'll have to force the channel on-chain, along with the HTLC. Only then will the HTLC be swept using the script, otherwise you'll only see the P2WSH output for the HTLC being added and then removed if the payment succeeds or fails. Under normal operation you wouldn't therefore see the HTLC. When testing c-lightning we ...


2

decodescript has this behavior because integers in Bitcoin are little endian. So decodescript is telling you what number the script interpreter would use when it processes your script.


2

Timestamps in Bitcoin, including block timestamps and nLocktime values, are unsigned 32-bit. The last possible timestamp is Feb 7th 2106, at 06:28:15 UTC.


1

I think you have answered your question yourself. If all nodes would behave honestly and in good faith your process would work. But in that case we would not need to go through the hustle of setting up htlcs to begin with but we could just forward money by changing the balances in each channel. The whole point of using htlcs is to make the payment process ...


1

Check the Script wiki would be helpful. I once did this by hand, here's the process. First, put the unlocking script on top of the locking script, <remotehtlcsig> <payment_preimage> # To remote node with revocation key OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE <remote_htlcpubkey&...


1

HTLCs have a different timeout (cltv_expiry) than the regular timeout that we use for penalty transactions (to_self_delay). That is the reason why we use a separate transaction stage (HTLC success/HTLC timeout) to allow our counterparty sufficient time to exercise their right to get the entire balance of the channel in case we broadcast the previous state of ...


1

How then further transactions can happen without waiting for the secret R? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B? Yes, that is correct. You go on adding HLTC outputs in the commitment transactions as more and more HTLCs are added, and delete those HTLCs that are either fullfiled with a ...


1

An HTLC always "freezes" funds. It is a smart contract that says "here is the balance and a hash. If you give me the preimage of that hash within time T, the balance is yours. Otherwise I can take it back.". You can then use this functionality to achieve an atomic swap by going through a service node that is active in both networks and offers to swap ...


1

As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint). I believe you have overlooked the commitment signed message from bolt 02. From there I quote: When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), ...


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