<p>The payment channel between Alice and Bob is encoded as a 2-2 multisig Adress the balance of that Adress is the capacity of the channel. </p>

<p>A channel is opened by sending funds to that multisig Adress via a funding transaction. These funds do exist (on the Bitcoin network) and are by no means virtual. </p>

<p>Alice and Bob each control a key of that Multisig Adress meaning they cannot spend from that address without the help of the other party. </p>

<p>The balance of the channel (not to be confused with the capacity) is encoded by a pair of commitment transactions. One for Alice and one for Bob. This is a spend of the funding transaction. And has at least two outputs. One for Alice encoding the amount of funds she has in the channel and one for Bob encoding his amount of funds in the channel.</p>

<p>Commitment transactions have exchanged signatures and can be published any time and encode the distribution of funds that alice and Bob agreed to.
When Alice sends funds to Bob a new commitment tx is negotiated. </p>

<p>Only problem is to invalidate or revoke the previously signed pair of commitment transactions. This is achieved by creating timelocks one the outputs of the commitment transactions, and allowing that output to be spend without the timelock if a revocation secret is presented. This incentivizes both parties to only broadcast the most recent commitment transaction. </p>

<p>All of this works as a protocol on top of Bitcoin as such it is nothing but a clever (?) way to use Bitcoin.</p>

<p>As for trusting a man in the middle. The trust model relies on the Bitcoin network (as hopefully became clear). As long as we trust the Bitcoin network to be honest operating a payment channel works as expected. </p>

CC BY-SA 4.0
2020-03-10T20:32:50.907Z
2020-03-11T03:09:31.280Z
2020-03-11T03:09:31.280Z
Rene Pickhardt
<p>In the Lighting Network or with micropayment it's possible to open up payment channels that basically work like a smart contract.</p>

<p>At the beginning, the channel is funded by one or two parties with some initial coins (or "funds"), which is then transactioned to the blockchain. The question is: <strong>Where do these initial coins go to?</strong> Are they like stored in the blockchain-only? Or are they stored in some kind of virtual Bitcoin address for that channel?</p>

<p>So let's say one party is Alice and the other is Bob. The channel is single-funded by Alice (the very same as <a href="https://upload.wikimedia.org/wikipedia/commons/0/05/Lightning_Network_Explained.webm" rel="nofollow noreferrer">here</a>). Now Alice sends Bob 0.2 BTC: <strong>Where are the transactions in the channel being written to?</strong> In other words, how can I make sure that Alice doesn't deliberately screw up the channel and gets back the 1 BTC instead of the 0.8 BTC? Does this even reliably work without a man in the middle? If not, who or where is this man in the middle?</p>

CC BY-SA 4.0
2020-03-11T05:25:42.223Z
FYI, I've found not the same but a related question: https://bitcoin.stackexchange.com/questions/41640/how-is-a-transaction-verified-in-a-micropayment-channel
Marcus
<lightning-network><smartcontracts><micropaymentchannels><channels><implementation>
Do payment channels have an address? And where are their transactions actually being written to?
Marcus
# Do payment channels have an address? And where are their transactions actually being written to?

(Asked by: username_0 on 2020-03-10)

In the Lighting Network or with micropayment it's possible to open up payment channels that basically work like a smart contract.

At the beginning, the channel is funded by one or two parties with some initial coins (or "funds"), which is then transactioned to the blockchain. The question is: **Where do these initial coins go to?** Are they like stored in the blockchain-only? Or are they stored in some kind of virtual Bitcoin address for that channel?

So let's say one party is Alice and the other is Bob. The channel is single-funded by Alice (the very same as [here](https://upload.wikimedia.org/wikipedia/commons/0/05/Lightning_Network_Explained.webm)). Now Alice sends Bob 0.2 BTC: **Where are the transactions in the channel being written to?** In other words, how can I make sure that Alice doesn't deliberately screw up the channel and gets back the 1 BTC instead of the 0.8 BTC? Does this even reliably work without a man in the middle? If not, who or where is this man in the middle?

**Tags:** lightning-network, smartcontracts, micropaymentchannels, channels, implementation

> **Comments:**
> **username_0**: FYI, I've found not the same but a related question: https://bitcoin.stackexchange.com/questions/41640/how-is-a-transaction-verified-in-a-micropayment-channel  

---

## 1 answers

### Answer by username_1 on 2020-03-10. Score: 4 | Accepted answer

The payment channel between Alice and Bob is encoded as a 2-2 multisig Adress the balance of that Adress is the capacity of the channel.

A channel is opened by sending funds to that multisig Adress via a funding transaction. These funds do exist (on the Bitcoin network) and are by no means virtual.

Alice and Bob each control a key of that Multisig Adress meaning they cannot spend from that address without the help of the other party.

The balance of the channel (not to be confused with the capacity) is encoded by a pair of commitment transactions. One for Alice and one for Bob. This is a spend of the funding transaction. And has at least two outputs. One for Alice encoding the amount of funds she has in the channel and one for Bob encoding his amount of funds in the channel.

Commitment transactions have exchanged signatures and can be published any time and encode the distribution of funds that alice and Bob agreed to.
When Alice sends funds to Bob a new commitment tx is negotiated.

Only problem is to invalidate or revoke the previously signed pair of commitment transactions. This is achieved by creating timelocks one the outputs of the commitment transactions, and allowing that output to be spend without the timelock if a revocation secret is presented. This incentivizes both parties to only broadcast the most recent commitment transaction.

All of this works as a protocol on top of Bitcoin as such it is nothing but a clever (?) way to use Bitcoin.

As for trusting a man in the middle. The trust model relies on the Bitcoin network (as hopefully became clear). As long as we trust the Bitcoin network to be honest operating a payment channel works as expected.


---

