CoinLoan (CLT) Price to USD - Live Value Today Coinranking

Weird behavior when scripting electrum's ECPrivkey(...).sign_transaction(...)

Update

Nevermind... Electrum is performing low-value R-grinding and bitcoinlib and CoinBin are not. For anyone interested, the grinding code his here. Nuking the while look makes the sigs the same.
A few days ago I used bitcoinlib to create a OP_CLTV transaction. Tonight I did the same with Electrum 4.0.4 via python and my sigs don't match.
The TXN I'm trying to match is:
The TXN has the following characteristics:
When I try signing the sighash (pre-image hash) using both bitcoinlib and Electrum 4.0.4, I get different results. I coded the TXN through another wallet as well (CoinBin), and bitcoinlib seems to be producing the proper signature, but Electrum's seems off.
I'm sure there is something simple I'm missing, but I can't figure it out.
Here's a test script to illustrate the differences:
``` from bitcoin.core.key import use_libsecp256k1_for_signing from bitcoin.core import x, b2x from bitcoin.wallet import CBitcoinSecret from electrum.ecc import ECPrivkey from electrum.bitcoin import EncodeBase58Check
use_libsecp256k1_for_signing(True) sechex = '535b755a4c265772c4f6c7e0316bfd21e24c9e47441989e14e8133c7cb2f41a3' hashhex = '9039c54c1c34aa12b69b4dda962f501bb6c9cdb6745014ef326f5d4d0472aa99' seckey = CBitcoinSecret.from_secret_bytes(x(sechex)) sig = seckey.sign(x(hashhex)) b_wif = str(seckey) b_pub = b2x(seckey.pub) b_sig = b2x(sig) seckey = ECPrivkey(x(sechex)) sig = seckey.sign_transaction(x(hashhex)) e_wif = EncodeBase58Check(b'\x80' + seckey.get_secret_bytes() + b'\x01') e_pub = seckey.get_public_key_hex(compressed=True) e_sig = b2x(sig) assert b_wif == e_wif assert b_pub == e_pub print("wif:", b_wif) print("pub:", b_pub) print("sighash:", hashhex) print("bitcoinlib sig:", b_sig) print("electrum sig: ", e_sig) 
```
The resultant sigs are:
Thoughts?
submitted by brianddk to Electrum [link] [comments]

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?

Future

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]

⚡ 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? ⚡

Explanations:

Image Explanations:

Specifications / White Papers

Videos

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 - yalls.org)

Medium Posts

Learning Resources

Books

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]

Libraries

Lightning Network Visualizers/Explorers

Testnet

Mainnet

Payment Processors

  • BTCPay - Next stable version will include Lightning Network

Community

Slack

IRC

Slack Channel

Discord Channel

Miscellaneous

⚡ 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 http://dev.lightning.community/resources. 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]

Let's be honest, we **all** care about price. So why do we never discuss valuation?

Valuation, not price. Is it to keep others in the dark, so the cycle of shilling continues? It's confusing to me, because everyone keeps saying 'this coin is undervalued', or 'that coin is overvalued' and then, when asked to back up their claims, they go on listing items on the project's roadmap or talking about the team.
I realize that many of you probably don't know what a valuation model is or why it works (to some extent, it's never perfect). Valuation models are especially useful in detecting whether a business (nearly all 2nd and 3rd gen cryptocurrencies are backed by business-like entities) is viable and using multiple different models will tend to yield some kind of 'reasonable range' for a project's market capitalization. If it's under, chances are that it's being underestimated (for cryptocurrencies, that chance is still very low, the entire industry is nascent and we are still in bubble territory). For example, let's take a SaaS (Software as a Service) company. Its most important metrics will likely be:
  1. Customer Acquisition Cost (CAC): the dollar amount the company needs to spend to gain a new customer. This is usually done via various marketing efforts, reputation/word of mouth or direct sales efforts.
  2. Customer Lifetime Value (CLTV): the total expected value our SaaS company can expect from an average customer over the course of their lifetime. By lifetime, we don't mean the client's actual lifespan, but rather the time they'll remain customers.
  3. Market size: the total size (in dollars) of the market the company is in. The bigger it is, the more potential the company has in terms of growth.
  4. Market penetration: the current share of the market the company currently captures.
If our company has a high CAC/CLTV ratio and poor market penetration, even if its market is ENORMOUS and their offering is good, it's unlikely to make a good investment. Growing would simply be too expensive. This is the same for cryptocurrencies. In my opinion, we need to think about valuation in this order:
  1. Philosophy: What is 'x' coin's vision for the future? Is it achievable? Why or why not? We don't go into technical details here, but rather simply examine the leading group/company/foundation/community's plan moving forward. If there are none, you should instantly become extremely skeptical. Right away, this exposes a type of project I personally consider malicious: clones. Bitcoin, Ethereum and other original projects' clones essentially never have a standalone vision. They rely on the reputation and promises of the original.
  2. Value distribution: Let's assume a team's grand vision is exciting, that it makes sense from a business and even tech perspective. How does that team intend to share value created? Most projects simply rely on having their token act as a currency, which is both lazy and dangerous, because it relies on a) high adoption levels, so a self-sustaining economy is created and b) lack of worthy competitors. Do you honestly think that, in the future, there'll be hundreds of economic micro-pockets that require their own currency?
  3. Technology: In concrete scientific terms, how is your project attempting to achieve its grand vision? This is where comparisons like network structure, hashing algorithms, throughput and others are relevant and yes, it only comes third on my list. Technology is a means to an end, not an end itself.
  4. Connections: What are the actors that will allow our technology to flourish? Are strategic partnerships needed? Will end users even be aware that they're using our technology? Partners are a sign of legitimacy, but that's just the beginning. Each and every cryptocurrency that exists today needs an ecosystem to surround it, for the sake of its liquidity, the realization of its use cases, etc.
Until we start creating and discussing valuation formulas, until we start extensively mapping our own vision of a post-DLT (distributed ledger technology) world as a community and calling out people who isolate facts to inflate the value of their own investment and shoot down competitors, we will not grow. We will certainly not help crypto become mainstream, either. The majority waits for safety and clarity before jumping on board, and we're here talking about sharding and audit trails in a vacuum, despite less than 10% of the space really understanding anything about it. We must work on the big picture, and it starts with trying to understand value.
submitted by bLbGoldeN to CryptoCurrency [link] [comments]

