CoinLoan Token (CLT) Listed on Tokpie Exchange - Medium

Technical: A Brief History of Payment Channels: from Satoshi to Lightning Network

Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value?
So let's have a short history of various payment channel techs!

Generation 0: Satoshi's Broken nSequence Channels

Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product.
Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger.
Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore.
In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction.
So what you'd do would be something like this:
  1. You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
  2. For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
  3. For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
  4. Eventually you have to stop drinking. It comes down to one of two possibilities:
    • You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
    • You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time.
Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
  1. Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
  2. Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
  3. When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
  4. Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
  5. The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
  6. Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
  7. The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
  8. Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
  9. I think I got sidetracked here.
Lessons learned?

Spilman Channels

Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is).
Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender.
Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender.
First, you and the bartender perform this ritual:
  1. You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
  2. You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
  3. The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
  4. Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds.
So now you start ordering in this way:
  1. For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
  2. You sign the transaction and pass it to the bartender, who serves your first drink.
  3. For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
  4. At the end:
    • If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
    • If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
    • If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen.
So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx...
Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly.
"I'm refusing service to you," the bartender says.
"Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!"
"Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed."
"What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer.
What you see shocks you.
"What the --- the txid is different! You--- you changed my signature?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!"
"Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by separating the signatures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW."
Lesson learned?

CLTV-protected Spilman Channels

Using CLTV for the backoff branch.
This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015.
Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed.
This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction.
With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to.
Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time".
With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.

Todd Micropayment Networks

The old hub-spoke model (that isn't how LN today actually works).
One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel.
Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable.
So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user).
In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today.
Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy.
Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.

Poon-Dryja Lightning Network

Bidirectional two-participant channels.
The Poon-Dryja channel mechanism has two important properties:
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel.
The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online.
Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want.
Both properties, together, form a very powerful scaling property that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening.
With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow.
I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere.
There is a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit):
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network.
Lessons learned?


After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time.
The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory).
Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough.
Lessons learned?
submitted by almkglor to Bitcoin [link] [comments]

Technical: Upcoming Improvements to Lightning Network

Price? Who gives a shit about price when Lightning Network development is a lot more interesting?????
One thing about LN is that because there's no need for consensus before implementing things, figuring out the status of things is quite a bit more difficult than on Bitcoin. In one hand it lets larger groups of people work on improving LN faster without having to coordinate so much. On the other hand it leads to some fragmentation of the LN space, with compatibility problems occasionally coming up.
The below is just a smattering sample of LN stuff I personally find interesting. There's a bunch of other stuff, like splice and dual-funding, that I won't cover --- post is long enough as-is, and besides, some of the below aren't as well-known.

"eltoo" Decker-Russell-Osuntokun

Yeah the exciting new Lightning Network channel update protocol!




Multipart payments / AMP

Splitting up large payments into smaller parts!




Payment points / scalars

Using the magic of elliptic curve homomorphism for fun and Lightning Network profits!
Basically, currently on Lightning an invoice has a payment hash, and the receiver reveals a payment preimage which, when inputted to SHA256, returns the given payment hash.
Instead of using payment hashes and preimages, just replace them with payment points and scalars. An invoice will now contain a payment point, and the receiver reveals a payment scalar (private key) which, when multiplied with the standard generator point G on secp256k1, returns the given payment point.
This is basically Scriptless Script usage on Lightning, instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).




Ensuring that payers cannot access data or other digital goods without proof of having paid the provider.
In a nutshell: the payment preimage used as a proof-of-payment is the decryption key of the data. The provider gives the encrypted data, and issues an invoice. The buyer of the data then has to pay over Lightning in order to learn the decryption key, with the decryption key being the payment preimage.



Stuckless payments

