8

There are a variety of different ways to construct a micropayment channel, but there are two designs that I think are particularly relevant to your question about "simple, one-directional, micropayment channels": Spillman-style micropayment channels: this was a commonly-described micropayment channel design prior to BIP65 (OP_CHECKLOCKTIMEVERIFY, CLTV). ...


6

I do not think there is anything to reach consensus on. very small payments (in relation to the transaction fees) they belong to neither (some developers will create a micro-payment solution on the main chain and other on side chains); both are viable and it depends on the application


5

All transactions that are sent between the two parties in a channel are valid bitcoin transactions, and they can be used to close the channel at any time by either party. When a channel is opened, those bitcoins are locked up in that channel until it is closed with a spending transaction, sending an agreed amount of bitcoin to each party in the channel. ...


5

They don't need to support those. As mentioned by Roman you could build the entire LN in one contract. You can even implement the LN Relative OP_CHECKLOCKTIMEVERIFY requirement in a much better way. In fact you can add more functionality than is possible with the Bitcoin LN, you could allow people to add more Ether to their side of the channel with offchain ...


4

It's possible for Alice and Bob to agree among themselves to pay Carol and any number of other recipients (subject to limits on transaction size). However, it's not possible for Carol and other additional recipients to receive those payments with the same trustless security available to Alice and Bob through the payment channel construct. Alice and Bob ...


4

Both lightning channels and duplex micropayment channels (DMC) are proposals to create bidirectional micropayment channels, that is, micropayment channels that can be used in both directions (a user A can pay to another user B and, at the same time, B can pay to A). Apart from their goal, both proposals also have similitudes in the basic blocks they use to ...


4

TL;DR. You need to specify --final_cltv_delta=144 option in the lncli queryroutes command. Longer answer... When payment is routed through Lightning Network, each intermediate node has a potential ability to steal the funds being transferred. To prevent this from happening, intermediate nodes cannot move the money immediately, but only after a certain ...


4

The short_channel_id points to the funding transaction of the payment channel by the format blockheightxtransaction_indexxoutput where the x is used to seperate the 3 values and the three values are depicted in decimal. This is at least the BOLT 1.1 agreed format for the short channel id. Previously the shortchannel id might have been encoded and depicted ...


3

I think the problem is that you are trying to pass the file name as an argument instead of the content of the file. Try passing the json through the standard input instead: cat routes.json | lncli --network=testnet sendtoroute --payment_hash=...


3