Probabilistic value outputs will allow to scale the lightning network to hundreds of trillions of accounts for almost no on-chain cost


" OP_CLTV and OP_CSV added time-dependent transaction/scripts. OP_DIFFICULTY has been proposed to add difficulty-dependent ones (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.html …). Making transactions depend on the hash of the block at height H (in the future) will enable on-chain probabilistic payments.
Lightning channels allow participants to perform an unlimited number of transactions. Probabilistic value outputs may enable for the creation of an unlimited number of Lightning channels.
The advantage of probabilistic value payment channels over channel factories (https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf …) is in the reduction of the potential damage one uncooperative participant can cause to the rest of the group in the form of settlement fees, although they can be complementary."
source : https://twitter.com/fnietom/status/1138016701646299136 (the whole thread and following replys are very interesting)
and https://github.com/zack-bitcoin/amoveo/blob/mastedocs/design/sortition_chains.md
submitted by lionmic to Bitcoin [link] [comments]

Value of a coin

This is a statement I back up 100%. Unfortunatelly I do not remember the autor, so please forgive my pirate deed. I just want to share an opinion I couldn't put better myself:
Value. Valuation, not price. Is it to keep others in the dark, so the cycle of shilling continues? It's confusing to me, because everyone keeps saying 'this coin is undervalued', or 'that coin is overvalued' and then, when asked to back up their claims, they go on listing items on the project's roadmap or talking about the team.
I realize that many of you probably don't know what a valuation model is or why it works (to some extent, it's never perfect). Valuation models are especially useful in detecting whether a business (nearly all 2nd and 3rd gen cryptocurrencies are backed by business-like entities) is viable and using multiple different models will tend to yield some kind of 'reasonable range' for a project's market capitalization. If it's under, chances are that it's being underestimated (for cryptocurrencies, that chance is still very low, the entire industry is nascent and we are still in bubble territory). For example, let's take a SaaS (Software as a Service) company. Its most important metrics will likely be:
Customer Acquisition Cost (CAC): the dollar amount the company needs to spend to gain a new customer. This is usually done via various marketing efforts, reputation/word of mouth or direct sales efforts.
Customer Lifetime Value (CLTV): the total expected value our SaaS company can expect from an average customer over the course of their lifetime. By lifetime, we don't mean the client's actual lifespan, but rather the time they'll remain customers.
Market size: the total size (in dollars) of the market the company is in. The bigger it is, the more potential the company has in terms of growth.
Market penetration: the current share of the market the company currently captures.
If our company has a high CAC/CLTV ratio and poor market penetration, even if its market is ENORMOUS and their offering is good, it's unlikely to make a good investment. Growing would simply be too expensive. This is the same for cryptocurrencies. In my opinion, we need to think about valuation in this order:
Philosophy: What is 'x' coin's vision for the future? Is it achievable? Why or why not? We don't go into technical details here, but rather simply examine the leading group/company/foundation/community's plan moving forward. If there are none, you should instantly become extremely skeptical. Right away, this exposes a type of project I personally consider malicious: clones. Bitcoin, Ethereum and other original projects' clones essentially never have a standalone vision. They rely on the reputation and promises of the original.
Value distribution: Let's assume a team's grand vision is exciting, that it makes sense from a business and even tech perspective. How does that team intend to share value created? Most projects simply rely on having their token act as a currency, which is both lazy and dangerous, because it relies on a) high adoption levels, so a self-sustaining economy is created and b) lack of worthy competitors. Do you honestly think that, in the future, there'll be hundreds of economic micro-pockets that require their own currency?
Technology: In concrete scientific terms, how is your project attempting to achieve its grand vision? This is where comparisons like network structure, hashing algorithms, throughput and others are relevant and yes, it only comes third on my list. Technology is a means to an end, not an end itself.
Connections: What are the actors that will allow our technology to flourish? Are strategic partnerships needed? Will end users even be aware that they're using our technology? Partners are a sign of legitimacy, but that's just the beginning. Each and every cryptocurrency that exists today needs an ecosystem to surround it, for the sake of its liquidity, the realization of its use cases, etc.
Until we start creating and discussing valuation formulas, until we start extensively mapping our own vision of a post-DLT (distributed ledger technology) world as a community and calling out people who isolate facts to inflate the value of their own investment and shoot down competitors, we will not grow. We will certainly not help crypto become mainstream, either. The majority waits for safety and clarity before jumping on board, and we're here talking about sharding and audit trails in a vacuum, despite less than 10% of the space really understanding anything about it. We must work on the big picture, and it starts with trying to understand value
submitted by GrimmReaperBG to CryptoCurrency [link] [comments]

The True Dark Web - "Bitcoin Gambling Addiction"

