On-chain transactions - Revision history

MiltonPusser: /* Funding Transaction */

2019-02-15T14:30:10Z

Funding Transaction

← Older revision		Revision as of 14:30, 15 February 2019
Line 13:		Line 13:
	The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].		The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].

	The remaining two transactions that are created but not published are [[Commitment Transaction\|Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing Transaction\|Closing Transaction]].		The remaining two transactions that are created but not published are [[Commitment Transaction\|Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transaction\|Commitment Transactions]] for later use in a possible future [[Closing Transaction\|Closing Transaction]].

	= [[Commitment Transaction]] =		= [[Commitment Transaction]] =

8go: typos

2019-02-05T19:34:09Z

typos

← Older revision		Revision as of 19:34, 5 February 2019
Line 13:		Line 13:
	The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].		The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].

	The remaining two transactions that are created but not published are [[Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing ~~Transactions~~\|Closing Transaction]].		The remaining two transactions that are created but not published are [[Commitment Transaction\|Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing Transaction\|Closing Transaction]].

	= [[Commitment Transaction]] =		= [[Commitment Transaction]] =
Line 21:		Line 21:
	The Closing Transaction closes the channel. When broadcast, the [[multisig]] address spends the funds back to Alice and Bob according to their '''agreed-upon''' channel amount.		The Closing Transaction closes the channel. When broadcast, the [[multisig]] address spends the funds back to Alice and Bob according to their '''agreed-upon''' channel amount.

	A "Closing Transaction" is always the result of a [[Closing channels\|Mutual close]].		A [[Closing Transaction]] is always the result of a [[Closing channels\|Mutual close]].

	= [[Punishing Transaction]] =		= [[Punishing Transaction]] =

8go: added details

2019-02-05T19:30:56Z

added details

← Older revision		Revision as of 19:30, 5 February 2019
Line 13:		Line 13:
	The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].		The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].

	The remaining two transactions that are created but not published are [[Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing Transaction]].		The remaining two transactions that are created but not published are [[Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing Transactions\|Closing Transaction]].

	= [[Commitment Transaction]] =		= [[Commitment Transaction]] =
Line 24:		Line 24:

	= [[Punishing Transaction]] =		= [[Punishing Transaction]] =
	In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. ~~Let’s investigate how~~ this is ~~possible~~ by the way ~~Lightning does channel updates~~.		In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. This is a unilateral transaction issued by the party that detects the possible [[fraud]].

			Alice can attempt to defraud Bob by publishing an old, outdated [[Commitment Transaction]] that has a balance that favors Alice. By design this transaction will not be executed immediately but will be on hold. Bob now has time to see this published transaction and detect that it is fraudulent. Bob can now react to it by publishing a [[Punishing Transaction]]. This [[Punishing Transaction]] takes all the funds from Alice and gives them to Bob. This way, the attempted theft is punished by loss of funds and the funds are sent to the other party.

			This fraud detection can be done by Bob's wallet or by a [[Watchtower]] used by Bob.

8go: /* Funding Transaction */ added detail

2019-02-05T19:18:52Z

Funding Transaction: added detail

← Older revision		Revision as of 19:18, 5 February 2019
Line 8:		Line 8:

	= [[Funding Transaction]] =		= [[Funding Transaction]] =
	The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.		The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob. The [[Funding Transaction]] creates and signs a total of 3 transactions but only broadcasts one.


			The one transaction that is broadcast funds the channel, and spends to a multisig output. It is signed by whomever chooses to fund the channel, Alice and/or Bob. When this [[Funding Transaction]] receives sufficient confirmation, the channel is considered open. The number of confirmations needed to be considered "sufficient" is configurable in the [[Lightning Network]].

			The remaining two transactions that are created but not published are [[Commitment Transactions]]. These are signed by both payment channel peers, e.g. Alice and Bob, and each peer stores its own [[Commitment Transactions]] for later use in a possible future [[Closing Transaction]].

	= [[Commitment Transaction]] =		= [[Commitment Transaction]] =

2A03:E600:100:0:0:0:0:13: more links

2019-01-31T11:30:22Z

2A03:E600:100:0:0:0:0:13: make layers links

2019-01-31T10:59:30Z

make layers links

← Older revision		Revision as of 10:59, 31 January 2019
Line 1:		Line 1:
	This page lists and explains the transactions broadcast and processed by the Layer-1 [[ blockchain ]]. Currently Lightning implementations exist for the [[ Bitcoin ]] and [[ Litecoin ]] Layer-1 chains. But in the future Lightning implements might exist for many crypto currencies or blockchains. [[ On-chain ]] transactions refer to transactions permanently written to the Layer-1 blockchain (e.g. Bitcoin blockchain).		This page lists and explains the transactions broadcast and processed by the [[Layer]]-1 [[ blockchain ]]. Currently Lightning implementations exist for the [[ Bitcoin ]] and [[ Litecoin ]] Layer-1 chains. But in the future Lightning implements might exist for many crypto currencies or blockchains. [[ On-chain ]] transactions refer to transactions permanently written to the Layer-1 blockchain (e.g. Bitcoin blockchain).

	On-chain transactions are (much) slower than Lightning payments (payment transactions), since you have to wait for [[Bitcoin]] block confirmation. Payments on the Lightning Network are off-chain, i.e. they are not written to the Layer-1 blockchain.		On-chain transactions are (much) slower than Lightning payments (payment transactions), since you have to wait for [[Bitcoin]] block confirmation. Payments on the Lightning Network are off-chain, i.e. they are not written to the Layer-1 blockchain.

	To distinguish, operations on the Layer-1 blockchain are often referred to as [[ transaction ]] and operations on the Lightning Network as [[ payments ]].		To distinguish, operations on the [[Layer-1]] blockchain are often referred to as [[ transaction ]] and operations on the [[Layer-2]] Lightning Network as [[payments]].

	Note, there are also concepts like [[ Cross-chain ]] transactions and [[ Side-chain ]] transactions which are not discussed on this page.		Note, there are also concepts like [[ Cross-chain ]] transactions and [[ Side-chain ]] transactions which are not discussed on this page.

