bitcoin core - CLTV vs nLockTime - Bitcoin Stack Exchange

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

Update UNO wallets to 0.11.0

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

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

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

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-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 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
On a personal note: I really don't like the fact someone pm'ed me telling me "a majority of bitcoiners have moved to btc", it's not (yet) true and comes across as very spammy. This combined with the tin-foiled hat people-bashing which seems to be popular makes me almost not want to join this community. I hope this can become like bitcoin, but with the freedom to discuss and mention any topic, not a mindless crusade against bitcoin, theymos, blockstream, etc.
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 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
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, bitcoinXT 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 btc [link] [comments]

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

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

[Informational] [CC0] Lightening Blockchain Load

Lightning Network

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

Motivation

The Scalability Problem

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

Scalability Solutions

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

The End of SPV

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

Achieving Lightning

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

Opening Payment Channels

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

Instant Settlement

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

Settlement Security

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

In Breach of Contract

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

Closing Time

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

Potential Issues

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

Links

submitted by pb1x to writingforbitcoin [link] [comments]

planungswelten.de - YouTube PTXofficial - YouTube RIPPLE XRP NASDAQ! APOLLO CURRENCY DEX ATOMIC SWAPS DAG APOLLO CLOUD TPS AFRICA SHARDING! What Is Lifetime Value? - YouTube Cellbit - YouTube

bitcoin-qt -proxy=127.0.0.1:9050 -connect=abcde.onion , where abcde.onion needs to be substituted with one of the Tor nodes below. These parameters can be added to bitcoin.conf to make them permanent. You can find detailed information on running clients and hidden services within Tor in the documentation. Nodes list IPv4 Nodes. This entire list was last checked on 2017-11-15. Hostname Owner IP ... CLTV is currently used in CLTV-style payment channels. Relative locktime . In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the nSequence field that is a part of every transaction input, creating a "relative locktime". This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that ... From Bitcoin Wiki. Jump to: navigation, search. CoinLoan is a crypto-lending platform, where anyone can issue and get a loan backed by crypto-collateral. The platform is a meeting point for borrowers who seek to leverage their crypto-assets without selling them and lenders who wish to earn competitive interest with minimal risks. Contents . 1 Company; 2 History; 3 Main Functions. 3.1 Interest ... From Bitcoin Wiki. Jump to: navigation, search. SegWit . Segregated Witness (abbreviated as SegWit) is an implemented protocol upgrade intended to provide protection from transaction malleability and increase block capacity. SegWit separates the witness from the list of inputs. The witness contains data required to check transaction validity but is not required to determine transaction effects ... Bitcoin Wiki says: When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block ...

[index] [47927] [6976] [46357] [21205] [18482] [25035] [49572] [15802] [16812] [16221]

planungswelten.de - YouTube

Share your videos with friends, family, and the world In unserem Kanal stellen wir euch Planungshilfen, Konfiguratoren und Visualisierungstools vor, die euch beim Einrichten und Planen eurer Wohnung helfen und i... Three-time Grammy® Award-winning and multi-Platinum-selling Pentatonix has sold nearly 10 million albums worldwide and performed for hundreds of thousands of... ABRA SUA CONTA GRATUITAMENTE NA XDEX: http://bit.ly/2vYMOlj OUÇA O PRIMOCAST: http://bit.ly/PrimoCast-des Abra sua conta na Rico: https://bit.ly/cadastrasepr... Learn what the difference between a proxy token based decentralized exchange and a native one. Agama GUI lead developer Satinder also talks about the risks with a conventional centralized exchange ...

#