The cryptocurrency craze has been nothing short of a phenom, seeing billions and billions of dollars created out of thin air, seemingly what felt like overnight has been nothing short of a marvel to watch transpire.
The headlines, blogs, forums all speak of new found riches, what seem like buried treasures found yet, as new high’s are made for Bitcoin and other currencies, new lows of self worth are discovered daily by the countless gambling addictions that have popped up with the rise and adoption of cryptocurrencies like Bitcoin.
Available for iPod, iPhone, iPad, Mac, Windows, Linux, Android, Samsung, etc, 24/7, 365 days a week at lighting fast speeds. Deposit bonus’, VIP raffles for “free bitcoins”, holiday bonus’, VIP trips, personal hosts - yup, it’s all in there and at times - it is magnificent.
However, that is the single most toxic thing about gambling addiction - if even for the briefest of moments, that time it is “magnificent’ takes a grasp so powerful, so determined and so unlikely to be found again until the hooks are set, play play play, reward, play play play, reward are deeply embedded into our cognitive behavior and we have conditioned ourselves to only derive happiness from the briefest of moments that the brain thinks are “magnificent”
I am one of those soul’s who lost millions of dollars, friends, close relationships, values, moral compass and most importantly - my ability to derive self worth, self love and empathy until I was almost too far down the rabbit hole to turn back.
Some statistics suggest nearly 80% of all Bitcoin’s in circulation are used for online gambling. They are the ideal currency for such gaming activities - anonymous, instant and can be broken down into payments both big and small.
I am writing this not to shun any operators nor the industry, I am writing this to let the thousands of people across the world who are in pain that no words can truly describe from the ruin and shame that go hand in hand with gambling addiction see that they are not alone.
The cycle of destruction that comes with gambling addiction is on par with the greatest of natural disasters. I have had the fortune of experiencing almost every type of addiction one could experience, nothing even comes close to the grip, power and intensity of online gambling addiction.
Now, I can understand those reading have little room for sympathy, after all, gambling addiction is and has been portrayed as one of the most shameful addictions one can develop that are stigmatized by both the media and in real life.
The goal of this is to not earn anyone’s sympathy, I do not feel like a victim - these are choices I made however, the US Surgeon General (whom I have the greatest respect for going against the grain) has coined (no pun intended) any addiction as a “Cognitive Brain Disease”. This means that the chemical makeup of one’s brain is altered and is not a choice. The brain gets rewired to release the chemical dopamine only when a jackpot or “near jackpot” is obtained. Perhaps a brief explanation of the “gamblers high” will help put things into context.
If I am playing cards, and let’s say I had a good run and am up $1 million. Each win experiences diminishing marginal returns, this means that the pleasure or “high” I receive from each win decreases with each bet. In fact, even if I won another $1 million jackpot while up $1 million, it will offer significantly less of a “high” than if i were to be down $1 million.
The gamblers high, as little sense as it may make to some, is not experienced when someone is winning money. The gamblers high truly kicks in when someone is down big and comes out of nowhere with a big win.
The speed and velocity of such a swing, down $1 million to up $1 million (we call that a $2m swing) is the true “high” and the rush of that high is so great we chase it leaving our lives, pride and self worth behind. The force of that rush is so intense, gamblers will intentionally bet irrationally to lose their winnings simply so they can experience that rush. Like I said, it’s the most vicious addiction I have experienced
New technologies that show the game is “Provably Fair” allow players to instantly verify the “die roll” if you will to show that the outcome was already decided by the software before the person decided how much they would bet or what decisions they would make during the game. (Ex: the makeup of the shoe of cards in a game of blackjack)
I commend the industry for providing such transparency and unlike fiat currency gaming sites, offer the “fairest” chance of any gambler to “take down the house” however, it takes a bit more understanding of the psyche behind gambling addiction to understand the predatory nature of such sites and the bells and whistles used to retain those addicts over long periods of time to boost their CLTV (Customer Lifetime Value)
Technology has led to great advancements and power, with that comes responsibility. I am very much a believer in capitalism and feel very strongly a business should have the ability to take advantage of inefficiencies in a market to their advantage. I would simply ask the operators of such site to do this with caution, offer a sense of humanity and empathy and help educate players around loss limits, self exclusion and even offer help if a player is playing on “edge”.
While taking advantage of a market opportunity is one thing, taking advantage of someone’s emotional and financial vulnerability goes against every facet of our own humanity.
For those who are struggling with online gambling addiction or any addiction to that matter, I know all too well just how dark times can get, I feel your pain and understand that hope is a hard thing to come by when such a spiral takes hold. Turn to those who you love for help, be brutally honest in whatever you are experiencing no matter how much shame you think it may bring.
Shame is a funny thing, everyone has it, nobody likes to talk about it and the less we talk about it the more we have. The sense of relief and hope that offers almost instant gratification when you are honest with yourself and your families about your addiction is the biggest catalyst to overcoming the darkest of days.
Find yourself, no matter how hard or dark it may be, the rewards are greater than any jackpot can offer
submitted by peterpan212 to Bitcoin [link] [comments]

Bitcoin dev meeting in layman's terms (2015-10-8)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs link to meeting minutes
Main topics discussed this week where:
Mempool limiting: chain limits Low-S change CLTV & CSV review Creation of bitcoin discuss mailing list
off-topic but important notice
This issue has made most JS bitcoin software vulnerable to generating incorrect public keys. "This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR."
Mempool limiting: chain limits
(c/p from last week) Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is reffered to as "packages".
As said in "Chain limits" last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before: As example: someone buys bitcoin from a website and can spend those bitcoin in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don't need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What's not within the proposed limits is the chain of +/- 100 transactions a company had during the spam-attacks. These where simply increased activities by end-users while not enough UTXO's where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first. Ways this can be solved from the company's end is to have more UTXO's available before hand, bundling transactions (which requires delaying customer's request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bare in mind these proposals are for default values for the memorypool, not in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some solution!" Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors. Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).
Review & test Limit mempool by throwing away the cheapest txn and setting min relay fee to it Provide support for Lower default limits for tx chains aka convince people 25 should be enough.
Low-S change
This is in regards to the recent malleability attack. Which is caused by a value 'S' in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id's. more info A solution for this is to require nodes to have the "low-s" encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014) This does not replace the need for BIP62, it only eliminates the cheap DOS attack.
95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions. Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)
Contact miners about "Test LowS in standardness, removes nuisance malleability vector" Release scheduled for the end of the month, together with likely check-lock-time-verify and possibly check-sequence-verfiy.
CLTV & CSV backport review
CLTV: checkLockTimeVerify CSV: checkSequenceVerify Both new time-related OP-codes. Been discussed heavily last week.
Concerns whether CSV will be ready enough for release later this month. There's no clarity on how things look when all 3 time related pull-requests are merged. There's a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used. Now these bytes are being repurposed for a mixture of things. Currently the plan is: " bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand) Continue review of pull requests 6312, 6564 and 6566
Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden.
No clarity about who are the moderators. Next week there'll be a bitcoin-discuss list created. Decisions are needed as to who'll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies. A meeting is scheduled on monday to discuss the moderation and policies of said lists.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille BlueMatt Matt Corallo btcdrak btcdrak petertodd Peter Todd warren Warren Togami phantomcircuit Patrick Strateman dstadulis Daniel Stadulis GreenIsMyPepper Joseph Poon bsm117532 Bob McElrath
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-10-22)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Mempool Memory Usage LevelDB replacement Median Past locktime & CLTV
Short topics/notes
BIP 9 Versionbits PR #6816 is ready for implementation and needs more reviews.
A 3 month moderation period on the bitcoin-dev mailinglist has started, as well as a new list bitcoin-discuss. more details: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011591.html
"bitcoin.org had incorrect release notes for 0.11.1. It's corrected now. They had posted the release notes for the initial RC and not updated them. Process wise it would be good to watch out for that in the future."
Mempool Memory Usage
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing.
To stop this from happening devs created a mechanism to reject and/or remove transactions from the mempool. This mempool limiting got merged this week.
Also relevant: There is an already existing limit on the database cache size called "dbCache". The default value for that is 100MB.
Testing shows there's a discrepancy between the configured mempool limit and the actual memory usage. This is caused by the amount of UTXO data when processing transactions. This data is only flushed after a block is processed (so temporarily exceeding the cache limit set in dbCache).
There are 2 "obvious" solutions for this:
  1. Always enforce the UTXO cache limit, just like the mempool limit is always enforced. Downside for that is if you misconfigure your mempool limit an attack can blow away your UTXO cache, which significantly slows down validation and propagation.
  2. Take the UTXO cache into account when limiting the mempool. Downside for that is that you could construct transactions which require way more cache space and thereby more easily kick out other transactions.
