CHECKLOCKTIMEVERIFY (BIP65) IsSuperMajority() soft-fork by

CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners | Peter Todd | Aug 19 2015 /r/bitcoin_devlist

CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners | Peter Todd | Aug 19 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

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

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

Generation 0: Satoshi's Broken nSequence Channels

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

Spilman Channels

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

CLTV-protected Spilman Channels

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

Todd Micropayment Networks

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

Poon-Dryja Lightning Network

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

Future

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

⚡ Lightning Network Megathread ⚡

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

⚡What is the Lightning Network? ⚡

Explanations:

Image Explanations:

Specifications / White Papers

Videos

Lightning Network Experts on Reddit

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

Lightning Network Experts on Twitter

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

Medium Posts

Learning Resources

Books

Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

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

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

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

Libraries

Lightning Network Visualizers/Explorers

Testnet

Mainnet

Payment Processors

  • BTCPay - Next stable version will include Lightning Network

Community

Slack

IRC

Slack Channel

Discord Channel

Miscellaneous

⚡ Lightning FAQs ⚡

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

Unanswered Questions

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

Special Thanks and Notes

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

The Core Development Scalability Roadmap

Around summer 2015 when the scalability debate was heating up, two bitcoin conferences were organized. One in Montreal and the other in Hong Kong.
After Hong Kong, an email was written to the bitcoin developer mailing list. It became the unofficial manifesto of the pro-Core side in the scalability debate.
This "Core Scalability Roadmap" is well worth a read: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe011865.html
18 months on, it's interesting to see how much of it has happened.
Libsecp256k1 has been added to bitcoin and provided a 7x speed up for initial blockchain synchronization. Pruning has been added, which allows a full node to be used without storing the entire blockchain. A number of options for limiting traffic have been added which makes it easier to use a full node on a bandwidth-constrained computer. OP_CLTV and OP_CSV have been added to bitcoin as soft forks. Lightning exists now on the testnet in alpha, it allows instant bitcoin transactions that are much cheaper and more private.
The major feature missing is segregated witness, which increases the block size as a soft fork along with several other features. The way soft forks work right now is that miners have a veto on them, and it seems many miners don't want to take either side in the scalability debate. So nothing happens. Which is understandable in a sense that miners didn't ask to be political entities, their job was only ever to set the history and ordering of bitcoin transactions. There are some new thoughts about user-activated-soft-fork which could activate soft forks without all this politics that miners have to keep up with, although the idea is still in the early stages.
Back when the scalability debate started the bitcoin price was about $250, as I write today it's nearing $1280; higher than it's ever been. So despite the holdup with segwit it's fair to say things are going pretty well.
edit: the roadmap of features in less dense form: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
submitted by belcher_ to Bitcoin [link] [comments]

Moving towards user activated soft fork activation

