Merge pull request #111 from bolatovumar/fix-105

Replace "onchain" and "On-Chain" with "on-chain"
pull/117/head
Andreas M. Antonopoulos 5 years ago committed by GitHub
commit 599473b27b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -24,7 +24,7 @@
[[using_own_bitcoin]]
==== Process for people who already own bitcoin ====
* send bitcoin to lightning wallet (1 onchain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoin to the lightning network wallet first)
* send bitcoin to lightning wallet (1 on-chain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoin to the lightning network wallet first)
* find a node to open a channel with (Node explorer / Autopilots / ...)
* open a connection
* open a channel

@ -133,7 +133,7 @@ This is obviously a lie.
One can use the Bitcoin network to send bitcoin from a P2PKH address as well as sending bitcoin from a 2-2 multisignature address with a P2WSH transaction.
In both cases transfer of ownership might be expensive in bitcoin fees if there is a lot of demand from people to utilize the Bitcoin Network.
However once the bitcoin are used to open a payment channel they can freely flow within the Lightning Network from one participant to another one.
If a channel partner should not respond, one will always have the chance to fall back to the onchain transactions without the necessity for the channel partner to help to do so.
If a channel partner should not respond, one will always have the chance to fall back to the on-chain transactions without the necessity for the channel partner to help to do so.
Due to the potentially high fees and confirmation times, bitcoin on the Bitcoin Network are way more rigid and harder to move than bitcoin on the Lightning Network.
====
@ -251,7 +251,7 @@ This transaction is similar to the commitment transaction.
It has the same balance as the commitment transaction but no outputs are encumbered with a time lock.
As the finish up of the routing attempts could take some time, a mutual close can also take some time.
The on chain transaction fees of the shutdown transaction for closing the channel in a mutual way are being paid by the party who opened the channel and not as many people think by the person who initiated the closing procedure.
As both nodes sign the shutdown transaction they have the chance to pay small fees for the Bitcoin transaction by using their onchain fee estimator.
As both nodes sign the shutdown transaction they have the chance to pay small fees for the Bitcoin transaction by using their on-chain fee estimator.
Even though there is is a potential waiting time this type of channel close is usually faster than the bad way.
===== Examining the force close
@ -259,7 +259,7 @@ In case your node cannot engage to a mutual close (most likely because your chan
This is done by publishing the latest commitment transaction that your node has.
As discussed before the Bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which you might have published for a financial gain.
Thus after that transaction was mined you will have to wait for the timelock of your output to expire until you can spend your own funds.
Also the onchain fees will be much higher for several reasons.
Also the on-chain fees will be much higher for several reasons.
The most obvious reason is that when the commitment transaction was negotiated you and your channel partner would not know how high the on chain fees might be at the time the force close is taking place.
As the fees cannot be changed without reasigning outputs of the commitment transaction which needs to signatures and as the force close usually should happen in an urgent situation the protocol developer decided to be very generouse with the fee rate for the commitment transactions.
It can be up to 5 times higher than the fee estimators would suggest at the time the commitment transaction is negotiated.
@ -268,7 +268,7 @@ The pending routing attempts in the commitment transaction are encoded as additi
In particular those routing attempts will have to be resolved on chain by additional spends.
These additional spends don't have to overestimate the fees but it still adds to the bill.
In general you should not do a force close unless it is absolutely necessary.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay onchain fees to abort or settle routing attempts - even if you haven't opened the channel.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay on-chain fees to abort or settle routing attempts - even if you haven't opened the channel.
===== Examining the ugly way to close a channel
In case you channel partner tries to cheat you - weather deliberate or not - by publishing an outdated state, you will be able to catch this cheating attempt and collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.

@ -199,7 +199,7 @@ They have particular illustrative purpose and are therefore collected separately
* source based routing vs best effort routing (onion routing vs IP forwarding)
* eltoo vs RSMC (?)
* private key vs fully signed transaction (it can be seen as almost the same in the sense of ownership)
* locked bitcoin vs freely movable bitcoin (onchain vs. offchain bitcoin)
* locked bitcoin vs freely movable bitcoin (on-chain vs. off-chain bitcoin)
* routing vs path finding
==== Examples

Loading…
Cancel
Save