A more optimal solution would be to give priority in the cache to things in the mempool. Ways to achieve that are to kick UTXO's from transaction that are evicted from the mempool out of the cache and from transactions that never made it into the mempool. Something TheBlueMatt is working on
Continue to research and optimize.
LevelDB replacement
LevelDB is the database system currently used in bitcoin. Since this is not being maintained for some time devs are looking for replacements.
jgarzik worked on a patch for SQLite Some people express concerns whether the performance will be good enough with SQLite, but there are no benchmark results yet.
Do research into other options Do lots of benchmarks and report results
Median Past locktime & CLTV
When a block is created miners include a timestamp. This timestamp has to be between the median of the previous 11 blocks and the network-adjusted time +2 hours. So this timestamp can vary a decent amount from the real time. With the introduction of lock-time transactions, that are only valid after a certain time, miners are incentivised to lie about the time in order to include time-locked transactions (and their fees) that wouldn't otherwise be valid. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behaviour. Users can compensate for this by adding 1 hour (6 blocks) to their lock times.
CLTV stands for CheckLockTimeVerify, BIP65 Commonly reffered to as: How you thought nLockTime worked before you actually tried to use it.
CLTV is ready to be merged (and has been merged at time of writing) Questions of whether to add median past locktime as mempool only or as softfork Overall questions as to what to include in the CLTV deployment, what to include as mem-pool only and what as softfork. Median past locktime violates current 'standard' behavior, so we would prefer to have that violation dead in the network before the median past locktime softfork moves forward.
review BIP-113: Mempool-only median time-past as endpoint for lock-time calculations review the CLTV backports (done and merged at time of writing) Backport median past locktime to 0.10 and 0.11
Participants
btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell BlueMatt Matt Corallo morcos Alex Morcos petertodd Peter Todd CodeShark Eric Lombrozo jgarzik Jeff Garzik maaku Mark Friedenbach kanzure Bryan Bishop jcorgan Johnathan Corgan Luke-Jr Luke Dashjr jonasschnelli Jonas Schnelli sdaftuar Suhas Daftuar
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-10-15)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Mempool limiting sendheaders BIP versionbits dev/discuss list policy CHECKSEQUENCEVERIFY
Mempool limiting
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing.
To stop this from happening devs are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can't be attacked by abusing this mechanism. So far the devs are going with TheBlueMatt's proposal of throwing away the cheapest txn and setting the min relay fee to it
While testing, sipa encountered transactions that took 200ms to be accepted into the mempool. As it's the first time he has benchmarked this and the pull-request shouldn't make an impact on these times it likely doesn't have anything to do with this. However, such times are bad either way. The average time in sipa's tests is 4ms. (After the meeting Morcos did some benchmarking and confirmed it was not specific to this PR, and pointed out the outliers come from CheckInputs and HaveInputs (as you might guess, having to do with checking the inputs) Question on why we should revert the minrelay (minimum fee for nodes to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the mempool issues), sipa thinks it should be floating as well or the dust limit becomes ineffective.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting min relay fee to it Morcos/sipa will do some more benchmarks and comment on the PR ( morcos' benchmark results )
sendheaders BIP
send headers BIP Copy/paste from the BIP: Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows:
  1. A node (N) announces the new tip with an "inv" message, containing the block hash
  2. A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself
  3. N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
Question on how to move forward. How to let the nodes know you want the blockheader instead of the blockhash. Options:
  1. Extend the version message.
  2. Have an "options" message that can send flags.
  3. Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
  4. Send a "sendheaders" message at any time, changing the way peers want their block announcement from hashes to headers.
No one likes to extend the version message further. There's no strong advantage to have an "options" message over a "sendheaders" message. Having the message being sent early on might be too constraining. Possible usecase from morcos: "its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don't". Most people like this to be enable-only, so no message to get back to receiving blockhashes. Which is how the BIP was drafted.
sdaftuar does a pull-request for the BIP to get a number assigned and proceeds with the BIP as drafted.
versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
copy/paste from IRC, since I don't know what this specifically means: CodeShark: so right now it's just a unit that implements the versionbits logic but does not demonstrate its usage I thought it would be better to actually integrate in a separate PR, but I can add a demonstration sipa: separate commit, same PR - i think we need something that's mergable as a whole, to be able to see whether the whole thing easily backports
Codeshark (who's implementing versionbits) had some more remarks but no one present had seemed to reviewed it, so not much use in discussing things further.
review versionbits implementation
dev/discuss list policy
The bitcoin-dev mailing list is intended for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden. For the things that don't belong on bitcoin-dev, but need to be discussed anyway there's a new list being created namely bitcoin-discuss as well as clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn't distributed to jgarzik who's willing to guide the moderation. Seperate moderation-proposals have been done meanwhile. People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we'll let them discuss it among each other and post their decisions publicly.
CHECKSEQUENCEVERIFY
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used). However, there's no way use these values in a bitcoin script. CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.
EDIT: Turns out this is not entirely correct as it is relative locktime that repurposes the nSequence field.
CLTV is pretty much done. Check to see maaku moving one of the bits to allow for other implementations to have better granularity has any objections. As long as we're using as few bits as possible the exact semantics are less important for most people. sipa points out a possible bug that influences the wallet. CSV is not on target for the end of of the month, although a lot of work and progress has been made.
Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint verification Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as endpoint for lock-time calculations
Participants
wumpus Wladimir J. van der Laan sipa Pieter Wuille btcdrak btcdrak gmaxwell Gregory Maxwell morcos Alex Morcos maaku Mark Friedenbach CodeShark Eric Lombrozo BlueMatt Matt Corallo sdaftuar Suhas Daftuar warren Warren Togami GreenIsMyPepper Joseph Poon davec Dave Collins cfields Cory Fields jonasschnelli Jonas Schnelli
Comic relief
19:21 sdaftuar it sounds like everyone is ok with the BIP as drafted then? 19:21 wumpus yes 19:21 gmaxwell I think so. 19:22 davec yes 19:22 sipa well, the only person with concerns was cfields, who doesn't seem to be here :) 19:22 gmaxwell sipa: he can raise concerns later too! 19:22 cfields dammit! 19:22 sipa cfields: too late! 19:22 gmaxwell ha 19:23 cfields did i really miss my third one of these in a row?
submitted by G1lius to Bitcoin [link] [comments]

Dalilcoin 0.1.6 released; Hard Fork Plans

Today Dalilcoin 0.1.6 is being released:
https://github.com/aliibrahim80/dalilcoin/releases/tag/v0.1.6
Yesterday 0.1.5 was released, but there was an off by one staking bug. Please use 0.1.6 instead.
The rest of this post is a copy and update of yesterday's deleted post.
The consensus code has been rewritten (since 0.1.4) in a way that helps nodes sync more easily. Another important change is that the communication with the ltc node can be done with remote ltc nodes (including ltc nodes run behind a tor hidden service).
Dalilcoin 0.1.6 will stop staking and will not accept blocks after May 1, 2019. The plan is to hard fork Dalilcoin on May 1, 2019, to make the following changes:
  1. Change the retarget algorithm.
  2. Add CLTV and CSV to scripts.
  3. Allow publication of theories and signatures.
The code with support for the hard fork should be released as Dalilcoin 0.2.0 in a few weeks (by April 1, 2019 April 21, 2019), so be sure to check for the update in late April.
Here are some more details about the planned hard fork.
The current retarget algorithm oscillates too much. It has not been uncommon for the difficulty to go high enough that there would be several days with no blocks. If seven days were to go by with no blocks staked, the chain would die (without a hard fork) and seven days without a block seems like it would eventually happen due to the oscillation with the current retarget algorithm (retarget_orig in block.ml). There is a new retarget algorithm (retarget_dampened in block.ml) which makes a much smaller change in the difficulty each block.
Dalilcoin scripts corresponded to Bitcoin scripts as they were at the time of the snapshot, before Bitcoin added CLTV and CSV. Adding CLTV and CSV would allow for atomic swaps between Dalilcoin and coins like Bitcoin and Litecoin. The ocaml code for this has not been written yet, but should be easy. Technically there are no "sequence numbers" or "nlocktime" values in Dalilcoin txs, so CLTV could be called "absolute locktime" and CSV "relative locktime," but calling them CLTV and CSV makes it easier to see the analogy with the corresponding bitcoin opcodes.
The support for the theories and signatures has been in the code from the beginning, but has been disabled due to a lack of testing. Someone pointed me to the qeditas-egal github repo that contains examples of theories and signatures. If the testing goes well, theories and signatures will no longer be disabled.
submitted by aliibrahim80 to dalilcoin [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
https://preview.redd.it/jxhm8fypd0t11.png?width=1341&format=png&auto=webp&s=007ddefb2d762a908d0644bee5aba637d668faa1
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.

https://preview.redd.it/essveiasd0t11.jpg?width=1289&format=pjpg&auto=webp&s=6871dbd14d4a9ea974ed2b46ec30ca46ad09fc36

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

https://preview.redd.it/k1mjw3itd0t11.jpg?width=1203&format=pjpg&auto=webp&s=2ab576fe1fc63a6fa55cc9efabfc0d4020931d9b


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.
https://preview.redd.it/d12qwarud0t11.jpg?width=722&format=pjpg&auto=webp&s=3ca17affcfe233e67397abe29ed1472b9bf06510
https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-completing-the-puzzle-and-closing-the-channel-1466178980/

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
https://preview.redd.it/0xnfa0daj3s11.png?width=990&format=png&auto=webp&s=eebff071633b7c8f93721d60bd68d2e43a2beccd
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.
https://preview.redd.it/7f17n7bfj3s11.jpg?width=1203&format=pjpg&auto=webp&s=8598cfddf9173d690e5ba194731ebe405cf0533b

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.

https://preview.redd.it/sfimnxfgj3s11.jpg?width=1203&format=pjpg&auto=webp&s=c4ff868439076097a35f6b9848762ca05944b585
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).)
https://preview.redd.it/2axendhhj3s11.jpg?width=1203&format=pjpg&auto=webp&s=d62e7ffb675781880402c3edd665cf5741acd4a1

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.

https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-creating-the-network-1465326903/
#InziderX #Exchange #ico https://inziderx.io/
submitted by InziderX to u/InziderX [link] [comments]

Fill-or-kill transaction | jl2012 at xbt.hk | Sep 17 2015

jl2012 at xbt.hk on Sep 17 2015:
Fill-or-kill tx is not a new idea and is discussed in the Scaling
Bitcoin workshop. In Satoshi's implementation of nLockTime, a huge range
of timestamp (from 1970 to 2009) is wasted. By exploiting this unused
range and with compromise in the time resolution, a fill-or-kill system
could be built with a softfork.
Two new parameters, nLockTime2 and nKillTime are defined:
nLockTime2 (Range: 0-1,853,010)
0: Tx could be confirmed at or after block 420,000
1: Tx could be confirmed at or after block 420,004
.
.
719,999: Tx could be confirmed at or after block 3,299,996 (about 55
years from now)
720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
(2016-09-22)
720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
(2016-09-22)
.
.
1,853,010 (max): Tx could be confirmed if the median time-past >=
3,794,966,528 (2090-04-04)
nKillTime (Range: 0-2047)
if nLockTime2 < 720,000, the tx could be confirmed at or before block
(nLockTime2 + nKillTime * 4)
if nLockTime2 >= 720,000, the tx could be confirmed if the median
time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
Setting a bit flag in tx nVersion will activate the new rules.
The resolution is 4 blocks or 2048s (34m)
The maximum confirmation window is 8188 blocks (56.9 days) or
16,769,024s (48.5 days)
For example:
With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
between block 420,080 and 420,480
With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
only between median time-past of 1,495,042,048 and 1,497,090,048
Why is this a softfork?
Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2
  • 2048
For height based nLockTime2 (<= 719,999)
For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which
means the tx could be confirmed after 1970-01-01 with the original lock
time rule. As the new rule does not allow confirmation until block
420,000, it's clearly a softfork.
It is not difficult to see that the growth of nLockTime will never catch
up nLockTime2.
At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
which means 2016-09-22. However, the new rule will not allow
confirmation until block 3,299,996 which is decades to go
For time based nLockTime2 (> 720,000)
For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
which means the tx could be confirmed after median time-past
1,474,560,000 (assuming BIP113). However, the new rule will not allow
confirmation until 1,474,562,048, therefore a soft fork.
For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime =
1,974,562,047, which could be confirmed at 1,474,562,047. Again, the new
rule will not allow confirmation until 1,474,562,048. The 1 second
difference makes it a soft fork.
Actually, for every nLockTime2 value >= 720,000, the lock time with the
new rule must be 1-2048 seconds later than the original rule.
For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
4,294,966,527, which is the highest possible value with the 32-bit
nLockTime
User's perspective:
A user wants his tx either filled or killed in about 3 hours. He will
set a time-based nLockTime2 according to the current median time-past,
and set nKillTime = 5
A user wants his tx get confirmed in the block 630000, the first block
with reward below 10BTC. He is willing to pay high fee but don't want it
gets into another block. He will set nLockTime2 = 210,000 and nKillTime
= 0
OP_CLTV
Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
However, height-based OP_CLTV is not compatible with nLockTime2. To
spend a height-based OP_CLTV output, user must use the original
nLockTime.
We may need a new OP_CLTV2 which could verify both nLockTime and
nLockTime2
55 years after?
The height-based nLockTime2 will overflow in 55 years. It is very likely
a hard fork will happen to implement a better fill-or-kill system. If
not, we could reboot everything with another tx nVersion for another 55
years.
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011042.html
submitted by dev_list_bot to bitcoin_devlist [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:
np.reddit.com/ BitcoinMarkets/comments/7n5dwi
The original post's content was as follows:
Hola,
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
{Script1}: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
{Script2}: OP_SHA256 OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
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]

The True Dark Web - Online Bitcoin Gambling Addiction

The true “Dark Web” - Online Bitcoin Gambling Addiction
The cryptocurrency craze has been nothing short of a phenom, seeing billions and billions of dollars created out of thin air, seemingly what felt like overnight has been nothing short of a marvel to watch transpire.
The headlines, blogs, forums all speak of new found riches, what seem like buried treasures found yet, as new high’s are made for Bitcoin and other currencies, new lows of self worth are discovered daily by the countless gambling addictions that have popped up with the rise and adoption of cryptocurrencies like Bitcoin.
Available for iPod, iPhone, iPad, Mac, Windows, Linux, Android, Samsung, etc, 24/7, 365 days a week at lighting fast speeds. Deposit bonus’, VIP raffles for “free bitcoins”, holiday bonus’, VIP trips, personal hosts - yup, it’s all in there and at times - it is magnificent.
However, that is the single most toxic thing about gambling addiction - if even for the briefest of moments, that time it is “magnificent’ takes a grasp so powerful, so determined and so unlikely to be found again until the hooks are set, play play play, reward, play play play, reward are deeply embedded into our cognitive behavior and we have conditioned ourselves to only derive happiness from the briefest of moments that the brain thinks are “magnificent”
I am one of those soul’s who lost millions of dollars, friends, close relationships, values, moral compass and most importantly - my ability to derive self worth, self love and empathy until I was almost too far down the rabbit hole to turn back.
Some statistics suggest nearly 80% of all Bitcoin’s in circulation are used for online gambling. They are the ideal currency for such gaming activities - anonymous, instant and can be broken down into payments both big and small.
I am writing this not to shun any operators nor the industry, I am writing this to let the thousands of people across the world who are in pain that no words can truly describe from the ruin and shame that go hand in hand with gambling addiction see that they are not alone.
The cycle of destruction that comes with gambling addiction is on par with the greatest of natural disasters. I have had the fortune of experiencing almost every type of addiction one could experience, nothing even comes close to the grip, power and intensity of online gambling addiction.
Now, I can understand those reading have little room for sympathy, after all, gambling addiction is and has been portrayed as one of the most shameful addictions one can develop that are stigmatized by both the media and in real life.
The goal of this is to not earn anyone’s sympathy, I do not feel like a victim - these are choices I made however, the US Surgeon General (whom I have the greatest respect for going against the grain) has coined (no pun intended) any addiction as a “Cognitive Brain Disease”. This means that the chemical makeup of one’s brain is altered and is not a choice. The brain gets rewired to release the chemical dopamine only when a jackpot or “near jackpot” is obtained. Perhaps a brief explanation of the “gamblers high” will help put things into context.
If I am playing cards, and let’s say I had a good run and am up $1 million. Each win experiences diminishing marginal returns, this means that the pleasure or “high” I receive from each win decreases with each bet. In fact, even if I won another $1 million jackpot while up $1 million, it will offer significantly less of a “high” than if i were to be down $1 million.
The gamblers high, as little sense as it may make to some, is not experienced when someone is winning money. The gamblers high truly kicks in when someone is down big and comes out of nowhere with a big win.
The speed and velocity of such a swing, down $1 million to up $1 million (we call that a $2m swing) is the true “high” and the rush of that high is so great we chase it leaving our lives, pride and self worth behind. The force of that rush is so intense, gamblers will intentionally bet irrationally to lose their winnings simply so they can experience that rush. Like I said, it’s the most vicious addiction I have experienced
New technologies that show the game is “Provably Fair” allow players to instantly verify the “die roll” if you will to show that the outcome was already decided by the software before the person decided how much they would bet or what decisions they would make during the game. (Ex: the makeup of the shoe of cards in a game of blackjack)
I commend the industry for providing such transparency and unlike fiat currency gaming sites, offer the “fairest” chance of any gambler to “take down the house” however, it takes a bit more understanding of the psyche behind gambling addiction to understand the predatory nature of such sites and the bells and whistles used to retain those addicts over long periods of time to boost their CLTV (Customer Lifetime Value)
Technology has led to great advancements and power, with that comes responsibility. I am very much a believer in capitalism and feel very strongly a business should have the ability to take advantage of inefficiencies in a market to their advantage. I would simply ask the operators of such site to do this with caution, offer a sense of humanity and empathy and help educate players around loss limits, self exclusion and even offer help if a player is playing on “edge”.
While taking advantage of a market opportunity is one thing, taking advantage of someone’s emotional and financial vulnerability goes against every facet of our own humanity.
For those who are struggling with online gambling addiction or any addiction to that matter, I know all too well just how dark times can get, I feel your pain and understand that hope is a hard thing to come by when such a spiral takes hold. Turn to those who you love for help, be brutally honest in whatever you are experiencing no matter how much shame you think it may bring.
Shame is a funny thing, everyone has it, nobody likes to talk about it and the less we talk about it the more we have. The sense of relief and hope that offers almost instant gratification when you are honest with yourself and your families about your addiction is the biggest catalyst to overcoming the darkest of days.
Find yourself, no matter how hard or dark it may be, the rewards are greater than any jackpot can offer
submitted by peterpan212 to GamblingAddiction [link] [comments]

Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) | Matt Corallo | Mar 16 2015

