Nice find!

I can't imagine that Bitpay is going to leave that there any longer though, it seems like a mistake for them to do so and now that it is publicly known, it will probably go away.

Also, this link
does not work, probably because the invoice expired already.

You can use the one I wrote: https://github.com/achow101/payment-proto-interface

You don't necessarily have to be the one paying the fee. Both parties in the channel can fund the channel in the same funding transaction. So if you only have 0.00001 BTC, you can have the other party be the one who pays the transaction fee. They might do this if the channel is not only for you to buy a coffee but rather that you are also expecting to get paid by this person or route incoming payments through them.

It wouldn't work. If the PoW for transactions was SHA256d, you could just buy an ASIC and spam transactions. If it were something else, you can use GPUs and it would be just as effective. Making the difficulty adjust to transaction size would be completely pointless since spam transactions are typically not large. Furthermore, you couldn't just make it based on the person who is sending it since Bitcoin does not use an accounts based system. It is difficult (nearly impossible) to know whether two transactions were created by the same person, so you can't make the difficulty adjust to the person. So this idea of adding a PoW to each transaction is pointless and wouldn't reduce anything, at least with Bitcoin's design and security model.

The channel owner determines that fee. If you don't like their fee, then you can choose to use a different channel to route your payment through.

It isn't really that you spend small amounts, but rather that you can send and receive many small amounts without paying a lot in fees.

Yes, there is a mechanism to cancel a payment. Anyways, currently it isn't even possible to have a partial payment. The way that routing works is that the sender chooses the nodes to send through and will only initiate the process if it knows that the payment will happen (barring circumstances involving malicious actors or unforseen circumstances).

No, that's not how it actually works on the technical level.

