Bitcore Js Multisig - Stellest

Technical: Upcoming Improvements to Lightning Network

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

"eltoo" Decker-Russell-Osuntokun

Yeah the exciting new Lightning Network channel update protocol!




Multipart payments / AMP

Splitting up large payments into smaller parts!




Payment points / scalars

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




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



Stuckless payments

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



Non-custodial escrow over Lightning

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



Payment decorrelation

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



submitted by almkglor to Bitcoin [link] [comments]

⚡ Lightning Network Megathread ⚡

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

⚡What is the Lightning Network? ⚡


Image Explanations:

Specifications / White Papers


Lightning Network Experts on Reddit

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

Lightning Network Experts on Twitter

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

Medium Posts

Learning Resources


Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

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

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

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


Lightning Network Visualizers/Explorers



Payment Processors

  • BTCPay - Next stable version will include Lightning Network




Slack Channel

Discord Channel


⚡ Lightning FAQs ⚡

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

Unanswered Questions

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

Special Thanks and Notes

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

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
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:
" 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
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
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.
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.
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
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]

Does "versionbits" fully address previous concerns about hard forks versus soft forks?

This week there has been an interesting new feature announced called "versionbits" (evidently due to an insight from Luke-Jr) which proposes to make soft-forking easier and safer. (In particular, it is claimed that it could be used to roll out Segregated Witness with minimal impact on the existing user base.)
A few months ago there was an interesting post from Mike Hearn on where he argued that even when a soft fork is possible, a hard fork may often be preferable - since with a hard fork, nobody is left "in the dark" about the new semantics that have been added.
My question is: Does VersionBits address the concerns raised in Mike's earlier post?
On consensus and forks - What is the difference between a hard and soft fork? - by Mike Hearn
In a soft fork, a protocol change is carefully constructed to essentially trick old nodes into believing that something is valid when it actually might not be.
Here’s an analogy. Imagine a big company with a team of auditors, and a team of traders. The traders want to make a new type of trade that the firm currently disallows: the auditors check what the traders are doing to enforce company policies. Changing the policies can be slow work. But one day, a trader has a brainwave. “Hey guys”, he says, “I’ve had an idea. I’m going to submit some trades for derivatives, but I’m going to write it down on the paperwork as buying land. When you see that, just mentally replace land with derivatives, and carry on as normal. The auditors won’t find out!”
The auditors are people and services that are running Bitcoin full nodes. The traders are people who want to change the rules. Whether their rule change is a good idea or not isn’t relevant here: what matters is how they’re doing it. The auditors are now cross checking every transaction, but their calculations can arrive at the wrong answer, because they don’t understand the true nature of the transactions they’re verifying.
Segregated Witness and its Impact on Scalability - by Pieter Wuille
Luke-Jr discovered that it's possible to do this as a soft-fork.
In a soft-fork, we can add a new rule that restricts what's valid.
We could say every script could begin with a version byte. The reason for doing so is making it easier to do soft-forks.
So this is the reason why previous soft-forks in particular, like CSV and CLTV, bip112 and bip65, the only thing they do is redefine that OP_NULL. This is sad. There are way, way more nice improvements to Script that we could imagine. By adding a version byte with semantics like, whenever you see a version byte that you don't know, consider it ANYONECANSPEND. This allows us to make any change at all in the Script language, like introducing new signature types like Schnorr signatures, which increase scalability by reducing the size of multisig transactions dramatically, or other proposals like merklized abstract syntax trees which is a research topic mostly. But there really are a lot of ideas for potential improvement to Script that we cannot do right now. This would enable it for free by just adding one more byte to all Script scripts.
Capacity increases for the Bitcoin system - by Gregory Maxwell
Versionbits (BIP9) is approaching maturity and will allow the Bitcoin network to have multiple in-flight soft-forks. Up until now we’ve had to completely serialize soft-fork work, and also had no real way to handle a soft-fork that was merged in core but rejected by the network. All that is solved in BIP9, which should allow us to pick up the pace of improvements in the network. It looks like versionbits will be ready for use in the next soft-fork performed on the network.
I'm not trying to create a face-off among devs here - I'm just curious if versionbits addresses the stuff that Mike was talking about.
Thanks for any feedback from pwuille, nullc, mike_hearn, luke-jr, and others who may be knowledgeable about this.
submitted by ydtm to btc [link] [comments]