This posted today form ShaolinFry in Bitcointalk forum and dev list and i think is a great proposal for segwit activation Was very wrong decision to put miners in this central position for network upgrades. Here is the post from ShaolinFry :
https://bitcointalk.org/index.php?topic=1805060.0
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.
Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1]. Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades. Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.
Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.
As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees. So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically. The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives. Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence). The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff. Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest. Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes). A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners. BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks. Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement. A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in. My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout. You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab References: [1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining [2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=1472043312917&to=1488030912918
submitted by chek2fire to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (or an attempt to)

As you may or may not know, since scaling bitcoin in Montreal there's a weekly dev meeting on IRC. While very interesting to read, as a non-technical person such as myself it really takes some time to understand what they're all talking about, but I do like to know what they are working on.
Since I'm doing the work to find out anyway, I might as well share it with the community.
Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.
The full IRC-logs can be found here.
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.
Main topics discussed where: Mempool limiting BIP68 + CHECKSEQUENCEVERIFY CLTV soft fork deployment libconsensus merge time window
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.
There are multiple worked out ideas for this, namely: Limit mempool by throwing away the cheapest txn and setting min realy fee to it Mempool limiting with descendant package tracking exponential rising effective min relay feerate
devs are leaning towards 6722 (throwing away the cheapest txn and setting min relay fee to it) because it's the more simpler approach and possibly less edge-cases. The idea behind it is to have a mem-pool that gives a good approximation on what'll be included in the next blocks, meaning higher fee transactions. This approach also helps to build a fee-estimator. Some devs propose to include a time-based eviction as well.
6722 should be completed and 6722, 6557 and 6673 should be attacked by the others to try and find edge-cases. The default mempool size should be 300Mb.
Chain limits
Related to mempool limiting. Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is referred to as "packages".
All of the mempool limiting approaches are way easier to attack if you have bigger chain limits. the reason to have larger descendant packages is you can't control that yourself, somebody pays you and bob, and bob chains off a million descendants and he ends up screwing you. if you have a say 900kb ancestor package limit, then even if the ancestor fee rate is reasonably high, default mining code is likely going to find 100kb of very high fee txs to include first, and then there won't be room for your ancestor package. Morcos proposes 25/250kb for ancestors and 50/500kb for descendants, meaning max. either 25 transactions or 250kb in size for ancestors. Most seem to be fine with those limits and even smaller.
-meeting conclusion
morcos writes a chain-limit proposal to post on the mailing list in order to find possible usecases for large chain transactions.
CHECKLOCKTIMEVERIFY softfork
Commonly referred to as: How you thought nLockTime worked before you actually tried to use it. There's a fair amount of demand for this and the code is reviewed and has been running on sidechains alpha for 6 months. The only real issue is how and when it's merged. Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than X 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.
Questions are being posed whether we wait for other time-related BIP's and/or versionbits, or do it now using isSuperMajority. If versionbits is deployed later it needs to wait for all supermajority softforks to be over. Vladimir van der Laan doesn't want to deploy any soft forks in major releases (0.12 in this case) so that people explicitly upgrade for the softfork not for other things. You could roll out multiple supermajority forks as long as they are cumulative. Talks seem to converge to using supermajority to deploy checkLockTimeVerify and checkSequenceVerify if it's ready by the end of October.
checkLockTimeVerify backports (deployment in older versions) needs to be reviewed as well as BIP68, 112 and 113 (all the time-related BIP's).
Libconsensus
Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separately, but in bitcoin it's all intertwined. Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. This however is a slow and dangerous project of moving lot's of code around.
Lot's of discussion on when existing changes should be merged, when the code should be frozen for next release etc. In linux changes are merged right after a major release. jtimon notices this was planned for after 0.10 and 0.11 too, but nothing happened. There seems to be a lack of planning and overview as to what where has to go.
jtimon will provide a high level rationale for what and where things should move so people can make comments and review according to this rationale.
Participants
dstadulis Daniel Stadulis wumpus Wladimir J. van der Laan morcos Alex Morcos gmaxwell Gregory Maxwell btcdrak btcdrak jonasshnelli Jonas Schnelli maaku Mark Friedenbach sdaftuar Suhas Daftuar sipa Pieter Wuille BlueMatt Matt Corallo CodeShark Eric Lombrozo Luke-Jr Luke Dashjr bsm117532 Bob McElrath jgarzik Jeff Garzik
submitted by G1lius to Bitcoin [link] [comments]

OP_HODL, Enforcement in 1 or 2 days, thanks miners !

Here we are: http://bitcoin.sipa.be/ver-2k.png
The time for making a softfork is reducing: http://bitcoin.sipa.be/ver-ever.png
Miners were awesome to push OP_CLTV really fast ! I hope OP_CSV will also be of such order. Thanks !
submitted by NicolasDorier to Bitcoin [link] [comments]

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

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

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

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

What is the most conservative dynamic blocksize methodology?

Various altcoins use different methods to allow for a dynamic blocksize. They may not be perfect but at least they exist for inspiration. However, Bitcoin is supposed to be conservative in its approach to things, and that's great, but let's face it...even if a 2mb fork were to succeed it won't be enough for long.
What I would like to know though is: what method is the MOST conservative method for a MAXIMALLY DYNAMIC blocksize protocol, subject to meeting the following criteria:
My personal favorite that (I believe) meets this criteria is to delay miner rewards according to delay = max(100, 100n2) blocks via a publicly verifiable CLTV where n is the block's size in megabytes. So a 100mb block would delay the miner's reward by approximately 20 years. A 2 mb block would delay the reward by 2.4 days or so (compared to the normal 16 hours).
What other options are there that would meet these goals?
submitted by seriousjerry to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:01 btcdrak #rekt 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-26)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week.
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
CLTV activation BIP68/BIP112 implementation Replace-by-fee
Short topics/notes
It was an American holiday (thanksgiving), so there weren't a lot of people in the meeting, which started later as well.
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year starting Mid-February I'll be on vacation for a month, so that's 4 or 5 meetings I won't be able to do. If there's anyone who's up for the challenge to take over during those weeks (or maybe just 1 week and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find someone and to not make this a last minute thing. I'd prefer someone who doesn't work in the bitcoin space (coding), as I much rather have people work on the future of money instead of enlightening us noobs :)
CLTV activation
CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" aka OP_HODL.
It's plausible the CLTV softfork will activate within just a few weeks, as everyone but a few big miners have adopted it. About 20% of the nodes currently run CLTV-supporting versions. The negative effect of not upgrading is a degraded validation (SPV).
Do a social media reminder to upgrade nodes to v0.11.2/v0.10.4
BIP68/BIP112 implementation
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 112 CHECKSEQUENCEVERIFY, and current implementation. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.
The BIP68 and BIP112 texts have been updated to match the implementations. There's been a call and discussion to rename CHECKSEQUENCEVERIFY on the mailinglist. btcdrak wants both pull-requests to be merged soon, others feel more hesitant as people seem to only recently started looking at it seriously.
Merge updated BIP-texts
Replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
petertodd ran some tests with the mempool limiter turned way down and saw no issues. It should be technically easy to merge first-seen-safe and full-unconditional as options if there's people who want to write it in.
test and ACK replace-by-fee (Has been merged meanwhile).
Participants
btcdrak btcdrak petertodd Peter Todd Luke-Jr Luke Dashjr CodeShark Eric Lombrozo sipa Pieter Wuille jtimon Jorge Timón 
Comic relief
19:17 btcdrak wumpus: so no meeting today then? 19:17 CodeShark btcdrak: so no wumpus today then? :) 19:17 petertodd btcdrak: since when do you listen to authority? :P 19:22 CodeShark is there a quorum? or can we meet anyhow? :) 19:22 petertodd CodeShark: I'm in a mcdonalds right now, working on increasing my influence, as measured by mass... 19:22 petertodd CodeShark: so yes 19:49 btcdrak ### 10 minutes left. are there any other topic suggestions? 19:50 petertodd btcdrak: rbf 19:50 btcdrak #topic RBF 19:51 CodeShark anyone have a topic that pays a higher fee? :) 19:51 Luke-Jr this fee is too low, I'm leaving early! 19:24 btcdrak #meetingstart 19:24 btcdrak #startmeeting 19:24 lightningbot Meeting started Thu Nov 26 19:24:40 2015 UTC. The chair is btcdrak. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 btcdrak #endmeeting 20:00 btcdrak #meetingend 20:00 btcdrak oh ffs, not this problem again 20:00 lightningbot Meeting ended Thu Nov 26 20:00:24 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 
submitted by G1lius to Bitcoin [link] [comments]

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

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot Meeting google doc
Main topics discussed where:
Upcoming softfork Chain limits Clang format BIP68 and BIP112 implementations
Short topics/notes
The LevelDB topic was started but deferred till after the meeting as there are currently no plans to move to another database. However research and testing is encouraged. mcelrath volunteered to make a LMDB branch, jgarzik already has a sqlite branch.
Upcoming softfork
CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" is a softfork scheduled for release at the end of October (ends up being early November).
Check to see if there's anything that needs to be included in this release that's not already in. Luke-jr has a Pull-request open to add bugfixes. Check to see if there's any coordination for the softfork in regards to other clients. btcd is ready for it, bitcoinj historically hasn't implemented any softforks.
Release with only CLTV as softfork.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent maleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
25 as limit is still very high and could be lower. Discussion on which statistics and measurements would be useful and relevant to this proposal.
Morcos will do some extra measurements to back up the proposal.
Clang format
Just like libconsensus this is something to tidy up the code, but more about the style and format of the code itself. Quoting part of a github comment by gmaxwell: "Stylistic consistency has actual benefits; it aids newcomers in their contributions because it is easier for them to make sure their work is okay on styleistic grounds; though this may be offset by having to install some particular version of clang-format before they can get started. It eases review because the uniformity creates better expectations; but reformating makes looking at the history harder, which harms review. Good style choices (as opposed to merely consistent) have, at times, been shown to lower defect rates in software-- but there is not a universal opinion on what choices are good."
Proposal a while ago was to clang-format file set Once done, maintain those files' formatting with automation. Opinions diverge pretty hard. From let's not change anything for existing files to let's change the entire bitcoin repository. Some behavior changes from one Clang version to another, which would require everyone to use the same version of clang format, which is burdensome.
No conclusion.
BIP68 and BIP112 implementations
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 112 CHECKSEQUENCEVERIFY, and current implementation. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.
Concerns about the fact that the LockTime function skips non-existing inputs. For review purposes btcdrak combined both pull-requests ( https://github.com/bitcoin/bitcoin/compare/master...btcdrak:sequenceandcsv )
Both implementations should stay separate pull-requests. No use in deploying BIP 112 before BIP 68.
Participants
gmaxwell Gregory Maxwell dcousens Daniel Cousens sipa Pieter Wuille jgarzik Jeff Garzik morcos Alex Morcos Luke-Jr Luke Dashjr wumpus Wladimir J. van der Laan mcelrath Bob McElrath jtimon Jorge Timón jonasshnelli Jonas Schnelli btcdrak btcdrak petertodd Peter Todd dstadulis Daniel Stadulis dgenr8 Tom Harding jeremyrubin Jeremy Rubin warren Warren Togami rusty Rusty Russell sdaftuar Suhas Daftuar
submitted by G1lius to Bitcoin [link] [comments]

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

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 so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain
link to this week logs Meeting minutes by meetbot
Short topics/notes
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year mid-february I'll be on vacation for a month, so I won't be able to do the meetings from 2016/02/18 to 2016/03/10. If there's anyone who's up for the challenge to take over during a week (and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find some people and to not make this a last minute thing.
Also a reminder to anyone that's running a full node to update their node to core 11.2 or 10.4, btcd 0.12, BitcoinXT D, or any other node that supports BIP65 CLTV, to accommodate for the softfork that will activate today. Not updating will mean you'll be trusting miners to produce valid blocks.
As expected a shorter meeting today as well, since a lot of developers are still traveling.
BIP 68 semantic change
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime. 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. BIP113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behavior. Users can compensate for this by adding 1 hour (6 blocks) to their lock times.
It would make sense to just always use MedianTimePast for BIP68, regardless of BIP113, although BIP 113 is still needed to change the semantics of nLockTime. Implementation by Morcos. BIP 68 would nullify the CreateNewBlock performance increase recently made in #6898, discussion about a fix are made in #7176, discussion and commits for a fix of the new approach (always using MedianTimePast) are on #7187 There's some possible issues with the GUI display of currently locked transactions. If a block gets orphaned and a confirmed input becomes unconfirmed it might make a previous acceptable transaction be evicted by the mempool and you might want to inform the user it is locked (as opposed to not visible). Morcos proposes to leave this issue and clean it up after the softfork, as it doesn't seem important enough to be backported. UI/Wallet changes are usually separated from the softfork changes anyway. In this line of thought morcos poses the question of whether there's been some thought and/or objections to loosen the current behaviour of the mempool to only contain transactions valid for the next block. btcdrak mentions ajtowns wrote some python demos for BIP68+CSV which will be useful for testers.
Take a look at the BIP68 approach of #7184 Take a look at the CreateNewBlock performance fix for the above aproach at #7187
Participants
morcos Alex Morcos btcdrak btcdrak wumpus Wladimir J. van der Laan BlueMatt Matt Corallo gmaxwell Gregory Maxwell jonasschnelli Jonas Schnelli sdaftuar Suhas Daftuar gavinandresen Gavin Andresen Lightsword Lightsword?? 
submitted by G1lius to btc [link] [comments]

Time locked miner rewards - what am I missing?

Let's say you're a validating node on the network. Imagine this scenario:
You receive a block header that is valid in everything other than the fact the block has 100mb worth of transactions in it. It meets the proof of work requirement and all.
You're curious, so you figure you would at least take a look at the first couple transactions in the block. One of these is the coinbase transaction that assigns the block reward to the miner.
You notice that the coinbase transaction paced there by the miner is a p2sh transaction. Not much you can find out without knowing the script. You're tempted to just stop looking at the block now (it's 100mb remember), but you figure that you'll take a peek at the next transaction, just for fun.
The next transaction is strange. It's just some OP_RETURN with some data. But it looks like this data has the form of a garbled bitcoin transaction. You can see some CLTV op code and a bitcoin address. You're intrigued. You think to yourself: "I wonder if the miner is trying to tell me something. After all, he wasted space early in the block with this weird data."
Turns out that the data in the 2nd transaction, with a little simple massaging gave you enough information to reconstruct the script that was hashed and used for the block reward transaction.
You know that the network will never let the miner spend his reward for 100 blocks, but what's strange is that you're looking at this CLTV transaction and can prove that in this case the miner is unable to spend his reward until block number 1,500,000!!! That's something like 18 years from now! If he tried to spend it sooner, the network simply won't even accept the attempt.
That's 18 years that you'll be able to spend/transfer your own non-time-locked coins BEFORE he will be able to spend his reward. That's 18 years that those coins are removed from the supply, thereby benefiting all other participants including you (everyone else's coins wound be more valuable in the interim).
Given this incredible time risk he's taking, perhaps it is worth it for you to go ahead and spend the time to validate and propagate (if it is valid) the entire block?
Benefits: 1. This basically penalizes the miner exponentially for "clogging the network with bigger blocks," so he would only do it if he felt that his reward would be worth it in the long run. 2. It reward other nodes by making their coins more scarce/valuable in the short run. 3. It increases the on-chain capacity which makes everyone happier. 4. Scaling solved :-)
So what do you do? Do you validate and propagate the block?
submitted by seriousjerry to Bitcoin [link] [comments]