Matt Corallo on Mar 16 2015:
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the height of the output being spent and then has
identical semantics to CLTV.
A slightly different API (and different name) was described by maaku at
http://www.reddit.com/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
which does a better job of saving softfork-available opcode space.
There are two major drawbacks to adding such an operation, however.
1) More transaction information is exposed inside the script (prior to
CLTV we only had the sigchecking operation exposed, with a CLTV and
RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
2) Bitcoin Core's mempool invariant of "all transactions in the mempool
could be thrown into one overside block and aside from block size, it
would be valid" becomes harder to enforce. Currently, during reorgs,
coinbase spends need checked (specifically, anything spending THE
coinbase 100 blocks ago needs checked) and locktime transactions need
checked. With such a new operation, any script which used this new
opcode during its execution would need to be re-evaluated during reorgs.
I think both of these requirements are reasonable and not particularly
cumbersome, and the value of such an operation is quite nice for some
protocols (including settings setting up a contest interval in a
sidechain data validation operation).
Thoughts?
Matt
On 10/01/14 13:08, Peter Todd wrote:
I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
The reference implementation, including a full-set of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify

BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd <pete at petertodd.org>
Status: Draft
Type: Standards Track
Created: 2014-10-01

==Abstract==
This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable until
some point in the future.
==Summary==
CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
compares the top item on the stack to the nLockTime field of the transaction
containing the scriptSig. If that top stack item is greater than the transation
nLockTime the script fails immediately, otherwise script evaluation continues
as though a NOP was executed.
The nLockTime field in a transaction prevents the transaction from being mined
until either a certain block height, or block time, has been reached. By
comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
indirectly verify that the desired block height or block time has been reached;
until that block height or block time has been reached the transaction output
remains unspendable.
==Motivation==
The nLockTime field in transactions makes it possible to prove that a
transaction output can be spent in the future: a valid signature for a
transaction with the desired nLockTime can be constructed, proving that it is
possible to spend the output with that signature when the nLockTime is reached.
An example where this technique is used is in micro-payment channels, where the
nLockTime field proves that should the receiver vanish the sender is guaranteed
to get all their escrowed funds back when the nLockTime is reached.
However the nLockTime field is insufficient if you wish to prove that
transaction output ''can-not'' be spent until some time in the future, as there
is no way to prove that the secret keys corresponding to the pubkeys controling
the funds have not been used to create a valid signature.
===Escrow===
If Alice and Bob jointly operate a business they may want to
ensure that all funds are kept in 2-of-2 multisig transaction outputs that
require the co-operation of both parties to spend. However, they recognise that
in exceptional circumstances such as either party getting "hit by a bus" they
need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
to act as a third-party.
With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.
However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:
IF  CHECKLOCKTIMEVERIFY DROP  CHECKSIGVERIFY 1 ELSE 2 ENDIF   2 CHECKMULTISIG 
At any time the funds can be spent with the following scriptSig:
  0 