Making a 2MB blocksize hardfork safer | Anthony Towns | Feb 07 2016

Anthony Towns on Feb 07 2016:
Hello world,
The core roadmap calls for having patches at the ready for
implementing hardforking blocksize increases [0]. However, at least
to my understanding, is that the deployment of segregated witness has
a significant impact on what a hardforking blocksize increase should
look like -- with segwit, the increase in the blocksize may have to
be traded off against decreasing the witness discount; without segwit,
alternative changes might need to be made to provide some of the other
benefits of segwit without segwit (in particular, additional limits to
prevent hashing massive amounts of data when checking sigs or to reduce
worst-case UTXO growth).
I don't personally have any real concerns that segregated witness will be
too complicated to implement and release by April, and given how quickly
CLTV rolled out, my guess is it will be usable prior to the block reward
halving. I'm also not terribly worried about fees rising significantly,
or that there will be a "fee event" [1] or "market disruption" -- fees
don't seem to be rising even with the spam attacks we've seen, and all
the problems with transactions not confirming that I've been able to see
so far seem to be due either to people trying to do free transactions,
fees not being calculated based on transaction size, or not checking
for dust outputs, all of which are things that can be dealt with by
individual wallets. [2]
But those are guesses and opinions, and I think it makes sense to have
a backup plan if everything goes horribly wrong -- someone discovers
a problem with segwit that requires major rearchitecturing to fix and
won't happen until 2017, eg.
To me, Gavin's BIP [3] and the Bitcoin Classic approach don't seem like
a good backup plan; but I don't see why they couldn't be made into a
good plan. In particular, if segwit turns out too hard to actually deploy
safely, I think Gavin's patchset -- an increase to ~2MB, coupled with
accurate counting and limiting of sighash bytes, and pretty much nothing
else -- is about the right set of technical things to do as a backup plan.
So the following are my suggestions for making Gavin's BIP workable
procedurally/politically as a backup plan. But that said, I don't know
if this is even remotely acceptable politically; I'm just following
bitcoin as a hobby and I don't have any backchannel contacts in mining
or bitcoin startups or anything.
  1. Level of supermajority

First, it was reported that the Chinese miners came up with a 2MB
blocksize plan in late January [4], with the following summarised plan:
] If:
] 1: Blocks are full
] 2: Core proposal is <2MB
] 3: Classic proposal have not gained consensus
] Then:
] Under the 90% hash power condition, switch from a 1MB limit to a
] 2MB limit to deal with the block size problem.
The summary also expresses concerns about segwit deployment; that it
makes significant changes, and that any issues with reliability may have
major impact. Those seem like valid concerns to me; though if they are
not addressed directly, then I expect miners will simply not enable the
segwit soft-fork until they are.
I think the only change to make this match Gavin's code for Bitcoin
Classic then is to require 90% hashpower support rather than 75%. I think
that can be easily done by a soft-forking change where miners reject any
block with a Classic vote (ie a version of 0x10000000) if the block height
is cleanly divisible by 6 [5]. As this is a soft-forking change, and one
that's only relevant until either Classic activates or the 2MB hardfork
attempt is permanently aborted on 2018-01-01, it seems like it could
easily be deployed prior to either segwit or Classic voting beginning.
  1. Activation Time

The activation time for Gavin's BIP is very short -- 1000 blocks for
voting could be as short as 6 days, followed by 28 days grace period.
I haven't seen any indication that there is an immediate crisis, or
that there will be one in the next few months; and the fact that the
BIP does not expire for two years seems to indicate it's not a short
term issue. Allowing three to six months before attempting to activate
the hardfork seems like it would still provide plenty of opportunity to
address the issue quickly, and would also mean there was time to see if
the segwit rollout worked as planned.
That also could be enforced by a soft-fork: eg having a rule that until
the median time past is 2015-05-27, any block voting for the 2MB hardfork
will be rejected, would ensure the hard fork was not activated until
1st of July. A slightly more complicated rule, eg only rejecting the
blocks if the last three decimal digits of its height was 500 or greater,
would allow support to be measured in the leadup to possible activation,
without any risk of activation happening early.
  1. Upgrade encouragement