Payment channels are a specific form of state channels used for forwarding payments (as in the Lightning network). State channels are a more abstract idea: In theory you could use the ideas of cryptographically securing a state between two or more participants (the balance in payment channels) backed by a blockchain for something else than payments (like ...


3

I was hoping somebody else would answer this, since I am the author of eltoo, I would have preferred an independent answer. To recap: the locktime is used in eltoo to enable a numeric comparison between an element on the stack (state number) and a value that the signature commits to. The reason we can't simply push a number on the stack ourselves is that ...


3

The preimage R is the same throughout the entire route, so Bob/Dave would know what R is (from lnd Overview). However if Bob were to broadcast his commitment transaction for the Bob -> Carol channel, it would have to either be an old commitment without the HTLC-offered output or be the current commitment transaction with the HTLC-offered output. In the ...


3

Short answer: No. Explanation: The fees are part of the onion routing package within the HTLCs. So a routing node accepts an incoming HTLCs and forwards it if there is a difference in value that can be collected as fees. The HTLCs are conditional payments on the condition that the preimage is delivered in return. This will only happen after a path of HTLCs ...


3

First of all we should understand the difference between capacity of a channel and its balance. The capacity is the amount of Bitcoin provided to that channel. The balance encodes the amount of bitcoin which each channel partner owns in the channel. so the sum of the balances will always be the total capacity of the channel. Second we currently do not ...


3

In your scenario you would like to create a payment channel with user 1 and 2 contributing (on-chain) and receiving (off-chain, in the payment channel) the following amounts: User 1: 2 btc User 2: 1 btc To open and fund the channel accordingly, you therefore create the following funding transaction: Input 0: 2 btc from user 1 Input 1: 1 btc from user 2 ...


3

Transactions in a payment channel are still real Bitcoin transactions. They require the cooperation of both parties in the channel, so there is no bank and no central party that can rewrite history or double spend anything in a channel. In order to change one party's balance in a payment channel, both parties must agree to it and sign the commitment ...


3

So the question is if it would be unfair to Alice if: Bob wouldn't reveal his secret information and Bob broadcasts the previous commitment transaction Now, the only case in which Bob would broadcast the previous transaction is if it would have a higher balance for Bob. That would mean that the intention for the channel state update is that Bob would ...


3

I use the following scenario for both questions: Alice wants to pay 1 BTC to Dave via the route: Alice -> Bob -> Carol -> Dave Why do we need timelocks? Lets assume that the payment route has just been established. Meaning: Each hop in the route (A, B, C, D) has an HTLC with its neighbor hop(s). However, the HTLCs would not have any timelocks. Now Dave ...


3

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 ...


3

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 ...


2

As of today, (November 2018): To what extent are those criticisms of Lightning valid as of November 2017? This is still a case for Lightning. Eltoo was the first to suggest a simpler way of coping with such storage requirement. They do not require storing keys or older transactions. Their disadvantage is that there is no punishment in the event of fraud, ...


2

This is absolutely possible. The negotiation between the payment-channel participants can happen over the ad-hoc network. However, each participant must still run a fully validating node at all times when he/she has an open channel-state, to be able to react to cheating counterparties. This validating full node may receive its updates over the ad-hoc ...


2

Even though Pieter Wuille has sad most of what was needed in the comments I will summarize this as an answer. Technically you could open a payment channel with every other person instead of creating a network with the ability to route. The drawbacks are that your total bitcoin amount has to be distributed over several channels and will be very small in ...


2

"Active" is used for Process BIPs, it is not used for Standards Track or Informational BIPs, which use "Final". A quote from BIP 2: "A process BIP may change status from Draft to Active when it achieves rough consensus on the mailing list."


2

In lightning network payments are onion routed. The only thing a PSV could reveal is the previous and next hop, but they can not know the origin or the destination. They know it came from Alice, and went to Bob, but they do not know where Alice may have gotten it from, or where Bob may send it to.


2

The cost is proportional to the number of committed HTLCs on the channel at the time of closure. Each HTLC has an output in the commitment transaction which pays into either a HTLC-success transaction script or a HTLC-timeout transaction script, depending on whether the HTLC was incoming our outgoing. The commitment also usually has an output to the spender (...


2

Streaming payments is not part of the lightning network protocol yet. However you can build a lightning app that simulates exactly this. There was a demo by alekos Filini on lädt years lightning residency. Check out https://youtu.be/IlSVTir_9Ns When AMP is coming streaming payments could be stimulated with AMP by setting up more and more routes. But that ...


1

The problem seems that the other nodes are also offline which is why you can't connect to them. Luckily you don't have to be connected as you can do a force close by publishing your channel state to the Bitcoin network (the disadvantage is that you have to wait for the timelock until you can spend your outputs) Just try lightning-cli close ENTER-CHANNEL-...


1

I know Bitcoin has this concept of "sweeping" funds. Does that still involve incurring a flat fee for every address generated by the master private key? No, sweeping an address involves inputting a private key into some wallet software, and then having the wallet software initiate a tx to empty that address’ funds entirely into a new address that the wallet ...


1

According to the BOLT 3 specification, the peer that funded the channel will incur the costs of closing fees. It also seems that these fees would be calculated before closing a payment channel. Both parties already have a transaction with a built in fee that can be used to close the channel that they can broadcast at anytime. Reference: https://github.com/...


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