At the technical level, every node in the route first creates an HTLC offered output and HTLC received output in the channels that the payment is being routed through. This effectively locks in the coins and the order of those outputs being created is not guaranteed. I.e. A could offer the HTLC to B before B offers to C, in which case B owes A money. But just as likely is B offers C the HTLC output before it receives the HTLC from A, in which case A owes B money. In either case, neither party actually gets any money, so no money actually exchanged hands nor is anything actually owed. If B fails to offer the HTLC C, A will get his money back when the HTLC times out and B will not be able to have gotten any of that money at all. When the preimage is passed down the route from D to A (let's add one additional hop for this example), none of the parties in the route is able to get more money than they are supposed to even if they don't reveal the preimage to the next person. With lending money, the lender can steal the money, but in LN, the "lenders" (i.e. nodes in the route) cannot.

The reason for this is slightly complicated. In a route A -> B -> C -> D, D must reveal the preimage R in order to be paid. He can do this by either broadcasting the C -> D Commitment transaction and the HTLC success transaction (so he spends the HTLC output from the commitment tx) or by telling C what R is (and thus keep the channel open). If he broadcasts the HTLC success, then both B and C know what R is since R is in that HTLC success and can immediately broadcast their HTLC success transactions, so they are paid and pay money at exactly the same time.

If D gives C R and they settle off chain (to keep the channel open) but C refuses to give B R, he is actually out money since he has already settled the HTLC offered output but not his HTLC received. C is now short the money that he gave to D. Note that this is different from lending because this is not B refusing to give C his money but rather C refusing to take it. The only way C can take that money is if he gives B R or if he broadcasts the commitment transaction and HTLC success transaction. Either way, B will get R and he will end up paying the money to C as that is how HTLCs work.

The payment of the HTLCs is guaranteed because of the commitment transactions. HTLCs are part of the commitment transaction which is signed by both parties in the channel. In the B -> C channel, B cannot revert his HTLC without C agreeing to revert it. If he chose to broadcast an old commitment which did not have this HTLC, then he will be subject to C's revocation transaction which can take all of B's money. The way that HTLCs work is that if you can show that you know R, then the payment is guaranteed because you can spend that output. So once C knows R, his payment is guaranteed unless he waits too long and the HTLC times out. But then that is still not lending as B did not refuse to pay C but rather C refused to take money from B.

So in no way is this actually lending. No node has more money than they are supposed to. HTLCs are not a promise that you will give them the money (as it is with lending) but rather a guarantee that they will get the money. Nodes must forward R down the route otherwise they will be losing money. There is no situation where a node can get more money than they are supposed.

Note that this only works when R goes from D -> A. If it went from A -> D, then it would be lending and a node could defraud the next node in the route. But LN goes the other way, so that is not a problem.

That's completely untrue. You are then dependent on the wealth of that "bank", how many channels it has open, and how much it owns on each channel. You are not done, and there is no guarantee that said "bank" will be any better than your 4 friends. Suppose that bank is just like friends, but with more channels that lead to dead ends and not the airline you want to pay. Now you're stuck. It's exactly the same as with your friends, and not any better nor any worse.

With a well connected graph, that's not a problem. And based on current use on testnet, it looks like it is going to be a fairly well connected graph.

This topic has been moved to Trashcan.

Duplicate

Please post the address that you game them from Coinbase.

Please also post the link to the transaction that you were given.

Actually he doesn't. B pays C at the exact same time that A pays B. So there is no lending as B is never short of his money. As soon as the hash preimage for an HTLC is known to the world, all parties in a route are instantly paid because the HTLCs can be then settled at the same time.


Joe can pay the same person using multiple channels.

If I have two BTC total split across 4 channels and I want to buy something for 2 BTC, I can send 0.5 via Channel 1 to merchant A, 0.5 BTC via Channel 2 to Merchant A, and so on. Merchant A will get 2 BTC from either one channel or from multiple channels, Either way, he gets paid 2 BTC and I spent 2 BTC and the transactions are guaranteed.

Because cryptocurrencies are not under the control of western countries. Cryptocurrencies like Bitcoin are completely decentralized and do not have a central authority (be that private a private group or a government) controlling it.

There is no lending of money. It is not an IOU system, there is no lending. All money exists and is accounted for on the blockchain.

It isn't a chain, it is a route. The graph of nodes is not the extremely degenerate case of a linked list or hub and spoke model. Sure the maximum amount is limited by the smallest amount in the route, but if that amount is too small, another route can be chosen that allows for more money to be transferred if necessary. Furthermore, each route is for one use only, they aren't permanent and do not always have to be used for payments to the same person.

The PoW and block size are completely independent and have nothing to do with each other.

The specification for the mnemonic is BIP 39. That mnemonic is then typically used with BIP 32 to generate your private keys.

It doesn't know, and it does not need to know. The search space is so massive that a crytpgraphically secure random number generator has an extremely small change of generating a seed that someone else has generated before. The probability of that happening is so infinitesimally small that it is nearly impossible. This principle of unlikelihood is the basis of all modern cryptography.

Then they can generate your private keys and spend your Bitcoin. The odds of this happening are extremely small, so much so that it is impossible.

No, they're not. It isn't 7 unconfirmed transactions per second that are being broadcast between nodes. That number has to do with blocks. Nodes are handling much larger numbers than that in unconfirmed transactions.

You can use the mempool message to get a list of all of the txids in a node's mempool.

It is unlikely that a new protocol message will be created which contains just statistical information.

Please post the contents of the debug.log file.

It would require a new address and scripting scheme, similar to segwit. So using it would require transferring all coins to a new address.

It is important because many people and services use Bitcoin Core. With this release, Segwit addresses will be used by default, so, in theory, segwit's usage will greatly increase.

Schnorr signatures (which includes signature aggregation and batch validation) in Bitcoin are actively being researched. There are no proposals or implementations for use in Bitcoin yet.

0.16 is a future release of Bitcoin Core which is planned to have full Segwit wallet support. This includes support for sending to and receiving at segwit addresses much more easily and with more robustness.