No more payments getting stuck somewhere in the Lightning network without knowing whether the payee will ever get paid!
(that's actually a bit overmuch claim, payments still can get stuck, but what "stuckless" really enables is that we can now safely run another parallel payment attempt until any one of the payment attempts get through).
Basically, by using the ability to add points together, the payer can enforce that the payee can only claim the funds if it knows two pieces of information:
  1. The payment scalar corresponding to the payment point in the invoice signed by the payee.
  2. An "acknowledgment" scalar provided by the payer to the payee via another communication path.
This allows the payer to make multiple payment attempts in parallel, unlike the current situation where we must wait for an attempt to fail before trying another route. The payer only needs to ensure it generates different acknowledgment scalars for each payment attempt.
Then, if at least one of the payment attempts reaches the payee, the payee can then acquire the acknowledgment scalar from the payer. Then the payee can acquire the payment. If the payee attempts to acquire multiple acknowledgment scalars for the same payment, the payer just gives out one and then tells the payee "LOL don't try to scam me", so the payee can only acquire a single acknowledgment scalar, meaning it can only claim a payment once; it can't claim multiple parallel payments.



Non-custodial escrow over Lightning

The "acknowledgment" scalar used in stuckless can be reused here.
The acknowledgment scalar is derived as an ECDH shared secret between the payer and the escrow service. On arrival of payment to the payee, the payee queries the escrow to determine if the acknowledgment point is from a scalar that the escrow can derive using ECDH with the payer, plus a hash of the contract terms of the trade (for example, to transfer some goods in exchange for Lightning payment). Once the payee gets confirmation from the escrow that the acknowledgment scalar is known by the escrow, the payee performs the trade, then asks the payer to provide the acknowledgment scalar once the trade completes.
If the payer refuses to give the acknowledgment scalar even though the payee has given over the goods to be traded, then the payee contacts the escrow again, reveals the contract terms text, and requests to be paid. If the escrow finds in favor of the payee (i.e. it determines the goods have arrived at the payer as per the contract text) then it gives the acknowledgment scalar to the payee.



Payment decorrelation

Because elliptic curve points can be added (unlike hashes), for every forwarding node, we an add a "blinding" point / scalar. This prevents multiple forwarding nodes from discovering that they have been on the same payment route. This is unlike the current payment hash + preimage, where the same hash is used along the route.
In fact, the acknowledgment scalar we use in stuckless and escrow can simply be the sum of each blinding scalar used at each forwarding node.



submitted by almkglor to Bitcoin [link] [comments]

⚡ Lightning Network Megathread ⚡

Last updated 2018-01-29
This post is a collaboration with the Bitcoin community to create a one-stop source for Lightning Network information.
There are still questions in the FAQ that are unanswered, if you know the answer and can provide a source please do so!

⚡What is the Lightning Network? ⚡


Image Explanations:

Specifications / White Papers


Lightning Network Experts on Reddit

  • starkbot - (Elizabeth Stark - Lightning Labs)
  • roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • stile65 - (Alex Akselrod - Lightning Labs)
  • cfromknecht - (Conner Fromknecht - Lightning Labs)
  • RustyReddit - (Rusty Russell - Blockstream)
  • cdecker - (Christian Decker - Blockstream)
  • Dryja - (Tadge Dryja - Digital Currency Initiative)
  • josephpoon - (Joseph Poon)
  • fdrn - (Fabrice Drouin - ACINQ )
  • pmpadiou - (Pierre-Marie Padiou - ACINQ)

Lightning Network Experts on Twitter

  • @starkness - (Elizabeth Stark - Lightning Labs)
  • @roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • @stile65 - (Alex Akselrod - Lightning Labs)
  • @bitconner - (Conner Fromknecht - Lightning Labs)
  • @johanth - (Johan Halseth - Lightning Labs)
  • @bvu - (Bryan Vu - Lightning Labs)
  • @rusty_twit - (Rusty Russell - Blockstream)
  • @snyke - (Christian Decker - Blockstream)
  • @JackMallers - (Jack Mallers - Zap)
  • @tdryja - (Tadge Dryja - Digital Currency Initiative)
  • @jcp - (Joseph Poon)
  • @alexbosworth - (Alex Bosworth -

Medium Posts

Learning Resources


Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

  • ZigZag - Disclaimer You must trust ZigZag to send to Target Address

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

  • LND - Lightning Network Daemon (Golang)
  • eclair - A Scala implementation of the Lightning Network (Scala)
  • c-lightning - A Lightning Network implementation in C
  • lit - Lightning Network node software (Golang)
  • lightning-onion - Onion Routed Micropayments for the Lightning Network (Golang)
  • lightning-integration - Lightning Integration Testing Framework
  • ptarmigan - C++ BOLT-Compliant Lightning Network Implementation [Incomplete]


Lightning Network Visualizers/Explorers



Payment Processors

  • BTCPay - Next stable version will include Lightning Network




Slack Channel

Discord Channel


⚡ Lightning FAQs ⚡

If you can answer please PM me and include source if possible. Feel free to help keep these answers up to date and as brief but correct as possible
Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain.
Is the Lightning Network open source?
Yes, Lightning is open source. Anyone can review the code (in the same way as the bitcoin code)
Who owns and controls the Lightning Network?
Similar to the bitcoin network, no one will ever own or control the Lightning Network. The code is open source and free for anyone to download and review. Anyone can run a node and be part of the network.
I’ve heard that Lightning transactions are happening “off-chain”…Does that mean that my bitcoin will be removed from the blockchain?
No, your bitcoin will never leave the blockchain. Instead your bitcoin will be held in a multi-signature address as long as your channel stays open. When the channel is closed; the final transaction will be added to the blockchain. “Off-chain” is not a perfect term, but it is used due to the fact that the transfer of ownership is no longer reflected on the blockchain until the channel is closed.
Do I need a constant connection to run a lightning node?
Not necessarily,
Example: A and B have a channel. 1 BTC each. A sends B 0.5 BTC. B sends back 0.25 BTC. Balance should be A = 0.75, B = 1.25. If A gets disconnected, B can publish the first Tx where the balance was A = 0.5 and B = 1.5. If the node B does in fact attempt to cheat by publishing an old state (such as the A=0.5 and B=1.5 state), this cheat can then be detected on-chain and used to steal the cheaters funds, i.e., A can see the closing transaction, notice it's an old one and grab all funds in the channel (A=2, B=0). The time that A has in order to react to the cheating counterparty is given by the CheckLockTimeVerify (CLTV) in the cheating transaction, which is adjustable. So if A foresees that it'll be able to check in about once every 24 hours it'll require that the CLTV is at least that large, if it's once a week then that's fine too. You definitely do not need to be online and watching the chain 24/7, just make sure to check in once in a while before the CLTV expires. Alternatively you can outsource the watch duties, in order to keep the CLTV timeouts low. This can be achieved both with trusted third parties or untrusted ones (watchtowers). In the case of a unilateral close, e.g., you just go offline and never come back, the other endpoint will have to wait for that timeout to expire to get its funds back. So peers might not accept channels with extremely high CLTV timeouts. -- Source
What Are Lightning’s Advantages?
Tiny payments are possible: since fees are proportional to the payment amount, you can pay a fraction of a cent; accounting is even done in thousandths of a satoshi. Payments are settled instantly: the money is sent in the time it takes to cross the network to your destination and back, typically a fraction of a second.
Does Lightning require Segregated Witness?
Yes, but not in theory. You could make a poorer lightning network without it, which has higher risks when establishing channels (you might have to wait a month if things go wrong!), has limited channel lifetime, longer minimum payment expiry times on each hop, is less efficient and has less robust outsourcing. The entire spec as written today assumes segregated witness, as it solves all these problems.
Can I Send Funds From Lightning to a Normal Bitcoin Address?
No, for now. For the first version of the protocol, if you wanted to send a normal bitcoin transaction using your channel, you have to close it, send the funds, then reopen the channel (3 transactions). In future versions, you and your peer would agree to spend out of your lightning channel funds just like a normal bitcoin payment, allowing you to use your lightning wallet like a normal bitcoin wallet.
Can I Make Money Running a Lightning Node?
Not really. Anyone can set up a node, and so it’s a race to the bottom on fees. In practice, we may see the network use a nominal fee and not change very much, which only provides an incremental incentive to route on a node you’re going to use yourself, and not enough to run one merely for fees. Having clients use criteria other than fees (e.g. randomness, diversity) in route selection will also help this.
What is the release date for Lightning on Mainnet?
Lightning is already being tested on the Mainnet Twitter Link but as for a specific date, Jameson Lopp says it best
Would there be any KYC/AML issues with certain nodes?
Nope, because there is no custody ever involved. It's just like forwarding packets. -- Source
What is the delay time for the recipient of a transaction receiving confirmation?
Furthermore, the Lightning Network scales not with the transaction throughput of the underlying blockchain, but with modern data processing and latency limits - payments can be made nearly as quickly as packets can be sent. -- Source
How does the lightning network prevent centralization?
Bitcoin Stack Exchange Answer
What are Channel Factories and how do they work?
Bitcoin Stack Exchange Answer
How does the Lightning network work in simple terms?
Bitcoin Stack Exchange Answer
How are paths found in Lightning Network?
Bitcoin Stack Exchange Answer
How would the lightning network work between exchanges?
Each exchange will get to decide and need to implement the software into their system, but some ideas have been outlined here: Google Doc - Lightning Exchanges
Note that by virtue of the usual benefits of cost-less, instantaneous transactions, lightning will make arbitrage between exchanges much more efficient and thus lead to consistent pricing across exchange that adopt it. -- Source
How do lightning nodes find other lightning nodes?
Stack Exchange Answer
Does every user need to store the state of the complete Lightning Network?
According to Rusty's calculations we should be able to store 1 million nodes in about 100 MB, so that should work even for mobile phones. Beyond that we have some proposals ready to lighten the load on endpoints, but we'll cross that bridge when we get there. -- Source
Would I need to download the complete state every time I open the App and make a payment?
No you'd remember the information from the last time you started the app and only sync the differences. This is not yet implemented, but it shouldn't be too hard to get a preliminary protocol working if that turns out to be a problem. -- Source
What needs to happen for the Lightning Network to be deployed and what can I do as a user to help?
Lightning is based on participants in the network running lightning node software that enables them to interact with other nodes. This does not require being a full bitcoin node, but you will have to run "lnd", "eclair", or one of the other node softwares listed above.
All lightning wallets have node software integrated into them, because that is necessary to create payment channels and conduct payments on the network, but you can also intentionally run lnd or similar for public benefit - e.g. you can hold open payment channels or channels with higher volume, than you need for your own transactions. You would be compensated in modest fees by those who transact across your node with multi-hop payments. -- Source
Is there anyway for someone who isn't a developer to meaningfully contribute?
Sure, you can help write up educational material. You can learn and read more about the tech at You can test the various desktop and mobile apps out there (Lightning Desktop, Zap, Eclair apps). -- Source
Do I need to be a miner to be a Lightning Network node?
No -- Source
Do I need to run a full Bitcoin node to run a lightning node?
lit doesn't depend on having your own full node -- it automatically connects to full nodes on the network. -- Source
LND uses a light client mode, so it doesn't require a full node. The name of the light client it uses is called neutrino
How does the lightning network stop "Cheating" (Someone broadcasting an old transaction)?
Upon opening a channel, the two endpoints first agree on a reserve value, below which the channel balance may not drop. This is to make sure that both endpoints always have some skin in the game as rustyreddit puts it :-)
For a cheat to become worth it, the opponent has to be absolutely sure that you cannot retaliate against him during the timeout. So he has to make sure you never ever get network connectivity during that time. Having someone else also watching for channel closures and notifying you, or releasing a canned retaliation, makes this even harder for the attacker. This is because if he misjudged you being truly offline you can retaliate by grabbing all of its funds. Spotty connections, DDoS, and similar will not provide the attacker the necessary guarantees to make cheating worthwhile. Any form of uncertainty about your online status acts as a deterrent to the other endpoint. -- Source
How many times would someone need to open and close their lightning channels?
You typically want to have more than one channel open at any given time for redundancy's sake. And we imagine open and close will probably be automated for the most part. In fact we already have a feature in LND called autopilot that can automatically open channels for a user.
Frequency will depend whether the funds are needed on-chain or more useful on LN. -- Source
Will the lightning network reduce BTC Liquidity due to "locking-up" funds in channels?
Stack Exchange Answer
Can the Lightning Network work on any other cryptocurrency? How?
Stack Exchange Answer
When setting up a Lightning Network Node are fees set for the entire node, or each channel when opened?
You don't really set up a "node" in the sense that anyone with more than one channel can automatically be a node and route payments. Fees on LN can be set by the node, and can change dynamically on the network. -- Source
Can Lightning routing fees be changed dynamically, without closing channels?
Yes but it has to be implemented in the Lightning software being used. -- Source
How can you make sure that there will be routes with large enough balances to handle transactions?
You won't have to do anything. With autopilot enabled, it'll automatically open and close channels based on the availability of the network. -- Source
How does the Lightning Network stop flooding nodes (DDoS) with micro transactions? Is this even an issue?
Stack Exchange Answer

Unanswered Questions

How do on-chain fees work when opening and closing channels? Who pays the fee?
How does the Lightning Network work for mobile users?
What are the best practices for securing a lightning node?
What is a lightning "hub"?
How does lightning handle cross chain (Atomic) swaps?

Special Thanks and Notes

  • Many links found from awesome-lightning-network github
  • Everyone who submitted a question or concern!
  • I'm continuing to format for an easier Mobile experience!
submitted by codedaway to Bitcoin [link] [comments]

Update UNO wallets to 0.11.0

UNOBTANIUM WALLET UPDATE. It's time to update your UNO QT wallet to 0.11.0 for bip65 support and misc fixes.
Get a compiled wallet at or roll your own from
This is an important update for enabling BIP65 consensus that will enable checklocktimeverify
BIP65 has been active in Bitcoin for nearly 5 years. The UNO network wants to enable this to enhance exchange safety and enable p2p 'atomic swap' apps. We need a consensus on the UNO network, which we have, but we want EVERYONE using the 0.11.0 wallet for the best network experience.
More info from the Bitcoin implementation of BIP65:
" In late 2015, the BIP65 soft fork[3] redefined the NOP2 opcode as the CheckLockTimeVerify (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block. "
submitted by FallingKnife_ to Unobtanium [link] [comments]

Bitcoin Unlimtited version available now with public labels (aka voting) and coin freezing!

Recently I've been working on a pull request for Bitcoin Unlimited.
This is in the coin_freeze_cltv branch based on dev. It contains features for the user to freeze coins, to associate public labels with a transaction amount (aka voting) as well as fixes for transaction searching.
These features can be merged into Bitcoin Unlimited but we need more user feedback and testing. If you can help test and provide feedback that would be great. If you can help create a deb package for the source that would also be a great help. Otherwise if you could just provide general feedback and let the other devs know if you want these features. If there is demand I will code more .... right now I am thinking about a Bitcoin Supply Chart in the Overview tab that incorporates the mining scchedule, frozen coins and compares your wallet balance versus current and upcoming supply. Freezing coins could be a powerful way for users to indicate which side of a fork they prefer. I also have prepared a draft design of an onchain exchange(ONX) between pre&post fork coins. In this way the community can bet on forking before it happens ONCHAIN!
Regarding associating public labels with a transaction amount other than zero that is not native as amounts in the same output as the OP_RETURN are NOT spendable. So this feature was achieved by associating OP_RETURN public label output with the following UTXO. In this way public labels are associated with transaction amounts and so the community can use the same public label to vote on the same topic! The user spends to themselves using a public label and in so doing commits the amount toward that publc label. When multiple users use the exact same public label their unspent amounts are aggregated. The "Top Public Labels" are therefore available as a list on their own tab sorted by the aggregate of UNSPENT amounts currently associated with the public label. When a user wants to unvote their coins they just spend them again with a new public label or none.
submitted by redmarlen to btc [link] [comments]

Understanding the Lightning Network, Part 3: Completing the Puzzle and Closing the Channel

Understanding the Lightning Network, Part 3: Completing the Puzzle and Closing the Channel
Understanding the Lightning Network, Part 3: Completing the Puzzle and Closing the Channel
The Lightning Network is probably the most highly anticipated technological innovation that will be deployed on top of Bitcoin. The payment layer, first proposed by Joseph Poon and Tadge Dryja about a year ago, promises to support a virtually unlimited number of off-chain transactions among users, at nearly no cost – while leveraging the security offered by Bitcoin.
At least three companies – Poon and Dryja's Lightning, Blockstream and Blockchain – are currently working on implementations of the technology. But few outside this small technological frontline fully grasp how the “future of micropayments” is set to boost Bitcoin’s capabilities.
In this three-part series, Bitcoin Magazine lays out the basic building blocks of the Lightning Network, and shows how they fit together to realize this upcoming protocol layer.
The first part of this series covered basic building blocks, and explained how these are used to establish bidirectional payment channels. The second part explained how a network is formed, and how Hash Timelock Contracts (HTLCs) link different channels in the network together. This third and final part of the series explains how HTLCs are placed inside bidirectional payment channels to ensure transactions can occur fully off-chain.
The Lightning Network
So far, Alice and Bob opened a bidirectional payment channel, which they both funded with five bitcoins. They've made two transactions back and forth, and at the current channel state, both Alice and Bob can claim five bitcoins for themselves by “dropping the channel” on the blockchain.
Now, they want to include an HTLC in the channel. This is to ensure that if Carol claims a bitcoin from Bob in return for her value, Bob is guaranteed a bitcoin from Alice in return.
Like the previous step, Alice and Bob start by creating a new commitment transaction each. In many ways, these commitment transactions are very similar to previous commitment transactions. They include a normal output, and an output to a funky multisig-address with a CSV (CheckSequenceVerify)-timelock and a special hash-lock. Likewise, as in the previous step, Alice and Bob exchange their old secrets, to effectively invalidate the old channel. And, once exchanged, both Alice and Bob can sign their halves of the commitment transactions and potentially drop them on the blockchain at any time.
All familiar territory. Except for one change. Both Alice’s and Bob's commitment transactions now include one new output, worth one bitcoin. (This makes the balance 4-5-1; four for Alice, five for Bob, one for the new output.)
This new output is essentially the HTLC. And it's even funkier than all other outputs so far, because there are three ways to unlock it.
First, the new output (in both Alice’s and Bob's commitment transactions) releases the bitcoin on condition that Bob's signature and the value is included in the subsequent transaction. As such, regardless of whether Alice or Bob signs and broadcasts the commitment transaction, only Bob can unlock this output – if he includes the value. But there is one small difference between the two commitment transactions: if Bob drops the channel, there is a CSV-timelock involved. He will need to wait 1,000 blocks. (If Alice drops the channel he can claim this bitcoin immediately.)
The reason Bob has to wait 1,000 blocks if he drops the channel is very similar to what we've seen before: It allows Alice to take this bitcoin in case Bob ever tries to sign and broadcast an old channel state. That's where the second way to unlock the output comes in. Alice can “steal” the funds if she provides Bob's (newest) secret.
Two can play this game: If Alice ever tries to cheat and broadcast this channel when it's already outdated, Bob can claim this bitcoin using Alice’s secret. (He wouldn't even need to provide the value.)
And third, as with any other HTLC, both commitment transactions also include the usual CLTV time-out fall-back for Alice. If Bob does not include the value in - say - two weeks (for instance because he didn't get it from Carol), Alice can claim her bitcoin back. Again, whether Alice or Bob drops the channel doesn't matter for this option.
So where did all this get us?
Both Alice and Bob hold a half-valid commitment transaction. If Alice drops her commitment transaction on the blockchain, she immediately sends five bitcoins to Bob. Additionally, she can wait for 1,000 blocks, and claim four bitcoins for herself. Plus, Bob has two weeks to provide the value, and claim the bitcoin in “HTLC output.” (If he doesn't provide the value in two weeks, Alice can claim this bitcoin back.)
Bob, meanwhile, can drop his commitment transaction at any time as well, and immediately send four bitcoins to Alice. Then, he'd have wait 1,000 blocks to claim five more bitcoins from one address, and another bitcoin from the HTLC output if he provides the value. (If he doesn't provide the value in two weeks, Alice can reclaim it.)
And of course, if either Alice or Bob tries to cheat at any point in the future, and sign and broadcast this channel when it’s outdated, both can completely block the other, and steal all bitcoins in the channel.

Settling the Status
At this point, Bob is guaranteed to receive a bitcoin in exchange for the value (assuming he has it). All he has to do is sign and broadcast the commitment transaction he got from Alice, include the value in a subsequent transaction, and sign and broadcast that as well.
Alice knows this. There is no way she can cheat Bob out of his bitcoin – not even if she found out what the value is through some other means.
As such, the two might as well just “settle” outside of the channel. Bob can simply give the value to Alice, and Alice can agree to update the channel status to the more normal state without the HTLC and the time-out deadline.
Assuming both parties want to keep the channel open, that's what they would naturally do: it's less of a hassle than having to drop the channel on the blockchain.Payment Channel

Closing the Channel
And finally, here's the real power of the Lightning Network: Almost everything described in these three articles will typically never need to hit the Bitcoin blockchain at all.
If both Alice and Bob want to close the channel “peacefully” they can simply create a transaction from the original opening transaction to override everything that happened since the opening transaction. From this closing transaction, they send themselves their fair share of the channel, as represented by the most recent channel state.
Concretely, this means that if Alice wants to close the channel, she can at this point simply create a transaction paying herself four bitcoins and Bob six, and ask Bob to sign and broadcast the transaction. Since there is no reason for him not to, he will probably cooperate and close the channel.
In the end, only two transactions will have been broadcast over the Bitcoin network and included in a block: the opening and the closing transactions. That will hold true even if Alice and Bob transact a million times in between, therefore unloading a huge burden away from the blockchain.

submitted by InziderX to u/InziderX [link] [comments]

Understanding the Lightning Network, Part 2: Creating the Network

Understanding the Lightning Network, Part 2: Creating the Network
The Lightning Network is the probably most highly anticipated technological innovation to be deployed on top of Bitcoin. The payment layer, first proposed by Joseph Poon and Tadge Dryja about a year ago, promises to support a virtually unlimited number of off-chain transactions among users, at nearly no cost – while leveraging the security offered by Bitcoin.
At least three companies – Poon and Dryja's Lightning, Blockstream and Blockchain – are currently working on implementations of the technology. But few outside this small technological frontline fully grasp how the “future of micropayments” is set to boost Bitcoin’s capabilities.
In this three-part series, Bitcoin Magazine lays out the basic building blocks of the Lightning Network, and shows how they fit together to realize this upcoming protocol layer.
The first part of this series covered basic building blocks, and explained how these are used to establish bidirectional payment channels. This second part explains how bidirectional payment channels are turned into a network.
The Network
In the previous article, Alice and Bob established a bidirectional payment channel. Now, Alice wants to pay one bitcoin to a third person, Carol.
To do so, Alice and Carol could open up a payment channel between them. But they don't actually need to. As it turns out, Bob and Carol already have a mutual channel, so Alice can simply pay Carol through Bob.
Specifically, Alice can pay Bob one bitcoin, and Bob can pay Carol one bitcoin.
However, Alice doesn't really trust Bob – or Carol for that matter. She's afraid that if she pays Bob, Bob will never actually pay Carol. Or perhaps Bob will pay Carol, but Carol will claim she never received the money, and Alice wouldn't know whom to blame.
Alice, therefore, wants to ensure that she only pays Bob one bitcoin, if he also pays Carol one bitcoin. This is accomplished (in part) with a simple cryptographic trick.
When Alice wants to send Carol a bitcoin, she tells Carol to create a value (a random string of numbers) and send her the hash. Alice also tells Carol to exchange the original value with Bob for a bitcoin.
Alice, meanwhile, takes the hash from Carol, turns to Bob, and tells Bob she will give him a bitcoin if he provides her the corresponding value (which only Carol has).
So, Bob turns to Carol, and gives Carol one bitcoin in return for the value.
Then, Bob turns back to Alice with the value. Alice knows Bob must have gotten the value from Carol in exchange for a bitcoin, and therefore concludes Carol got her bitcoin. So Alice can confidently give Bob a bitcoin.
Everybody is happy.

Well. .. almost everybody is happy.
In this “naive” scenario, middleman Bob still has to trust Alice and Carol. Bob has to trust Carol to really give him the value after he sent her a bitcoin, and Bob has to trust Alice to really give him a bitcoin once he presents her the value.
The bitcoin-for-value trades must therefore be absolutely guaranteed along the network. More specifically: if Bob gives a bitcoin to Carol, he must be guaranteed to get a bitcoin back from Alice.
That's where Hash Time-Locked Contracts (HTLCs) come in.
Hash Time-Locked Contracts
So Alice and Bob want to exchange a bitcoin for the value through an HTLC. (And Bob and Carol also want to a bitcoin exchange for that same value - but never mind that for now.)
To do so, rather than sending Bob a bitcoin straight up, Alice sends a bitcoin to a new (and, again: funky) multisig address. The bitcoins locked up on this address can be unlocked in two different ways.
The first option is for Bob to include his signature and the value.
The second option is for Alice to include her own signature. However, this option has a CLTV-timelock on it: Alice can sign and broadcast the transaction only after – say – two weeks have gone by.
This means that Bob has two weeks to create a subsequent transaction in which he includes his signature and the value, and broadcast it to send the bitcoin from the funky multisig address to himself. As such, this trade is guaranteed. Bob can only claim Alice's bitcoin if he provides the value: broadcasting it over the Bitcoin network makes it publicly visible for Alice to see.
And if Bob doesn’t provide the value in time, there is a “time-out alternative” for Alice to get her bitcoin back. Simple.
Back to the network, as that’s really why this HTLC setup is needed.
As mentioned, not only Alice and Bob, but also Bob and Carol established an HTLC. So, if Carol claims her bitcoin from Bob, Bob will get the value in return; it will be visible on the blockchain.
Therefore, if that happens, Bob is guaranteed to get a bitcoin from Alice as well. Bob can take the value that Carol made publicly visible on the blockchain, include it in his HTLC with Alice, and claim a bitcoin for himself, too. The two channels are effectively linked.
As a final detail, it is important that Bob gets the value from Carol before Alice can reclaim her bitcoin from Bob. If Bob gets the value from Carol only after Alice already reclaimed hers back, Bob is stuck in the middle after all. The time-out in Bob and Carol’s HTLC must therefore expire before the time-out in Alice and Bob’s HTLC expires. (For example after exactly ten days, instead of two weeks. This is also why HTLCs need CheckLockTimeVerify (CLTV)--and not CheckSequenceVerify (CSV).)

Lastly, there's one more problem to solve: for the Lightning Network to be useful, all this must be accomplished off-chain. How this is done, is covered in the third and final article of this series.
#InziderX #Exchange #ico
submitted by InziderX to u/InziderX [link] [comments]

[uncensored-r/BitcoinMarkets] Bitcoin Tech Rant - Happy New Year: Atomic Cross Chain Swaps

The following post by L14dy is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link: BitcoinMarkets/comments/7n5dwi
The original post's content was as follows:
I didnt have much success with the last Tech Rant, so I decided to do another. Please provide feedback.
So the topic for this tech rant is Cross Chain Swaps. They’re pretty simple, but require a bit of understanding of Bitcoin Script. I will start off with on-chain swaps.
So, let’s assume I want to swap testnet BTC for mainnet BTC with you (for instance if someone wants millions of testnet coins and is willing to pay 0.01 BTC for them). How would you be able to pay me and ensure that you actually get the testnet coins? Well, the easiest way is for us to agree that u/jaderadej will be our escrow. We both trust him, so we he generates an address and provides this address to the both of us. We then each generate a new address and provide it to u/jaderadej. At this point we both send our coins to the address he generated. One tx on testnet and the other on mainnet. As soon as u/jaderadej receives the coins from both of us, he does the swap (minus his “fee”). If I send coins but you dont, then he sends them back to me. If you send coins but I dont, then he sends them back to you.
Now, this works fine as long as we both trust u/jaderadej, and we do, but what if the only person willing to do it is u/pineconecandle. Well, I dont trust u/pineconecandle ;), so why would I do this deal? I wouldn’t. Hence, we need to do it without a third party. And this is possible in Bitcoin.
The first thing you need to understand is how OP_IF works. Basically OP_IF allows you to create a conditional branch of your PubKey Script. The second thing you need to udnerstand is how OP_CLTV works: OP_CLTV stands for Check Lock-Time Verify. It is an OP_Code that accepts an integer as input, which is either interpreted as a unix timestamp or as a block number (there is a convention on when the integer is interpreted as which, you can google it if you care). So now we can create a PubKey Script on a UTXO that has one PubKeyScript branch OP_IF OP_CLTV {Script1} OP_ELSE {Script2}
Ok, so enough with the preliminaries. On to the actual protocol.
I have testnet coins and you want to buy them. So what you do is you generate a random byte string (some random sequence of bits with enough entropy to ensure I cant brute force it before the lock-time we agree upon is up. If you use a cryptographically strong random number generator that will be fine. You generate this random number and hash it, i.e. OP_SHA256 or OP_RIPEMD160, whichever of the two is fine. Usually you would SHA.
I generate an address and provide you with the hash of my public key.
You then also generate a new address and send both the hash and the new hash of the public key to me. You now spend you 0.01 BTC to an output with a PubKey Script like the one above where Script 1 is just a normal P2PKH for your new address and Script 2 is a simple pre-image check combined with a P2PKH for my address, i.e. first hash the first element in the SigScript, compare that it matches the commitment value for the hash and finally check the standard P2PKH Script, i.e. soemthing like
Now, eventually I will see this transaction show up on the mainnet blockchain. Since you are the one looking to buy from me, you pony up the cash. Now, if I change my mind and walk away your coins are not gone. Once the lock-time is up, you can just use you knowledge of the private key to your address to create a SigScript that satisfies Script 1 above. So far no trust needed... you will NOT lose your coins.
Ok, but I want to sell my testnet coins, so I decide to Pony up the testnet coins. I spend them to an output with the same PubKeyScript, only that I reverse the roles of our public key hashes AND more importantly, I cut the lock-time in half. Since you have the hash, I want to make sure I get my coins back before you can take your BTC back, otherwise you could take both.
So now I spend to that and you see it show up on the testnet blockchain. If you decide to walk away, thats fine. I can just get my testnet coins back in half the time you can. Again, no trust needed. Why? Well, even though you know the secret random number, since you dont control the private key associated to my address, you wont be able to satisfy the pubKey Script to take your BTC back and you cant take my testnet coins without revealing the secret random number in the SigScript of the spending transaction. Since all SigScripts are public information, you cant spend my testnet coins if you want to keep the random number secret.
Let’s assume we went through all this hassle to actually do the deal. So, now you spend the testnet coins to a new address that you control (P2PKH) by revealing the random number and providing a SigScript for the address you control in the OP_ELSE branch of the PubKeyScript.
As soon as you do that, I see the random number, and I can now spend your 0.01 BTC to an address I control using the Secret Random Number You revealed to me, along with the SigScript for the P2PKH of the address I control.
And voila. We just exchanges testnet BTC for mainnet BTC in a trustless fashion with no trusted third party using some pretty simple Cryptographic primitives. Done deal.
Now, notice a few things:
  1. You need to wait a bunch of confs before this can be done, because you want to avoid double spending of your counterparty (whom you do not trust)
  2. Tetsnet is kinda a stupid example, because its pretty easy to reorg the chain. I just didn’t wanna mention another coin.
  3. In Lightning this can be done instantly. No need to wait for confs and no need to wait too long for lock-times to expire. Basically it is achieved by routing the payment to yourself on the Lightning Network. You can also combine on-chain swaps with off-chain swaps. Pretty cool stuff. This is basically how decentralized exchanges would work on Lightning.
Ok, done. Hope you like it!
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

[Informational] [CC0] Keeping Bitcoin Peer to Peer

The purpose of full nodes in the Bitcoin network is manifold. They exist as sovereign arbiters of the true state of the currency, they welcome new entrants into the network by sharing the history of the shared ledger, and they work together to spread new transactions to every corner of the earth.
There are many ways to use Bitcoin that do not require the use of a full node, however a full node describes something that offers the best level of security and privacy. As long as it is practical to use a full node, it's strongly suggested that one be used.
The precautionary suggestion to use a full node is one in which the user must be proactive about their own safety. The safety recommendation is analogous to wearing a seat belt in a car, or using a prophylactic device in an amorous encounter. Following a general guideline for safety that incurs some unwanted cost might not be immediately obvious, but on sober reflection of all the risks ignoring the guideline can be seen to be a mistake.

Strength in Numbers

The link between Bitcoin's health and the health of the full node peer to peer network is often stated. This is because a distributed network of redundant peers is seen as the most durable configuration possible. Thousands upon thousands of full nodes give strength to the network through herd protection. To sever a geographic link to the network, every node in the geographic area would have to be terminated, even a single remaining node could bridge the replication gap. It is seen that every additional user running a node translates to another brick in the wall keeping the network alive.
It's hard to determine the exact number of nodes on the network at any given time, because the network is designed to be distributed and decentralized, with each node giving thought only to its connected peer nodes and not the greater network. Despite this design, services exist to attempt to map the nature of the network by deliberately attempting to connect to as many peers as possible. These services are easily misled by fake nodes, and they cannot easily connect to the vast majority of nodes behind firewalls or with other limiting factors, so their published data must be treated as suspect.

Node Cooperative Contribution

Nodes in the network act in a peer to peer way, meaning that they act as servers and clients. Acting as a client is a baseline requirement for every node, however some nodes can limit the ways in which they act as servers, to limit their costs or for other reasons. In a network of full nodes, the level of server-like nodes is not important beyond a certain degree due to the great level of redundancy and the low demands full nodes place on the network. Just like almost any server and client split network topology, clients may outnumber servers greatly without any ill effects.
There are a variety of methods in which a node may act as a server: relaying transactions and blocks, catching up other nodes on Blockchain history, helping peer discovery. Generally speaking, contributory full nodes service two types of clients: other full nodes, and light clients.
A full node server serving other full nodes generally speaking has very light requirements. Full nodes have very limited demands because they only require a tiny differential sync from their current state. This differential sync cost is easily covered by the altruism of other nodes, in a model generally seen as sustainable to a large degree.
A full node servicing light clients, also known as SPV clients, has a much more costly set of requirements. Light clients cannot query their own local data set and thus require syncs tasks which carry a high marginal cost in both networking and system resources. Covering this cost through generalized altruism is not seen as sustainable, so most light clients have moved to a model of querying more formalized servers instead of the network at large.

Full Nodes Promote Privacy

An important element of Bitcoin as a unit of account and a convenient medium of exchange is that every single unit of Bitcoin is equivalent to every other unit. If some coins became more valuable than other coins, despite their face value, it would make for a confusing and therefore lower utility experience in exchanging them.
Unfortunately, Bitcoins are implemented in such a way that every Bitcoin balance is accompanied by a wealth of metadata relating to its origin. This represents a risk to every unit being exchangeable for every other unit, also known as the fungibility of the currency. Coin metadata represents a risk to the coin owner's privacy that can have unwanted negative secondary consequences, such as being accused of being linked to a theft through the web of transactions.
Full nodes uniquely help the network and the user from this negative privacy outcome by carefully protecting the metadata surrounding balances and transactions. In wallets that do not sync the entire Blockchain, they must query outside third parties for information about the funds they control. This querying represents a leak of information: information that can link multiple addresses together, can link Bitcoin addresses to IP addresses, funds to identities and actions that tar the theoretically neutral value tokens with a harmful history of their use.
Bitcoin full nodes can even take obscuring metadata one step further, severing even the link of IP address to Bitcoin full node and transaction relaying by automatically detecting a local Tor connection and then rerouting connections using Tor to provide for the privacy of the node.

Full Node Validation Security

The security of a user's funds and exchanges using Bitcoin is guarantees by a set of rules that govern how Bitcoin works. These rules describe things like the total possible number of coins in the system, or the coin limit, which promotes the utility of Bitcoin as a scarce tradable commodity. People are incentivized to use full nodes to remove their risk of these rules being broken, and this also serves to limit the impact of rule breaking: validating nodes will refuse to relay and spread invalid data.
Other notable rules are the subsidy schedule, which describes how quickly the currency can be minted, double spending, which prevents a user from spending the same funds in two places, signature validation, which prevents unauthorized users from spending others' funds, the block size limit which promotes network durability by preventing network denial of service deliberately or indirectly, and Bitcoin script execution, which evaluates intelligent rules for spending coins, like the CLTV which prevents funds from being spent until a certain time.
The validation that a full node performs is complete and total. Every single piece of data supplied by a third party is checked, so that even if all information a full node receives is supplied by a malicious attacker, they cannot create any negative results by manipulating the supplied data. The one exception to this rule is a situation in which the full node itself is running on a compromised platform. Therefore it is considered that the most secure practice for using Bitcoin is to only run a Bitcoin node on a platform known to be secure: third party platforms like cloud services where trust is an unknown factor are not recommended.
Due to the stringent checks performed by full nodes rule violations are few and far between. However rule violations, even by miners, are not unknown, for example in July of 2015 invalid blocks were published to the network in multiple incidents. This proves in practice what is obvious in theory: data from third parties, even miners who are strongly incentivized to publish valid data, can at times be invalid, either maliciously or through simple error. A full node's validation mechanisms will automatically ignore invalid data from any source, even a miner, unlike many alternatives to a full node that offer reduced levels of validation.

Full Node Code Security

When selecting a wallet, important consideration should be given to the authorship of the wallet. Is the wallet open source? Has the code been reviewed? Has there been thorough security testing? Examining the methodology in developing and releasing a wallet can help prevent the use of malware that abscond with user funds, or buggy prototype wallets that lose coins through simple coding errors.
Bitcoin Core as the Bitcoin reference client represents a very thoroughly vetted wallet. The code produced by Bitcoin Core is seen by many eyes, the scope of the wallet is narrow and focused, the users of the wallet are wide and varied. Bitcoin Core is designed as a comprehensive client, meaning it should be seen as comprehensively reliable, and the code should be seen as thoroughly vetted and secure. These qualities help make Bitcoin Core a very attractive choice for security conscious use.

Altruism in Full Nodes

The Bitcoin network relies upon having some nodes to bear some costs without direct recompense. This mechanism generally relies upon altruism and default behavior. It's well understood that this is a weak mechanism, but realistic given a limited cost: some percentage of users of Bitcoin Core who are not inconvenienced by the limited costs of default altruism will not adjust their default settings and some percentage of Bitcoin users can be expected to even go out of their way to assist others in the network.
This system works because the cost of altruism is capped. Servicing the requests of other nodes can be extremely inexpensive, running a node from home barely carries a negative impact: through the effort of many hands light work is made of the task of keeping the network running.

Efforts to Reduce Node Operational Cost

Creating a positive result in the cost benefit analysis of running a full node can be attacked from both sides: cost and benefit. The benefits of running a full node are great: financial privacy, security, self-determination, and altruistic fulfillment. But if the costs of running a full node outweigh those benefits, a user may not pursue the full node path, leading to their sacrifice of those potential benefits and the networks' loss of the marginal durability value they represent. For this reason, minimizing node cost has been a strong priority of the Bitcoin Core project: CPU, memory, disk storage, bandwidth have all been heavily optimized over many years of work.
One oft lamented cost center of Bitcoin Core is the cost of storing the Blockchain, the entire history of transactions. The Blockchain network design calls for this shared history to be stored in a distributed fashion, but its growth to tens of gigabytes of data over the years has made that burden something of a hot potato. To address this, in Bitcoin Core version 0.11.0, a major new feature was added to reduce this burden by eliminating archival data, in a feature known as pruning. Pruning turns the storage burden of tens of gigabytes of Bitcoin data into a small two to three gigabyte task, even pruning progressively on initial syncs. Pruned nodes cannot help catch up other nodes, but they can still help the network stay in sync with the all important trailing differential that is all that caught up full nodes nodes require.
Another great technical barrier to syncing the Blockchain is the CPU cost of validating the cryptographic signature that accompanies every movement of funds. Marginally a signature cost is small, but the impact of tens of millions of transactions means that syncing the chain is a lengthy task even for the most powerful computing devices. To address this the Bitcoin Core developers worked for many years on an optimized version of their signature algorithm, resulting in the highly optimized libsecp256k1 signature library. This library was put into full use in Bitcoin Core version 0.12.0, resulting a massive seven hundred percent improvement in signature validation speed, making Blockchain sync much more accessible to a wider range of users and devices.
Bitcoin transactions have a limited memory footprint: at the median transaction size a single transaction requires about the same amount of memory as two Tweets. Thousands of transactions can fit in active memory without issue. Even with transactions' limited memory footprint, memory utilization still represents a significant cost center for some users, or in some unlikely but possible scenarios where unconfirmed transactions rise to extremely high levels. To address this memory usage issue, Bitcoin Core added a discrete limiter: the mempool size option. This makes the trade-off of ignoring unlikely to confirm transactions for the benefit of allowing a fixed cap on full node memory demands.
To address bandwidth costs, Bitcoin Core added an upload limiter to put a cap on upload bandwidth, and a new blocksonly configuration option that limits the download bandwidth requirement to a maximum of about two thousand bytes/second, well within reach of even a standard dialup modem.
In addition to optimizations to reduce the marginal burden of transactions, optimizations were also made to lift the weight of the initial Blockchain sync. After users began to be forced into using BitTorrent to perform the initial sync of the large Blockchain data files, Bitcoin Core developers integrated a superior solution into Bitcoin Core itself, in a mechanism called headers-first sync that removes the bandwidth bottleneck to an initial sync. The initial sync may also be sped up by adjusting the dbcache option which allocates the syncing Bitcoin Core process additional memory beyond the low impact defaults of a standard Bitcoin Core install.
Beyond all these options stands a general firewall to the cost limits of Bitcoin Core. This firewall is known as the block size limit, and it puts a hard cap on the introduction of new costs on a node. Not all costs are limited by this, for example the set of transactions that are kept in memory instead of on disk or pruned is not strictly limited, only at a gross level does the block limit apply in that case. But generally speaking, the block limit is a general, final limit that protects the full node peer to peer network, and thus Bitcoin's durability, by promoting a low barrier to entry and thus a diverse and wide set of participants.
submitted by pb1x to writingforbitcoin [link] [comments]

[Informational] [CC0] Lightening Blockchain Load

Lightning Network

The Lightning Network is a concept proposed by developers Thaddeus Dryja and Joseph Poon to create a network of trust-less payment channels on top of the Bitcoin Blockchain. The goal of this network is to allow for instantaneously secure Bitcoin payments of any amount, no matter how small.


The Scalability Problem

From the earliest days of Bitcoin, critics took issue with its scalability characteristics. The very first response to Satoshi Nakamoto's described design was a total rejection of the system as being unable to deal with the enormous capacity demands of the world's economy. This message was the first, but far from the last time the scalability of Bitcoin would be called into question.
The reason for this skepticism is that in computer science, there are well understood system designs and algorithm designs, with vastly different costs. For example when a design calls for searching through a group of words, an adjustment to make the words alphabetically ordered can produce a potentially billion times faster solution. Simply by using a strategy of checking in exponentially reducing half sections, the search is executed at an exponentially reduced cost. The Blockchain is an example of a system in which growth of use does not just grow cost linearly, but instead at an exponentially increasing rate.
The reason for this inefficiency is that when the Blockchain adds a new member who needs to send payments, the new member incurs a cost on all the other members who have a need to fully validate payments. All fully validating members of the Blockchain must sync and validate everything all other members produce. From the perspective of the total system, this means that the total system cost is increasing as a power of two, the polar opposite outcome of what a more ideally scalable and efficient algorithm would yield.

Scalability Solutions

Satoshi Nakamoto realized this deficiency in his original proposal, and came up with a proposed solution. His idea was to reduce the operative mode of validation to be scoped to a user, for users who had less need to validate. Since additional members only incurred costs on validating members, skipping validation from some clients would mean that the impact of adding members was more limited, to be borne only by those who wished to dependably receive payments, such as merchants.
This method he named Simplified Payments Verification or SPV, and his original outlined plan would present a less secure but still acceptable model for normal consumers because there would be an alerting mechanism for rule breaches that would signify the system was compromised, proactively preventing attacks on consensus rules.
Although long promised, the demands of Bitcoin Core's development meant that Satoshi was never able to deliver on his promised SPV-mode client. Over time others took his ideas and appropriated the SPV name in making their own similar, but not quite equal solutions. Due to wide differences of opinion in the correct methods and workability of SPV mode, a reference project was never created and the alerting system was never crafted. Nevertheless as a working solution many people adopted lower security but more user friendly and less operationally costly wallets, in many varied configurations.
Eventually the efficiencies of SPV came to be seen as only a temporary optimization of the Blockchain design. Instead of solving the exponential cost of the Blockchain system, SPV clients could only slow the cost increases. The lack of an alerting system and other faults of SPV meant that anyone receiving payments could not rely on it, muting the model's positive impact on the total system scalability cost. SPV's dependency on miner validation made miner centralization concerns more pronounced.
The validation cost burden on merchants and on the overall system began to have secondary negative effects, such as contributing directly to mining centralization by giving outsize advantages to miners with economies of scale. The high cost of a full node contributed to merchant validation centralization by creating an increasingly high cost to validate payments. Many efforts were made to optimize against these increasing costs, but the fundamental design of the Blockchain meant that an increasing tide of transactions would one day overwhelm any possible optimization that did not address the basic peer broadcasting design.

The End of SPV

Another marked failing of SPV clients proved to be that they could never successfully be secured against financial privacy leakage. This represented a threat to users' personal privacy and even to the overall utility of the currency where all equal denomination coins, no matter their origin, should have close to an equal value.
SPV clients were also seen as unsustainable in a decentralized configuration: since they cannot sync with each other they must make increasing demands on the limited and increasingly costly altruism of the node operators.
SPV could also not provide a solution to another much lamented Blockchain problem: the limitations preventing micro-payments. Early on in Bitcoin's life, to fight floods of small transactions that were called penny-flooding, Satoshi had instituted barriers against very small payments: payments smaller than a tenth of a bitcoin were blocked.
Satoshi also created a prioritization system to improve the Blockchain's reliability for high value payments, a marketplace for transactions in every block, with space being prioritized to the highest value transactions as indicated by fees. This further pushed out very small payments, Satoshi often had to regretfully inform people that micro-payments were not feasible.
In the early years of Bitcoin, Satoshi Nakamoto and the other developers faced many and varied pressing immediate practical operational concerns and development realities of simply keeping the Blockchain reliable, durable and secure. Early plans for scalability and support for broad use-cases gave way to what was seen as the most important use-case: high value transactions with a high level of security and durability against network attack.
Over time the system's long-term scalability, various lower priority use cases, and difficult to implement features like instant settlement were all pushed to be developed outside of the Blockchain on a different layer, called Layer 2. Layer 2 systems would still empower transactions denominated in Bitcoin units and be ultimately settled against the Blockchain, but also be able to avoid offering the same guarantees and functionality as the Blockchain, in order to serve a broader range of use cases.
The Lightning Network is an example of a Layer 2 service: a network service that seeks to provide instant settlement, tiny micro-payments, improved privacy, in a system that is fundamentally built on the Blockchain but also logically separated.

Achieving Lightning

Lightning's solutions are based on a common and long running proposal for how to use the Blockchain to provide for instantly secure and arbitrarily small transactions: payment channels. Payment channels have existed for many years, in both well established theory and as real libraries and projects.
Payment channels are a method of using smart contracts to rapidly trade Bitcoin between two parties, without requiring the Blockchain for more than occasional settlement. The parties create a shared starting balance on the Blockchain and then using signed but un-broadcast transactions rapidly, cheaply, and privately update the balance between them.
Because the funds are locked in a multiple signature smart contract, cooperation with the channel partner is required to spend the funds, however a payment channel smart contract also specifies a timeout that acts an escape if there is a failure of cooperation. There are multiple ways to form these channels, but they all offer the same advantages: instant transactions, arbitrarily small denomination payments, low fees, and transaction privacy, although only between two joined together parties.
The key innovation in Lightning is to take these joined pairs and link them together in a network: pairs passing along funds to each other in a chain until they reach their destinations. This combines the Blockchain's benefit of sending to arbitrary users with all payment channel benefits like instantly secure transactions.

Opening Payment Channels

To open channels in Lightning, a Bitcoin transaction smart contract is published with rules for how deposited funds may be spent. The rules of the transaction essentially specify that funds deposited cannot be spent unless both parties agree, with the exception that one party can unilaterally refund his deposited funds to himself if he is willing to wait for a time delay before re-spending them.
The transaction establishing these rules is called a commitment transaction and a transaction that adds funds into this channel is called a funding transaction. For efficiency, when initiating the channel for the first time both transactions may be folded together into a single Blockchain transaction.
There are two proposed methods for accomplishing Lightning's channel timeout requirement. The first mechanism uses a feature called CLTV that first added to Bitcoin in the soft forking Bitcoin Core version 0.11.2, released in November of 2015. This feature allowed for time-locking funds against a certain date, meaning that channel partners could create fixed future time timeouts for their channels. Using this feature would mean that channels be routinely re-created to bump the timeout window forward.
Another method was also proposed, using a time-locking feature called CSV that was first added to Bitcoin in the soft forking Bitcoin Core version 0.12.1, released in April of 2016. CSV allowed for specifying relative time locking contracts, meaning that channel partners could instead choose their timeout relative to when they executed their channel escape clause, allowing for channels that could remain open indefinitely. Because of this improvement, CSV timeouts were selected as the standard for Lightning payment channels.

Instant Settlement

Lightning payment channels work pretty much like normal payment channels, they pass signed transactions between two parties to update their balance. There is however one unique aspect that allows for routing: a third party involved in a Lightning balance update transaction called an R value. This R value, which is simply a lumping together of information about the movement of funds, allows a transaction between parties to be routable. R values represent hash-able information that can be used as Blockchain presentable proof that funds have been moved across the Lightning Network.
To understand how the R value allows moving money through the interaction of third party Lightning Network actors, it's important to understand that when spending funds on the Blockchain it is not actually the people who authorize funds. Instead it is only their private keys' signatures that authorize spending, all Blockchain funds are actually locked in contracts that have various rules about how they may be unlocked, the most common being that a singular private key may be used to unlock them.
Because Blockchain contracts simply deal in signatures and are scriptable, it is possible to create a type of transaction that is keyed against a signatory who actually knows nothing about the transaction and simply testifies to a system state in a signed way. For example, a server that produced cryptographically signed statements about the weather could be used in a transaction between two parties to be the arbiter of the execution of a weather based funds transfer, without any direct involvement of the server in the transaction itself.
This type of transaction is rare, and it was banned as part of a blanket banning effort by Gavin Andresen and Jeff Garzik who objected to general purpose smart contracts on the Blockchain and promoted the idea of a white listing system called standard transactions. In February of 2014, the release of Bitcoin version 0.10.0 mostly lifted this restriction, allowing more novel transaction types. Included in the allowed transaction types were those keyed off of an arbitrary non participatory signature, called hash locked transactions.
In February of 2016, Sean Bowe and Pieter Wuille published a work in progress version of a special transaction type that could include a time locked transaction with a hash unlock code. This specific type of transaction, called a Hash Time Locked Contract or HTLC, enables the state changes within Lightning Network channels.
Lightning Network clients negotiate with the network to send out a transaction to be routed across the network, yielding an updated set of finalized settlement data which represents the settlement update hash lock solution, the R value. This R value is only represented to the Blockchain as an opaque signature, and it could signify any successful routing, including passing of value from the Bitcoin Blockchain to another Blockchain, like the Bitcoin Testnet.
This type of settlement transaction is very powerful, it can be used to create a wide variety of transactions, like multi-signature transactions within the Lightning Network, or even probabilistic settlements within the Lightning Network. A novel payment type called Pre-Image Length Probabilistic Payment, or PILPP has been proposed as a way to send payments on the Lightning Network that are actually provably probabilistic, meaning it is possible to send someone a one bitcoin with a fifty percent chance of arrival. Using this payment type, it is theorized that services could even charge sub-Satoshi fees for their services by asking customers for probabilistic payments of a single Satoshi.

Settlement Security

The Lightning Network offers a particularly private solution to executing a transaction, called onion routing, in a method similar to the online privacy system Tor, also known as The Onion Router. The way that Lightning Network transactions are executed, each client considers the destination for funds and then decides on a linked series of pairs to execute the transfer. The client then wraps the pair series information in an encrypted format so that each pair jump is only given information on a need-to-know basis. The intermediary relays are not given information about any of the other pairs, including the final destination of the transfer they are assisting.
To avoid a situation where pairs fail to execute their fund passing duty, routed payments are given a TTL, or a time to live, meaning that the payments are no longer valid after a certain point. This allows automatic retrying of payments that fail to route successfully due to a third party fund transfer failure. Transactions can also use fees to incentivize pairs to successfully pass funds in a timely manner; pairs that fail to route may bear an opportunity cost.

In Breach of Contract

From the Blockchain's perspective, Lightning Network funds are just funds deposited in a two of two signature multi-signature wallet. As the balance of funds changes within a channel, the settlement is actually done through a transaction that may be broadcast at any time to the Blockchain to settle funds back to each party.
With potentially thousands of balance state change transactions, the balance within the channel is intended to go up and down over time. This presents a major problem for payment channels: what happens if the other party broadcasts an obsolete state of the balance of payment to the network that ignores a recent payment, and therefore steals funds?
This situation in which there is a breach of the basic channel contract where an out of date state is broadcast can only be solved by correcting the Blockchain record in response, meaning the stored funds must be monitored for breaches. In the Lightning Network the solution to this issue is to preemptively prepare a special type of transaction called a breach remedy transaction that prevents the invalid old state from being used to steal funds.
A breach remedy transaction goes beyond reclaiming the injured party's funds. To discourage theft, the transaction also takes the entirety of the offending party's funds as a penalty. For this reason it is recommended that a channel never be allowed to empty, that some funds to take in penalty always remain, to avoid a situation called an exhausted channel.
Breach remedy transactions are formed as a part of every update to the balance of payments in a Lightning Network channel, in a flow called the Revocable Sequence Maturity Contract or RSMC. The RSMC flow is done without requiring trust in the other party, generating and exchanging the guarantees against betrayal before completing the funds state update.
Breach remedy transactions are fully formed, fully signed, and they may even be safely published to third parties with rewards for the first publisher attached, to incentivize many eyes watching for and preventing a breach of contract.

Closing Time

Sometimes channel participants may wish to close their channels, for regular channel rebalancing or just to make a Blockchain payment. Lightning Network transactions that settle back to the Blockchain are called exercise settlement transactions, and they are simply standard co-signed transactions. Funds are sent as in any standard multi-signature transaction and the channel is considered closed. This happens instantly, as long as the channel partner is cooperative.
In the event that a channel partner is unavailable to close the channel, another option is possible, which is to exercise the CSV clause specified in the channel opening contract. This clause says that any party may unilaterally close the channel and reclaim their funds, provided that they wait for a timeout period to spend their funds again freely.
This timeout period is called a dispute period, because it gives the channel partner a chance to dispute the channel close in the case of a breach of contract, when the channel is closed with an out of date balance of payments.

Potential Issues

There are a number of challenges inherent in the Lightning Network concept. In the most marked change from the Blockchain, Lightning flips the configuration of the network from a single shared Blockchain ledger to a wide array of individualized Lightning client ledgers. Users holding Lightning Network funds are holding funds that are just as good as Bitcoin, but the funds are actually signed claims on funds.
In the Blockchain a global ledger state is synced between everyone and a user must only save their private keys to retain control of their funds. In Lightning, securely holding both the key data and individualized ledger data is the responsibility of the client. One solution to this issue is to use the saved keys to securely encrypt the state data and then save the encrypted data to a networked backup.
Another departure from the Bitcoin network model that requires careful consideration is that Lightning transactions do not need to be broadcast to every member by relaying others transactions. Given a more limited number of transactions that are sent, this reveals more information as to the identity of the sender. To solve this, Tor channels could be used to obscure IP information from channel partners, but a more comprehensive and as yet undefined solution may be needed to help obscure other correlation efforts.
Funds in Lightning also work differently from Bitcoin funds. The Lightning channels lock the funds to an agreement with a Lightning relay, in which a set of cooperative rules are agreed upon to enable the Lightning protocol. But in the case of a cooperation failure, which can simply mean the connected Lightning relay suffering downtime, user funds will be locked from use for up to the preset lock time, which could be up to a week. To deal with this, it's suggested that the risk of locking be spread over multiple channels, or that a user be encouraged to limit their use of Lightning to smaller amounts of spending money. Spending down entire channels is also not an efficient use of Lightning, so that reinforces the idea of users separating their funds into spending money in Lightning channels and savings in traditional Bitcoin wallets.
Another tricky issue with Lightning funds is that a channel partner may try to steal funds from the channel. Wallets must either be semi-regularly online to prevent that, or third parties must be available who can be relied upon to prevent theft. Theoretically, miners could also execute a theft directly, by gaining majority control of the network for the dispute period and blocking any breach remedy transactions from occurring, although some of the standard guards against miners taking that action would still apply, such as their general block reward incentives. This means that Lightning benefits from a decentralized set of miners and a set of users who are able to access the Blockchain cheaply to respond to breaches of channel contracts.
There are actually two configuration types of Lightning, similar to how there are two common types of Bitcoin clients: light Lightning clients who only spend money occasionally, and full Lightning nodes who act as relays and comprise the body of the Lightning network. There is a benefit associated with running a Lightning relay: as transactions are passed through a relay, they carry a reward of small market-based fees. But there is also a potential cost with running a Lightning relay, these relays are software that must have the agency to move funds between their channels. Relays need to have some automated access to user funds, to complete the signatures needed for channel transaction routing. It is recommended that relay operators be sure to secure their systems from unauthorized access to protect the capital required to operate a relaying node. Lighter Lightning clients do not share this issue, by only connecting occasionally they may secure their funds in colder storage and through multi-signature setups, as is the standard for secure Bitcoin storage.


submitted by pb1x to writingforbitcoin [link] [comments]

The Return to Genesis - From @cryptoAcorns Perspective Live Bitcoin Chart & Gear Bitcoin Explained : Bull & Bear How to Open a Lightning Payment Channel ~ Bitcoin to the ... Live Bitcoin Chart : Bull or Bear

Want to know How much Bitcoin is 1 CoinLoan? 1 CoinLoan to BTC Calculator: Exchange Rate Price. Here you can check exchanges where you can trade CoinLoan to BTC pair. en; ru; de; zh Currencies; Exchanges; Trading pairs; Blog; Close. $348,36B. Total marketcap. $759,85B. Total volume. 57.00%. BTC dominance. en; ru; de; zh; coin data flow Crypto Charts. Currencies; Exchanges; Trading pairs; Blog ... The latest propaganda piece by Bitcoin ABC: "After the upgrade, Bitcoin ABC software will continue to be fully compatible with the Bitcoin Cash protocol, whereas alternative node implementations will become BCH-incompatible." More than 500 BCH have been sent through! Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community . Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Jobs; Unanswered ; Transaction still unspendable with CLTV. Ask Question Asked 1 year, 9 ... Bitcoin Wiki says: When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or grea... Stack Exchange Network Stack Exchange network consists of 177 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. People seem to have a misplaced idea that the SegWit-coin (BTC) Core developers are even adequate developers who understand Bitcoin and seek to make it work. Such ends cannot be logically ...

[index] [12955] [43241] [27694] [24344] [41088] [37868] [46444] [24609] [4132] [2512]

The Return to Genesis - From @cryptoAcorns Perspective

This video is unavailable. Watch Queue Queue. Watch Queue Queue Cryptocurrency news and market information from Be Cool Be Real Always Abide And Think Logically Twitter: @adamthedude420 Steemit htt... Bitcoin explained for beginners ! Hello guys here are the most relevant ICO for 2020 Sylare (SNL): About : New token developped by French team for privacy data in cryptocurrency (Your Data Belongs ... This is a presentation I gave at the Bitcoin SV San Francisco Meetup on 2/4/2020. I decided to record this on my YouTube channel so people can view it and get a high level understanding of the ... Bitcoin Liquidation Watch Livestream: Center Chart is 1hour bars. Along right side are the significant trades, with audio alerts turned on. Best crypto-friendly browser : Brave download it ...