I think there's three ways the 2MB hardfork could go: (a) not ever being
activated at all, similar to XT; (b) being activated with effective
consensus, where everyone switches to the hard-fork, whether happily
or not; or (c) being activated, but with the old chain being actively
mined and used on an ongoing, long-term basis.
If the 2MB blocksize hardfork is deployed as a fallback after segwit
deployment has failed, or determined to be much more complicated than
currently believed, then it seems like (c) would be a pretty undesirable
The only way I can see of avoiding/discouraging (c) is to have the new
hardfork be merge-minable with the existing chain, and having every
block in the new chain also commit to a merged-mined empty block on the
old chain, so that as long as the new chain has more hashpower than the
old chain, the longest valid old chain will have no outgoing payments
after the hardfork activates. (That requirement could probably be safely
dropped after some number of blocks, perhaps 25000 or 6 months?)
Alternatively, if the old blockchain has 10% or less hashpower remaining
(due to the 90% activation above), then the new chain has 9x the
hashpower. Perhaps a rule such that every 8th block in the hard-forked
chain must include an OP_RETURN in the coinbase that provides a valid,
empty block for the old chain. With a 90%/10% split, this would ensure
that the empty chain had more work than any other attempt at extending
it. However at the next difficulty change for the old chain (decreasing
by a factor of 4, presumably), I think they'd have to be mined every
second block rather than every 8th, and by the second difficulty change,
would need to be mined every block; otherwise I think 10% of hashpower
could catch up in chain-work. (Again, the requirement could probably be
dropped entirely after 6 months, or similar)
I believe this latter approach could be implemented as a soft-fork on
top of Gavin's BIP / Bitcoin Classic, provided activation was at 90% [7].
In this scenario, it would be possible for miners to simply sell empty
blocks on the old chain once they find them, so finding an empty block
for the old chain could plausibly be independent of finding the new
block for the new chain.

I think those three changes, which all should be implementable as
soft-forks compatible with Gavin's current code (the first two only
relevant prior to activation; the last only relevant after activation),
would mitigate what I see as the biggest risks of classic:
And I think that would make this BIP (for me) a workable backup plan in
the event segwit doesn't work as planned. And for a multi-billion dollar
service, backup plans seem like a worthwhile thing to have, even if it's
highly unlikely it will actually get used.
However, these are all ideas where the benefits are basically "political"
rather than "technical", and I have no idea if the above actually makes
sense... And I guess trying to establish that is probably off-topic for
bitcoin-dev anyway? Anyway, as a consequence I've no idea if a write up
as a BIP and/or patches to implement any/all of the above as soft-forks
for classic/core that could be activated would be interesting for anyone,
and beyond posting about the ideas here, no idea how to find out. It
seemed like an interesting thought experiment to me, anyway. Apologies
in advance if it turns out I'm alone in that :)
[0] "Finally--at some point the capacity increases from the above may not
be enough. Delivery on [various improvements], and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, ..." via 
[2] I do think that, without segwit or a blocksize increase, there will be
a discontinuity for venture funded bitcoin companies, becau...[message truncated here by reddit bot]... 
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

#bitcoin-dev Weekly Development Meeting Minutes 2015-10-08 | Daniel Stadulis | Oct 09 2015

Daniel Stadulis on Oct 09 2015:
More readable Google Doc version with html links here:
Meeting Title:

bitcoin-dev Weekly Development Meeting

