Getting started with Bitcoin: Info, Price, Calculator and ...
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. Anyway.....
Yeah the exciting new Lightning Network channel update protocol!
Solves "toxic waste" problem. In the current Poon-Dryja update protocol, old state ("waste") is dangerous ("toxic") because if your old state is acquired by your most hated enemy, they can use that old state to publish a stale unilateral close transaction, which your counterparty must treat as a theft attempt and punish you, causing you to lose funds. With Decker-Russell-Osuntokun old state is not revoked, but is instead gainsaid by later state: instead of actively punishing old state, it simply replaces the old state with a later state.
Allows multiple participants in the update protocol. This can be used as the update protocol for a channel factory with 3 or more participants, for example (channels are not practical for multiple participants since the loss of any one participants makes the channel completely unuseable; it's more sensible to have a multiple-participant factory that splits up into 2-participant channels). Poon-Dryja only supports two participants. Another update protocol, Decker-Wattenhofer, also supports multiple participants, but requires much larger locktimes in case of a unilateral close (measurable in weeks, whereas Poon-Dryja and Decker-Russell-Osuntokun can be measured in hours or days).
It uses nLockTime in a very clever way.
No, it does not solve the "watchtower needed" problem. Decker-Russell-Osuntokun still requires watchtowers if you're planning to be offline for a long time.
What might be confused is that it was initially thought that watchtowers under Decker-Russell-Osuntokun could be made more efficient by having the channel participant update a single "slot" in the watchtower, rather than having to consume one "slot" per update in Poon-Dryja. However, the existence of the "poisoned blob" attack by ZmnSCPxj means that having a replaceable "slot" is risky if the other participant of the channel can spoof you. And the safest way to prevent spoofing somebody is to identify that somebody --- but now that means the watchtower can surveill the activities of somebody it has identified, losing privacy.
Requires base layer change --- SIGHASH_NOINPUT / SIGHASH_ANYPREVOUT. This is still being worked out and may potentially not reach Bitcoin anytime soon.
Determining costs of routes is somewhat harder, and may complicate routefinding algorithms. In particular: every channel today has a "CLTV Delta", a number of blocks by which the total maximum delay of the payment is increased. This maximum delay is the maximum amount of time by which an outgoing payment can be locked, and needs to be reduced for UX purposes. Decker-Russell-Osuntokun will also add a "CSV minimum", a number of blocks, which must be smaller than the delay of an HTLC going through the channel. Current routefinding algos are good at minimizing a summed-up cost (like the "CLTV Delta") so the "CSV minimum" may require discovering / developing new routefinding algos.
Due to the "CSV minimum" above, existing nodes that don't understand Decker-Russell-Osuntokun cannot reliably route over Decker-Russell-Osuntokun channels, as they might not impose this minimum properly.
Multipart payments / AMP
Splitting up large payments into smaller parts!
There are at least three variants of multipart payments: Original, Base, and High.
Original is the original AMP proposed by Lightning Labs. It sacrifices proof-of-payment in order to allow each path to have a different payment hash. This is done by having the payer use a derivation scheme to generate each part's payment preimage from a seed, then having the split the seed (using secret sharing) to each part. The receiver can only reconstruct the seed if all parts reach it.
Base simply uses the same payment hash for all routes. This retains proof-of-payment (i.e. an invoice is undeniably signed by the receiver, including a payment hash in the invoice; public knowledge of the payment preimage is proof that the receiver has in fact received money, and any third party can be convinced of this by being shown the signed invoice and the preimage). The receiver could just take one part of the payment and then claim to be underpaid by the payer and then deny service, but claiming any one part is enough to publish the payment preimage, creating a proof-of-payment: so the receiver can provably be made liable, even if it took just one part, thus the incentive of the receiver is to only take in the payment once all parts have arrived to it.
High requires elliptic curve points / scalars. It combines both Original and Base, retaining proof-of-payment (sacrificed by Original) and ensuring cryptographically-secure waiting for all parts (rather than the mere economically-incentivized of Base). This is done by using elliptic curve homomorphism to addition of scalars to add together the payer-provided preimage (really scalar) of Original with the payee-provided preimage (really scalar) of Base.
Better expected reliability. Channels are limited by capacity. By splitting up into many smaller payments, you can fit into more channels and be more likely to successfully reach the payee.
Capacity on mutiple of your channels can be used to pay. Currently if you have 0.05BTC on one channel and 0.05BTC on another channel, you can't pay 0.06BTC without first rebalancing your channels (and paying fees for the rebalance first, whether the payment succeeds or not). With multipart you can now combine the capacities of multiple of your channels, and only pay fees for combining them if the payment pushes through.
Wumbo payments (oversized payments) come "for free" without having to be explicitly supported by the nodes of the network: you just split up wumbo payments into parts smaller than the wumbo limit.
Multipart will have higher fees. Part of the feerate of each channel is a flat-rate fee. Going through multiple paths means paying more of this flat-rate fee.
It's not clear how to split up payments. Heuristics for payment splitting have to be derived and developed and tested.
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).
Enables a shit-ton of improvements: payment decorrelation, stuckless payments, noncustodial escrow over Lightning (the Hodl Hodl Lightning escrow is custodial, read the fine print), High multipart.
It's the same coolness that makes Schnorr Signatures cool. ECDSA, despite being based on elliptic curves, is not cool because the hash-the-nonce operation needed to prevent it from infringing Schnorr's fatherfucking patent also prevents ECDSA from using the cool elliptic curve homomorphism of addition over scalars.
Requires Schnorr on Bitcoin layer.
Actually, we can work with 2p-ECDSA without waiting for Schnorr. We get back the nice elliptic curve homomorphism by passing the ECDSA nonce through another cryptosystem, Paillier. This gets us the ability to do Scriptless Script. I think it has only 80-bits security because of going through Paillier though.
Basically the conundrum is: we could implement 2p-ECDSA now, hope we never have to test the 80-bit security anytime soon, then switch to Schnorr with 128-bit security later (which means reimplementing a bunch of things, because the calculations are different and the data that needs to be exchanged between channel participants is very different between the 2p-ECDSA and Schnorr). Reimplementing is painful and is more dev work. If we don't implement with 2p-ECDSA now, though, we will be delaying all the nice elliptic curve goodness (stuckless, noncustodial escrow, payment decorrelation) until Bitcoin gets Schnorr.
Elliptic curve discrete log problem is theoretically quantum-vulnerable. If we can't find a qunatum-resistant homomorphic construction, we'll have to give up the advantages (payment decorrelation, stuckless payments, noncustodial escrow over Lightning) we got from using elliptic curve points and go back to boring old hashes.
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.
Enables data providers to sell data. This could be sensors, livestreams, blogs, articles, whatever.
There's no scheme to determine if the data provider is providing actually-useful data. The data-provider could just stream https://random.org for example. This is a potentially-impossible problem. Even if the data-provider provides a "sample" of the data, and is able to derive some proof that the sample is indeed a true snippet of the encrypted data, the rest of the data outside of the sample might just be random junk.
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:
The payment scalar corresponding to the payment point in the invoice signed by the payee.
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.
Can safely run multiple parallel payment attempts as long as you have the funds to do so.
Needs payment point + scalar
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.
True non-custodial escrow: the escrow service never holds any funds.
Needs payment point + scalar.
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.
Privacy! Multiple forwarding nodes cannot coordinate to try to uncover the payer and payee of each payment.
Lastupdated2018-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!
Lightning Network White Paper - The protocol has changed since this original paper, but covers the mid-level mechanics of the Lightning Network with an emphasis on the smart contracts that make it trustless
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?
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?
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?
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?
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?
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?
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 logsMeeting 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:
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.
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
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 logsMeeting 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.
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:
A node (N) announces the new tip with an "inv" message, containing the block hash
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
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:
Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
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.
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?
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 medium.com 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 https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.bhhh1hza6
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.
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.
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.
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 . 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"  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.  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  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.
Level of supermajority
First, it was reported that the Chinese miners came up with a 2MB blocksize plan in late January , 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 . 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.
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.
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 outcome. 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% . 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. Conclusion 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:
short preparation time, and resulting uncertainty and pressure
non-trivial chance of old chain remaining active after activation
miners' and core's plans being ignored 
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 :) Cheers, aj  "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, ..." https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe011865.html via https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
Creation of [bitcoin-discuss] mailing list planning
6706 “CLTV IsSuperMajority() soft-fork, rebased for v0.10.2”
6707 “CLTV IsSuperMajority() soft-fork, rebased for v0.11.0”
All Unspecified 5 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 Unspecified 6 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
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 ...
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 http://www.teachparentstech.org/ 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 ...