5.196.1.129: added more details, explained that Bitcoin is not the only blockchain for which LN exists

2019-01-30T19:17:43Z

added more details, explained that Bitcoin is not the only blockchain for which LN exists

← Older revision		Revision as of 19:17, 30 January 2019
Line 1:		Line 1:
	~~Transactions~~ broadcast and processed by the [[Bitcoin]] blockchain.		This page lists and explains the transactions broadcast and processed by the Layer-1 [[ blockchain ]]. Currently Lightning implementations exist for the [[ Bitcoin ]] and [[ Litecoin ]] Layer-1 chains. But in the future Lightning implements might exist for many crypto currencies or blockchains. [[ On-chain ]] transactions refer to transactions permanently written to the Layer-1 blockchain (e.g. Bitcoin blockchain).

	~~They~~ are (much) slower than Lightning transactions, since you have to wait for block ~~confirmation~~.		On-chain transactions are (much) slower than Lightning payments (payment transactions), since you have to wait for [[Bitcoin]] block confirmation. Payments on the Lightning Network are off-chain, i.e. they are not written to the Layer-1 blockchain.

			To distinguish, operations on the Layer-1 blockchain are often referred to as [[ transaction ]] and operations on the Lightning Network as [[ payments ]].

			Note, there are also concepts like [[ Cross-chain ]] transactions and [[ Side-chain ]] transactions which are not discussed on this page.

	= Funding Transaction =		= Funding Transaction =

MiltonPusser at 14:20, 11 January 2019

2019-01-11T14:20:41Z

← Older revision		Revision as of 14:20, 11 January 2019
Line 5:		Line 5:
	= Funding Transaction =		= Funding Transaction =
	The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.		The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.

			= Commitment transaction =
			A transaction that spends the funding transaction. Each peer holds the other peer's signature for this transaction, so that each always has a commitment transaction that it can spend. After a new commitment transaction is negotiated, the old one is revoked.

	= Closing Transaction =		= Closing Transaction =

MiltonPusser at 14:13, 11 January 2019

2019-01-11T14:13:21Z

← Older revision		Revision as of 14:13, 11 January 2019
Line 7:		Line 7:

	= Closing Transaction =		= Closing Transaction =
	The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their agreed-upon channel amount.		The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their '''agreed-upon''' channel amount.

			A "Closing Transaction" is always the result of a [[Closing channels\|Mutual close]].

	= "Punishing" transaction =		= "Punishing" transaction =
	In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. Let’s investigate how this is possible by the way Lightning does channel updates.		In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. Let’s investigate how this is possible by the way Lightning does channel updates.

MiltonPusser at 14:03, 11 January 2019

2019-01-11T14:03:36Z

← Older revision		Revision as of 14:03, 11 January 2019
Line 8:		Line 8:
	= Closing Transaction =		= Closing Transaction =
	The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their agreed-upon channel amount.		The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their agreed-upon channel amount.

			= "Punishing" transaction =
			In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. Let’s investigate how this is possible by the way Lightning does channel updates.

← Older revision		Revision as of 11:30, 31 January 2019
Line 7:		Line 7:
	Note, there are also concepts like [[ Cross-chain ]] transactions and [[ Side-chain ]] transactions which are not discussed on this page.		Note, there are also concepts like [[ Cross-chain ]] transactions and [[ Side-chain ]] transactions which are not discussed on this page.

	= Funding Transaction =		= [[Funding Transaction]] =
	The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.		The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.

	= Commitment ~~transaction~~ =		= [[Commitment Transaction]] =
	A transaction that spends the funding transaction. Each peer holds the other peer's signature for this transaction, so that each always has a commitment transaction that it can spend. After a new commitment transaction is negotiated, the old one is revoked.		A transaction that spends the funding transaction. Each peer holds the other peer's signature for this transaction, so that each always has a commitment transaction that it can spend. After a new commitment transaction is negotiated, the old one is revoked.

	= Closing Transaction =		= [[Closing Transaction]] =
	The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their '''agreed-upon''' channel amount.		The Closing Transaction closes the channel. When broadcast, the [[multisig]] address spends the funds back to Alice and Bob according to their '''agreed-upon''' channel amount.

	A "Closing Transaction" is always the result of a [[Closing channels\|Mutual close]].		A "Closing Transaction" is always the result of a [[Closing channels\|Mutual close]].

	= "Punishing~~" transaction~~ =		= [[Punishing Transaction]] =
	In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. Let’s investigate how this is possible by the way Lightning does channel updates.		In the case where either party attempts to defraud the other, a third transaction, which punishes the attacker, will end up being broadcasted on-chain. Let’s investigate how this is possible by the way Lightning does channel updates.