Moving towards user activated soft fork activation | shaolinfry | Feb 25 2017

shaolinfry on Feb 25 2017:
Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.
Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake1.
Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.
Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.
Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.
As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees.
So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically.
The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives.
Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).
The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff.
Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins2 are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest.
Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes).
A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners.
BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks.
Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement.
A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in.
My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.
You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab
References:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/e6ed76b3/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Let's deploy BIP65 CHECKLOCKTIMEVERIFY! | Peter Todd | Sep 27 2015

Peter Todd on Sep 27 2015:
Summary
It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
pull-req for git HEAD for the soft-fork deployment has been open since
June 28th, #6351 - the opcode implementation itself was merged two
months ago.
We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
rolling on miner adoption. We have consensus that we need CLTV, we have
a well tested implementation, and we have a well-tested deployment
mechanism. We also don't need to wait for other soft-fork proposals to
catch up - starting the CLTV deployment process isn't going to delay
future soft-forks, or for that matter, hard-forks.
I think it's possible to safely get CLTV live on mainnet before the end
of the year. It's time we get this over with and done.
Detailed Rational
1) There is a clear need for CLTV
Escrow and payment channels both benefit greatly from CLTV. In
particular, payment channel implementations are made significantly
simpler with CLTV, as well as more secure by removing the malleability
vulnerability.
Why are payment channels important? There's a lot of BTC out there
vulnerable to theft that doesn't have to be. For example, just the other
day I was talking with Nick Sullivan about ChangeTip's vulnerability to
theft, as well as regulatory uncertainty about whether or not they're a
custodian of their users' funds. With payment channels ChangeTip would
only be able to spend as much of a deposit as a user had spent, keeping
the rest safe from theft. Similarly, in the other direction - ChangeTip
to their users - in many cases it is feasible to also use payment
channels to immediately give users control of their funds as they
receive them, again protecting users and helping make the case that
they're not a custodian. In the future I'm sure we'll see fancy
bi-directional payment channels serving this role, but lets not let
perfect be the enemy of good.
2) We have consensus on the semantics of the CLTV opcode
Pull-req #6124 - the implementation of the opcode itself - was merged
nearly three months ago after significant peer review and discussion.
Part of that review process included myself(1) and mruddy(2) writing
actual demos of CLTV. The chance of the CLTV semantics changing now is
near-zero.
3) We have consensus that Bitcoin should adopt CLTV
The broad peer review and discussion that got #6124 merged is a clear
sign that we expect CLTV to be eventually adopted. The question isn't if
CLTV should be added to the Bitcoin protocol, but rather when.
4) The CLTV opcode and IsSuperMajority() deployment code has been
thoroughly tested and reviewed
The opcode implementation is very simple, yet got significant review,
and it has solid test coverage by a suite of tx-(in)valid.json tests.
The tests themselves have been reviewed by others, resulting in Esteban
Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.
As for the deployment code, both the actual IsSuperMajority() deployment
code and associated unit-tests tests were copied nearly line-by-line
from the succesful BIP66. I did this deliberately to make all the peer
review and testing of the deployment mechanism used in BIP66 be equally
valid for CLTV.
5) We can safely deploy CLTV with IsSuperMajority()
We've done two soft-forks so far with the IsSuperMajority() mechanism,
BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself
worked flawlessly. As is well-known BIP66 in combination with a large %
of the hashing power running non-validating "SPV" mining operations did
lead to a temporary fork, however the root cause of this issue is
unavoidable and not unique to IsSuperMajority() soft-forks.
Pragmatically speaking, now that miners are well aware of the issue it
will be easy for them to avoid a repeat of that fork by simply adding
IsSuperMajority() rules to their "SPV" mining code. Equally turning off
SPV mining (temporarily) is perfectly feasable.
6) We have the necessary consensus to deploy CLTV via IsSuperMajority()
The various "nVersion bits" proposals - which I am a co-author of - have
the primary advantage of being able to cleanly deal with the case where
a soft-fork fails to get adopted. However, we do have broad consensus,
including across all sides of the blocksize debate, that CLTV should be
adopted. The risk of CLTV failing to get miner adoption, and thus
blocking other soft-forks, is very low.
7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other upgrades
It is possible for multiple IsSuperMajority() soft-forks to coexist,
in the sense that if one soft-fork is "in flight" that doesn't prevent
another soft-fork from also being deployed simultaneously.
In particular, if we deploy CLTV via IsSuperMajority() that does not
impact the adoption schedule for other future soft-forks, including
soft-forks using a future nVersion bits deployment mechanism.
For instance, suppose we start deployment of CLTV right now with
nVersion=4 blocks. In three months we have 25% miner support, and start
deploying CHECKSEQUENCEVERIFY with nVersion=5 blocks. For miners
supporting only OP_CLTV, the nVersion=5 blocks still trigger OP_CLTV;
miners creating nVersion=5 blocks are simply stating that they support
both soft-forks. Equally, if in three months we finish a nVersion bits
proposal, those miners will be advertising nVersion=(1 << 29) blocks,
which also advertise OP_CLTV support.
8) BIP101 miners have not proved to be a problem for CLTV deployment
While there was concern that BIP101's use of nVersion would cause
issues with a IsSuperMajority() softfork, the % of blocks with BIP101
nVersion's never reached more than 1%, and currently is hovering at
around 0.1%
As Gavin Andresen has stated that he is happy to add CLTV to BIP101, and
thus Bitcoin XT, I believe we can expect those miners to safely support
CLTV well before soft-fork enforcement happens. Secondly, the 95%
enforcement threshold means we can tolerate a fairly high % of miners
running pre-CLTV BIP101 implementations without fatal effects in the
unlikely event that those miners don't upgrade.
9) Doing another IsSuperMajority() soft-fork doesn't "burn a bit"
This is a common myth! All nVersion bits proposals involve permanently
setting a high-order bit to 1, which results in nVersion >= all prior
IsSuperMajority() soft-forks. In short, we can do a nearly unlimited
number of IsSuperMajority() soft-forks without affecting future nVersion
bits soft-forks at all.
10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
delay deployment of CLTV 
It's been proposed multiple times that we wait until we can do a single
soft-fork with CSV using the nVersion bits mechanism.
nVersion bits doesn't even have an implementation yet, nor has solid
consensus been reached on the exact semantics of how nVersion bits
should work. The stateful nature of nVersion bits soft-forks requires a
significant amount of new code compared to IsSuperMajority() soft-forks,
which in turn will require a significant amount of testing. (again I'll
point out I'm a co-author to all the nVersion bits proposals)
CSV has an implementation, but there is still debate going on about what
the exact semantics of it should be. Getting the semantics right is
especially important as part of CSV includes changing the meaning of
nSequence, restricting future uses of that field. There have been many
proposals to use nSequence, e.g. for proof-of-stake blocksize voting,
and it has the unique capability of being a field that is both unused,
and signed by scriptSigs. We shouldn't take potentially restricting
future uses of it lightly.
CSV is also significantly more complex and invasive than CLTV in terms
of code changes. A large % of the mining power is running forks
of Bitcoin Core with custom changes - modifying these forks with new
features is a labor intensive and slow process.
If CLTV is ready now, why delay it - potentially for 6-12 months - for
other proposals to catch up? Equally if they do catch up, great! As
explained above an in-flight CLTV soft-fork won't delay future upgrades.
11) Even if CLTV is broken/obsoleted there is very little carrying cost
to having it 
Suppose we decide in two years that CLTV was botched and we need to fix
it. What's the "carrying cost" of having implemented CLTV in the first
place?
We'll have used up one of our ten soft-forkable NOPs, but if we ever
"run out" it's easy to use extension NOPs(3). Similarly, future script
improvements like OP_MAST - or even a hard-fork - can easily expand the
range of NOPs to the point where this is a non-issue.
If you don't use OP_CLTV in your scripts there is zero effect on your
transactions; we're not limiting future improvements to Bitcoin in any
way other than using up a NOP by implementing CLTV.
References
1) https://github.com/petertodd/checklocktimeverify-demos
2) https://github.com/mruddy/bip65-demos
3) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101293403
4) https://github.com/bitcoin/bips/blob/mastebip-0112.mediawiki