Meeting Date:
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
IRC Chat Logs:
Topics to be discussed:
  1. Mempool limiting
  2. Partial transaction malleability fix: Low-S change (releases 0.10.3, 0.11.1
  1. CHECKLOCKTIMEVERIFY (CLTV) backport reviews
  3. Creation of [bitcoin-discuss] mailing list planning
2015-10-08 Meeting Conclusions:
Ecosystem Warnings & Alerts:
There is a Bitcoin ecosystem threat with the potential to cause millions of
dollars in losses that needs higher visibility. It's not a Bitcoin Core /
Bitcoin network issue but most Javascript-based Bitcoin software is
affected. The issue, documented here, is about common, critical,
Javascript code that is broken and may cause the generation of incorrect
pubkeys (among other issues). If Javascript is part of your implementation,
you should read the referenced pull request.
Action items
Responsible Parties
ETA/Due Date
Review/test code for Pull Request #6722 "Limit mempool by throwing away the
cheapest txn and setting min relay fee to it".
Provide ACK’s/support for low limits on PR #6771 "Policy: Lower default
limits for tx chains".
Urgent code review and ACKs of CLTV backports PR:

6706 “CLTV IsSuperMajority() soft-fork, rebased for v0.10.2”

6707 “CLTV IsSuperMajority() soft-fork, rebased for v0.11.0”

Contact miners about PR #6769 "Test LowS in standardness, removes nuisance
malleability vector" and turning on the long-existing anti-malleability
standardness rules in Bitcoin Core
Bluematt & Gmaxwell
Clarification from maaku regarding nSequence for BIP68
Continue review and ACKs of PR

6312 “BIP-68: Mempool-only sequence number constraint verification”

6564 “BIP-112: Mempool-only CHECKSEQUENCEVERIFY”

6566 “BIP-113: Mempool-only median time-past as endpoint for lock-time

Mailing Lists: [bitcoin-discuss] creation, moderators assignment of discuss
and dev list, simple website for mailing list policy.
Discussion meeting scheduled for: 2015-10-12 19:00-20:00 UTC
Meetingbot Minutes
IRC Log:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Boursorama - YouTube TEACH TECH  Create a short URL How To Calculate Customer Lifetime Value For eCommerce Profit Workers' Compensation Premiums PVC Pipe Bending - YouTube

In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking. Then, starting from block 31001 ... (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter ... Bitcoin / Crypto Calculator & Converter. Use the Bitcoin calculator below to convert real-time price of a single BTC to United States Dollar (USD) and many other popular fiats like Japanese Yen (JPY), Chinese Yuan (CNY), Euro, British Pound (GBP) and many more. This little useful calculator is not limited to Bitcoin, you can also see the real-time prices for popular cryptocurrencies like ... CoinLoan (CLT) Naar Amerikaanse dollar (USD) prijsgeschiedenis grafiek: CoinLoan Naar Amerikaanse dollar tabel sinds de start van de handel. CoinLoan waarde geschiedenis in Amerikaanse dollar sinds 2015. While a similar feature is available through simply setting a transaction’s locktime in the future, CLTV can be combined with other script instructions, like multisig or arithmetic operators, to create complex contracts. Multisig is a technique that allows several public keys to sign for… The state of Bitcoin multisig Nov 30, 2015 In this article, I’ll look at the history of multisig ... Want to know How much Bitcoin is 1 CoinLoan? 1 CoinLoan to BTC Calculator: Exchange Rate Price. Here you can check exchanges where you can trade CoinLoan to BTC pair. en; ru; de; zh Currencies; Exchanges; Trading pairs; Blog; Close. $348,36B. Total marketcap. $759,85B. Total volume. 57.00%. BTC dominance. en; ru; de; zh; coin data flow Crypto Charts. Currencies; Exchanges; Trading pairs; Blog ...

[index] [5287] [44076] [11357] [51064] [44564] [30065] [38259] [18934] [36544] [6667]

Boursorama - YouTube

In unserem Kanal stellen wir euch Planungshilfen, Konfiguratoren und Visualisierungstools vor, die euch beim Einrichten und Planen eurer Wohnung helfen und i... 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... Workers’ Compensation insurance is one of the biggest expenses for businesses, particularly in industries with huge payrolls and high risks such as manufacturing. As a result, manufacturers are ... Learn how to make your long URL into a short URL. Inspired by with our own twist. 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 ...