After 3 months have passed Lenny and one of either Alice or Bob can spend the
funds with the following scriptSig:
  1 
===Non-interactive time-locked refunds===
There exist a number of protocols where a transaction output is created that
the co-operation of both parties to spend the output. To ensure the failure of
one party does not result in the funds becoming lost refund transactions are
setup in advance using nLockTime. These refund transactions need to be created
interactively, and additionaly, are currently vulnerable to transaction
mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
interactive setup with a non-interactive setup, and additionally, making
transaction mutability a non-issue.
====Two-factor wallets====
Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
such that one keypair is controlled by the user, and the other keypair is
controlled by the service. To spend funds the user uses locally installed
wallet software that generates one of the required signatures, and then uses a
2nd-factor authentication method to authorize the service to create the second
SIGHASH_NONE signature that is locked until some time in the future and sends
the user that signature for storage. If the user needs to spend their funds and
the service is not available, they wait until the nLockTime expires.
The problem is there exist numerous occasions the user will not have a valid
signature for some or all of their transaction outputs. With
CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand
scriptPubKeys of the following form are used instead:
IF  CHECKSIGVERIFY ELSE  CHECKLOCKTIMEVERIFY DROP ENDIF  CHECKSIG 
Now the user is always able to spend their funds without the co-operation of
the service by waiting for the expiry time to be reached.
====Micropayment Channels====
Jeremy Spilman style micropayment channels first setup a deposit controlled by
2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends
the output of tx1 to payor and payee. Prior to publishing tx1 a refund
transaction is created, tx3, to ensure that should the payee vanish the payor
can get their deposit back. The process by which the refund transaction is
created is currently vulnerable to transaction mutability attacks, and
additionally, requires the payor to store the refund. Using the same
scriptPubKey from as in the Two-factor wallets example solves both these issues.
===Trustless Payments for Publishing Data===
The PayPub protocol makes it possible to pay for information in a trustless way
by first proving that an encrypted file contains the desired data, and secondly
crafting scriptPubKeys used for payment such that spending them reveals the
encryption keys to the data. However the existing implementation has a
significant flaw: the publisher can delay the release of the keys indefinitely.
This problem can be solved interactively with the refund transaction technique;
with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using
scriptPubKeys of the following form:
IF HASH160  EQUALVERIFY  CHECKSIG ELSE  CHECKLOCKTIMEVERIFY DROP  CHECKSIG ENDIF 
The buyer of the data is now making a secure offer with an expiry time. If the
publisher fails to accept the offer before the expiry time is reached the buyer
can cancel the offer by spending the output.
===Proving sacrifice to miners' fees===
Proving the sacrifice of some limited resource is a common technique in a
variety of cryptographic protocols. Proving sacrifices of coins to mining fees
has been proposed as a ''universal public good'' to which the sacrifice could
be directed, rather than simply destroying the coins. However doing so is
non-trivial, and even the best existing technqiue - announce-commit sacrifices
create outputs that are provably spendable by anyone (thus to mining fees
assuming miners behave optimally and rationally) but only at a time
sufficiently far into the future that large miners profitably can't sell the
sacrifices at a discount.
===Replacing the nLockTime field entirely===
As an aside, note how if the SignatureHash() algorithm could optionally cover
part of the scriptSig the signature could require that the scriptSig contain
CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed.
(the CODESEPARATOR opcode came very close to making this possible in v0.1 of
Bitcoin) This per-signature capability could replace the per-transaction
nLockTime field entirely as a valid signature would now be the proof that a
transaction output ''can'' be spent.
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP2: { // CHECKLOCKTIMEVERIFY // // (nLockTime -- nLockTime ) if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) break; // not enabled; treat as a NOP if (stack.size() < 1) return false; // Note that elsewhere numeric opcodes are limited to // operands in the range -2**31+1 to 2**31-1, however it is // legal for opcodes to produce results exceeding that // range. This limitation is implemented by CScriptNum's // default 4-byte limit. // // If we kept to that limit we'd have a year 2038 problem, // even though the nLockTime field in transactions // themselves is uint32 which only becomes meaningless // after the year 2106. // // Thus as a special case we tell CScriptNum to accept up // to 5-byte bignums, which are good until 2**32-1, the // same limit as the nLockTime field itself. const CScriptNum nLockTime(stacktop(-1), 5); // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return false; // There are two times of nLockTime: lock-by-blockheight // and lock-by-blocktime, distinguished by whether // nLockTime < LOCKTIME_THRESHOLD. // // We want to compare apples to apples, so fail the script // unless the type of nLockTime being tested is the same as // the nLockTime in the transaction. if (!( (txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) || (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) )) return false; // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nLockTime > (int64_t)txTo.nLockTime) return false; // Finally the nLockTime feature can be disabled and thus // CHECKLOCKTIMEVERIFY bypassed if every txin has been // finalized by setting nSequence to maxint. The // transaction would be allowed into the blockchain, making // the opcode ineffective. // // Testing if this vin is not final is sufficient to // prevent this condition. Alternatively we could test all // inputs, but testing just this input minimizes the data // required to prove correct CHECKLOCKTIMEVERIFY execution. if (txTo.vin[nIn].IsFinal()) return false; break; } 
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
==Upgrade and Testing Plan==
TBD
==Credits==
Thanks goes to Gregory Maxwell for suggesting that the argument be compared
against the per-transaction nLockTime, rather than the current block height and
time.
==References==
PayPub - https://github.com/unsystem/paypub
Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
==Copyright==
This document is placed in the public domain.
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-March/007714.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

How To Calculate Customer Lifetime Value For eCommerce Profit Core Value Challenge - Zappos CLT How Digital Nomads Live Like Royalty for CHEAP Paxos Moves to Ontology, E Trade Looks to Trade BTC and ETH CLTV Ep 001 What Is Lifetime Value? - YouTube

Approximately 20% of all bitcoin transactions set a nLockTime value different from zero as of early-2019. CheckLockTimeVerify. In late 2015, the BIP65 soft fork 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 ... CLTV is an op code in the Bitcoin scripting language that allows you to lock a UTXO (Unspent Transaction Output) by time. i.e. a coin cannot be spent until a certain time or blockchain height has been past. In this guide, we will have a function that creates a script that locks a UTXO for a predetermined amount of time using the CLTV op code as well as separately learn how to sign these types ... A transaction output encumbered with a CLTV opcode cannot be spent unless the spending transaction has an nLockTime that is greater than or equal to the CLTV parameter. In your example, you are correct that T cannot be mined until time 400. However, the CLTV value applies to a single transaction output that is being spent by T. The two values ... A javascript Bitcoin library for node.js and browsers. - bitcoinjs/bitcoinjs-lib We invite you to the world of CoinLoan value, by giving a real comprehension of its prospect and worthiness! ... Bitcoin (7.70%) Ethereum (10.58%) Ripple (6.75%) Tether (6.59%) ChainLink (23.36%) Bitcoin Cash (6.32%) Polkadot (22.59%) Binance Coin (27.51%) Bitcoin SV (5.84%) Litecoin (7.43%) EOS (7.66%) Cardano (17.85%) Tron (-0.87%) Tezos (11.93%) Stellar (9.97%) Crypto.com Chain (2.31% ...

[index] [42141] [21519] [20398] [1766] [22054] [12981] [50773] [25844] [26019] [30607]

How To Calculate Customer Lifetime Value For eCommerce Profit

Customer lifetime value is the single most important metric for understanding your customers. 11 sep 2014 also, just 42. An introduction to lifetime value mo... Bitcoin Lounge using TRDR signals Long Signals are IN it' FRIDAY Joe Saz 265 watching Live now PINK FLOYD: Delicate Sound Of Thunder (expanded new edition) - Duration: 1:54:26. Starting a new series Called Coin Logic TV where we talk about nothing but crypto! So for the first episode, we are talking about Paxos Standard stable coin moving to the Ontology blockchain and ... Join the Talent Tribe for Exclusive Trainings, Interviews, Masterclass, and get your questions answered directly from the Talented Mr. Salas in our Private F... How to quickly & easily identify your Customer Lifetime Value (CLTV) to drive more eCommerce PROFIT If you aren’t leveraging your data to discover your True Customer Value - you’re leaving ...

#