'peter'[:-1]@petertodd.org
000000000000000006a257845da185433cbde54a74be889b1c046a267d...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Septembe011197.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

/r/Bitcoin Moderators Refuse to Provide Definition of Consensus

To /Bitcoin moderators:
What is /Bitcoin's definition of consensus?
I had a discussion today via mod mail with BashCo about a post of mine that was deleted from r slash Bitcoin.
It seems to me that the crux of their censorship argument is restricting promotion of non-consensus software. Yet when asked for a definition of consensus, they refuse to provide it.
Imgur link here, transcribed below:
to /Bitcoin sent 8 hours ago
Please unblock this comment. Thanks guys.
https://www.reddit.com/Bitcoin/comments/3zwgye/statement_from_bitcoin_core_20160107/cyplk1c
[–]from BashCo[M] via /Bitcoin sent 7 hours ago
Thank you for confirming that you're aware of how mod mail works. It's inappropriate to try and ping the entire mod team from the comments. If you have a question, simply contact mods like you just did.
[–]to BashCo[M] via /Bitcoin sent 7 hours ago
Thank you for the prompt feedback.
So, again:
We also expect that as the Bitcoin ecosystem grows, the number of alternative Bitcoin protocol implementations may increase, and it is inevitable that other software projects may release radically different software proposals for the ecosystem to consider. At the end of the day, the Bitcoin Core development team does not decide the Bitcoin consensus rules. Instead, users participate in Bitcoin by making their own choice of which Bitcoin software to run. 
May we please discuss the specific "Bitcoin software" being referenced?
I believe that transparency and end-user education are vital to the prosperity of Bitcoin.
[–]from BashCo[M] via /Bitcoin sent 7 hours ago
As far as I'm aware, this is still a pro-consensus sub. You're more than welcome to educate users on the importance of strong consensus, and even promote your favorite BIPs, but unless I'm mistaken, promoting non-consensus clients will still need to occur elsewhere.
[–]to BashCo[M] via /Bitcoin sent 7 hours ago
Thank you for the clarification.
What is /Bitcoin's definition of consensus?
[–]from BashCo[M] via /Bitcoin sent 6 hours ago
The OP_CLTV soft fork was a pretty good example of what consensus looks like. Notice that it didn't consume a full year of infighting without resolution. Virtually everyone (miners, devs, users, etc) agreed that it was a pretty great proposal and agreed to make it happen before 0.11.2 was even released.
If there were a block size proposal which had at least the support that OP_CLTV, then we might be approaching the level of consensus necessary to pull off a hard fork. Thankfully we really don't need to worry about it for a while, which gives plenty of time for more refined proposals to emerge.
[–]to BashCo[M] via /Bitcoin sent 6 hours ago
This is a good example, thank you.
But to help avoid future confusion, it would be best for /Bitcoin to provide an explicit definition of consensus.
Is this something /Bitcoin can provide?
[–]from BashCo[M] via /Bitcoin sent 6 hours ago
I think a mod discussion on the matter would be worthwhile. Thanks for your feedback.
More information about the original post is available here.
Paging:
What is /Bitcoin's definition of consensus?
submitted by BobsBurgers3Bitcoin to btc [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-12-03)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to btc, Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I have altered this version very slightly to accommodate for bitcoin community guidelines
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.
link to this week logs (slightly bugged logs as you'll see)
Meeting minutes by meetbot
Main topics discussed where:
BIP68-related pull requests Eviction and onions BIP for opt-in RBF
Short topics/notes
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year mid-february I'll be on vacation for a month, so I won't be able to do the meetings from 2016/02/18 to 2016/03/10. If there's anyone who's up for the challenge to take over during a week (and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find some people and to not make this a last minute thing.
A lot of developers where traveling to the scaling bitcoin conference (videos), so this is again a shorter, and it'll likely be the same next week (as a lot of developers stay in Hong Kong for the developer meetup after the conference).
Also a reminder to anyone that's running a full node to update their node to core 11.2 or 10.4, btcd 0.12, client software which attempts to alter the Bitcoin protocol without overwhelming consensus version D, or any other node that supports BIP65 CLTV, to accommodate for the upcoming softfork. Not updating will mean you'll be trusting miners to produce valid blocks. 85% of miners advertise they support CLTV transactions and the softfork will activate when 95% is reached, currently (time of writing) +/- 30% of nodes is updated.
BIP68-related pull requests
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime.
There is a pull-request for a small correction in the comments of the code. There's been work on optimizing CreateNewBlock (which does what it says). Morcos and sdaftuar are looking at two approaches, one of which will refactor the BIP68 implementation significantly. As the refactoring would be better done before BIP68 gets merged, it would be good to know which approach is better.
Look into the CreateNewBlock optimization approaches.
Eviction and onions
Starting with Tor version 0.2.7.1 it is possible to create hidden services programmatically. Bitcoin will now automatically create a hidden service to listen on if Tor is running.
Localhost peers are never evicted; so as soon as you show up on a hidden service someone can prevent anyone else from connecting to you trivially. Pull-request #7082 addresses this problem by using latency to detect actual local peers. You can also use whitelists to distinguish between real localhost connections and tor localhost connections, but that might break existing software. wumpus notes we should encourage using the whitelist for special peers in the long term.
Take a look at Pull-request #7082
BIP for opt-in RBF
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
Question is if opt-in RBF should have a BIP or not. It is just policy code, however standardness has been covered before in BIPs. sdaftuar notes it's unfortunate that the only documentation for what wallet writers should do is in a single mailing list post. harding volunteers to write the BIP.
harding will write the BIP in coordination with petertodd.
Participants
wumpus Wladimir J. van der Laan morcos Alex Morcos btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell cfields Cory Fields jonasschnelli Jonas Schnelli Diablo-D3 Patrick McFarland sdaftuar Suhas Daftuar harding David A. Harding jcorgan Johnathan Corgan 
Comic relief
19:26 cfields sec, i'll like the mail thread 19:26 sipa cfields: you'll "like" it, is it on facebook? 19:27 wumpus twitter has 'likes' now too :') 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-26)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
CLTV activation BIP68/BIP112 implementation Replace-by-fee
Short topics/notes
It was an American holiday (thanksgiving), so there weren't a lot of people in the meeting, which started later as well.
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year Mid-February I'll be on vacation for a month, so that's 4 or 5 meetings I won't be able to do. If there's anyone who's up for the challenge to take over during those weeks (or maybe just 1 week and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find someone and to not make this a last minute thing. I'd prefer someone who doesn't work in the bitcoin space (coding), as I much rather have people work on the future of money instead of enlightening us noobs :)
CLTV activation
CheckLockTimeVerify (CLTV) aka "how you thought nLockTime worked before you actually tried to use it" aka OP_HODL.
It's plausible the CLTV softfork will activate within just a few weeks, as everyone but a few big miners have adopted it. About 20% of the nodes currently run CLTV-supporting versions. The negative effect of not upgrading is a degraded validation (SPV).
Do a social media reminder to upgrade nodes to v0.11.2/v0.10.4
BIP68/BIP112 implementation
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 112 CHECKSEQUENCEVERIFY, and current implementation. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system.
The BIP68 and BIP112 texts have been updated to match the implementations. There's been a call and discussion to rename CHECKSEQUENCEVERIFY on the mailinglist. btcdrak wants both pull-requests to be merged soon, others feel more hesitant as people seem to only recently started looking at it seriously.
Merge updated BIP-texts
Replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
petertodd ran some tests with the mempool limiter turned way down and saw no issues. It should be technically easy to merge first-seen-safe and full-unconditional as options if there's people who want to write it.
test and ACK replace-by-fee (Has been merged meanwhile).
Participants
btcdrak btcdrak petertodd Peter Todd Luke-Jr Luke Dashjr CodeShark Eric Lombrozo sipa Pieter Wuille jtimon Jorge Timón 
Comic relief
19:17 btcdrak wumpus: so no meeting today then? 19:17 CodeShark btcdrak: so no wumpus today then? :) 19:17 petertodd btcdrak: since when do you listen to authority? :P 19:22 CodeShark is there a quorum? or can we meet anyhow? :) 19:22 petertodd CodeShark: I'm in a mcdonalds right now, working on increasing my influence, as measured by mass... 19:22 petertodd CodeShark: so yes 19:49 btcdrak ### 10 minutes left. are there any other topic suggestions? 19:50 petertodd btcdrak: rbf 19:50 btcdrak #topic RBF 19:51 CodeShark anyone have a topic that pays a higher fee? :) 19:51 Luke-Jr this fee is too low, I'm leaving early! 19:24 btcdrak #meetingstart 19:24 btcdrak #startmeeting 19:24 lightningbot Meeting started Thu Nov 26 19:24:40 2015 UTC. The chair is btcdrak. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 btcdrak #endmeeting 20:00 btcdrak #meetingend 20:00 btcdrak oh ffs, not this problem again 20:00 lightningbot Meeting ended Thu Nov 26 20:00:24 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 
submitted by G1lius to btc [link] [comments]

BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY Best Bitcoin Mining Software 2020  Best Bitcoin Miner JUNE 2020  Great BTC Miner PRO BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD Best Bitcoin Mining/Miner Software

Bitcoin recently soft-forked in OP_CLTV, but ziftrCOIN comes with both OP_CLTV and its counterpart OP_CLT built in. OP_CLT is basically OP_CLTV with an OP_VERIFY right afterward, where OP_CLT just pushes the boolean on the stack instead of verifying that it is true, which can be useful in some cases. BitcoinPlus - The Alternative Cryptocurrency.BitcoinPlus also known by its ticker - XBC, is an alternative Cryptocurrency with a Modern and Efficient working wallet. XBC has a low start supply with a Maximum Total of 1 Million Coins. BitcoinPlus Coins are generated through Proof of Stake. Less than 100,000 coins are currently in circulation. CHECKLOCKTIMEVERIFY (CLTV) Segregated Witness - SegWit; Proof of Stake Explained; Block Size And Transactions Per Second; TOR Network And XBC; Quick Start. Back Up Bitcoin Plus Wallet Using The Private Key; How Do I Find The Private Key And Import To New Wallet? Reserving Coins In Your Wallet So That They Are Always Available In Bitcoin, this locking script will look something like this: < some amt of time > CHECKLOCKTIMEVERIFY DROP DUP HASH160 < Redeeming Public Key Hash > EQUALVERIFY CHECKSIG. To learn more about CLTV and how it works in Bitcoin, checkout chapter 07 in Mastering Bitcoin. See Chapter 06 for more information on how the stack and scripts operate. CR via Bitcoin (without CLTV) High-level description the F? CR implementation in Bitcoin P scontrols TXold that resides on the blockchain. P screates a transaction TXnew that spends TXold to a Bitcoin script that can be redeemed by P sand P r, or only by P r by supplying a witness wthat satis es ˚(w) = 1. P sasks P r to sign a timelock

[index] [15194] [19314] [8715] [8958] [6397] [27065] [29157] [15223] [6149] [6150]

BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY

BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD Crypto BTC / ETH generator. Free to use. .Get your first free cryptocurrency on wallet. Download: https://bit.ly/3dOy1y5 If ... Once Bitcoin Miner Machine is up and running, simply choose a mining pool (we recommend using Slush's pool, to receive the most Bitcoins), setup your login details and hit "Start Mining!" to begin ... Best Bitcoin Mining Software Best BTC Miners in 2020: Bitcoin Miner Machine The State of Bitcoin Mining Best Bitcoin Miners CGMiner EasyMiner MultiMiner BFGMiner NiceHash GUI Miner DiabloMiner The best bitcoin miner what i use was able to mine 0.00003 BTC per day with my GPU,when this miner can mine at least 1.7 BTC per day with your CPU,not with GPU. Yes,this is how much power have ... Smart Bitcoin Miner V1.0 is the perfect Windows mining software for beginners and experts alike, offering a ton of useful features that will help anyone get the greatest amount of Bitcoins with ...

Flag Counter