Bitcoin Wallet Store Bitcoin Cash (BCH) & Bitcoin (BTC)

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 (2016-01-28)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
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

Logs

Main topics

Short topics

ajtowns has written some functional test scripts for OP_CSV which will be helpful for testing #7184(BIP 68) and #6564(BIP 112)

Refactoring window

background

jtimon asks when exactly this is and what it entails. Refactoring is moving code around to specific libraries or files to make things easier to read and to safely change parts of the code without affecting other parts. Mainly these will be moves to facilitate libconsensus, the part that will hold all the consensus-critical code.

meeting comments

Wumpus is fine with starting to merge moveonly stuff. The refactors might interfere with segregated witness, however waiting for it might cause the refactor window for 0.13 to be missed.

meeting conclusion

Refactor window is from now till -undecided- Review #7091, #7287, #7310 and #7311

outstanding issues for 0.12.0

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc2 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

We need to sign the win32 release with a new key for win7+ as the current key uses sha-1 which is broken. There's still some controversy how the changes for priority should be noted in the release notes. e.g. #7346 gmaxwell points out we never did anything about the issues with localhost being whitelisted which might cause issues with the new automatic hidden service creation. This issue was raised in the 2015/12/03 meeting

meeting conclusion

There will be a new key, if it takes too long to get it someone else can sign it this time. gmaxwell will change #7082 to only remove the privledging of localhost. The rest of the PR can be done for 12.1/0.13

how does this new "critical" OpenSSL release affect us

background

There's a new openSSL release which fixes some security issues. https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html Question is if and how this affects bitcoin. Since 0.12 bitcoin-core uses their own libsecp256k1 for ECDSA signature verification instead of openSSL.

meeting comments

BIP70 (Payment Protocol) might be affected. The parts of core that still depend on openSSL are entropy, AES (wallet) and BIP70. There's a plan to replace openSSL for entropy with fortuna (build by sipa and gmaxwell), which needs to be build into a separate library. There are many complications in making a safe random number generator, first among them is fork detection (fork= a unix operation which duplicates the entire process state which will lead to reuse of random numbers) Wumpus notes openSSL has the same issues and we only have to be better than openSSL, also bitcoin never forks so the problem is mainly for other applications using the library. It would be good if this was an effort which included non-bitcoin users (e.g. mailinglist & tor)

meeting conclusion

Long term goal is leaving openSSL only for BIP70.

Participants

wumpus Wladimir J. van der Laan jonasschnelli Jonas Schnelli gmaxwell Gregory Maxwell petertodd Peter Todd jtimon Jorge Timón cfields Cory Fields btcdrak btcdrak Luke-Jr Luke Dashjr paveljanik Pavel Janik maaku Mark Friedenbach 

Comic relief

19:47 wumpus note also that bitcoin never forks 19:48 wumpus gmaxwell: just add a disclaimer 'not fork safe' 19:48 jonasschnelli 'not fork safe'? HF or SF.... 19:48 jonasschnelli  
submitted by G1lius to Bitcoin [link] [comments]

Merkle branch verification & tail-call semantics for generalized MAST | Mark Friedenbach | Sep 07 2017

Mark Friedenbach on Sep 07 2017:
I would like to propose two new script features to be added to the
bitcoin protocol by means of soft-fork activation. These features are
a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution
semantics.
In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force
redemption to use values selected from a pre-determined set committed
to in the scriptPubKey, but without requiring revelation of unused
elements in the set for both enhanced privacy and smaller script
sizes. Tail-call execution semantics allows a single level of
recursion into a subscript, providing properties similar to P2SH while
at the same time more flexible.
These two features together are enough to enable a range of
applications such as tree signatures (minus Schnorr aggregation) as
described by Pieter Wuille [1], and a generalized MAST useful for
constructing private smart contracts. It also brings privacy and
fungibility improvements to users of counter-signing wallet/vault
services as unique redemption policies need only be revealed if/when
exceptional circumstances demand it, leaving most transactions looking
the same as any other MAST-enabled multi-sig script.
I believe that the implementation of these features is simple enough,
and the use cases compelling enough that we could BIP 8/9 rollout of
these features in relatively short order, perhaps before the end of
the year.
I have written three BIPs to describe these features, and their
associated implementation, for which I now invite public review and
discussion:
Fast Merkle Trees
BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
MERKLEBRANCHVERIFY
BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431
Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify
Tail-call execution semantics
BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics
Note: I have circulated this idea privately among a few people, and I
will note that there is one piece of feedback which I agree with but
is not incorporated yet: there should be a multi-element MBV opcode
that allows verifying multiple items are extracted from a single
tree. It is not obvious how MBV could be modified to support this
without sacrificing important properties, or whether should be a
separate multi-MBV opcode instead.
Kind regards,
Mark Friedenbach
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Septembe014932.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-21)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
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

Logs

Main topics

Short topics

0.11 backport release for chainstate obfuscation

background

As some windows users might have experienced in the past, anti-virus software regularly detects values in the bitcoin database files which are false-positives. Thereby deleting those files and corrupting the database. To prevent this from happening developers discussed a way to obfuscate the database files and implemented it last year. While downgrading after upgrading is possible, if you start from a new 0.12 installation or you've done a -reindex on 0.12 it's impossible to downgrade to 0.11 (without starting from scratch).

meeting comments

The proposed pull-request detects the obfuscation in 0.11 so it throws a relevant error message. To avoid this in the future it would be good to have versionnumbers for the chainstate.

meeting conclusion

Release a 0.11 backport release right after the 0.12 final release to avoid confusion.

C++11 update

background

C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.

meeting comments

All changes needed for C++11 have gone in and it's ready to switch. Cfields talked to the travis team and all the features needed (trusty, caching) will be ready by the end of the month, so he proposes to wait until then to flip the switch. Wangchung from f2pool indicated he would not run code that required a C++11 compiler. No one knows what his exact concerns are. Wumpus notes the gitian-built executables don't need any special OS support after the C++11 switch.

meeting conclusion

Wait for Travis update to switch to C++11. Talk to wangchung about his concerns.

EOL Policy / release cycles

background

In general bugfixes, translations and softforks are maintained for 2 major releases. btcdrak proposed to makes this official into a software life-cycle document for bitcoin core in order to inform users what to expect and developers what to code for. Pull request for this document. Given the huge 0.12 changelog jonasschnelli asks whether shorter release cycles might be a good idea. Currently there's a +/- 6 month release cycle.

meeting comments

Gmaxwell notes he doesn't know how useful the backports are given there's no feedback about them, but thinks the current policy is not bad. "I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree." If no one is using the backports, it might not see sufficient testing. People generally agree with the 2 major releases approach.
The cyclelength also contributes to frustration and pressure to get features in, as it won't see the light of day for 6 months if it doesn't make the new release. For users it's not really better to have more frequent major releases, as upgrading may not always be a trivial process. There's also a lot of work going into releases. If the GUI and wallet where detached there could be more frequent releases for that part.

meeting conclusion

Policy will be: final release of 0.X means end-of-life of 0.(X-2), which means a 1 year support on the 6 month cycle.

Participants

wumpus Wladimir J. van der Laan gmaxwell Gregory Maxwell jonasshnelli Jonas Schnelli cfields Cory Fields btcdrak btcdrak sipa Pieter Wuille jtimon Jorge Timón maaku Mark Friedenbach kangx_ ??? Kang Zhang ??? sdaftuar Suhas Daftuar phantomcircuit Patrick Strateman CodeShark Eric Lombrozo bsm117532 Bob McElrath dkog ?dkog? jeremias ??? Jeremias Kangas ??? 

Comic relief

jonasschnelli maaku: refactoring? We have a main.cpp. We don't need refactoring. :) gmaxwell jonasschnelli: can we move everything back into main.cpp? I'd save a lot of time grepping. :P wumpus #endmeeting lightningbot` Meeting ended Thu Jan 21 19:55:48 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) btcdrak wumpus: hole in one maaku Did it right this time! gmaxwell Hurray! 
submitted by G1lius to Bitcoin [link] [comments]

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

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

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

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

Bitcoin dev IRC meeting in layman's terms (2016-01-21)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
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

Logs

Main topics

Short topics

0.11 backport release for chainstate obfuscation

background

As some windows users might have experienced in the past, anti-virus software regularly detects values in the bitcoin database files which are false-positives. Thereby deleting those files and corrupting the database. To prevent this from happening developers discussed a way to obfuscate the database files and implemented it last year. While downgrading after upgrading is possible, if you start from a new 0.12 installation or you've done a -reindex on 0.12 it's impossible to downgrade to 0.11 (without starting from scratch).

meeting comments

The proposed pull-request detects the obfuscation in 0.11 so it throws a relevant error message. To avoid this in the future it would be good to have versionnumbers for the chainstate.

meeting conclusion

Release a 0.11 backport release right after the 0.12 final release to avoid confusion.

C++11 update

background

C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.

meeting comments

All changes needed for C++11 have gone in and it's ready to switch. Cfields talked to the travis team and all the features needed (trusty, caching) will be ready by the end of the month, so he proposes to wait until then to flip the switch. Wangchung from f2pool indicated he would not run code that required a C++ compiler. No one knows what his exact concerns are. Wumpus notes the gitian-built executables don't need any special OS support after the C++11 switch.

meeting conclusion

Wait for Travis update to switch to C++11. Talk to wangchung about his concerns.

EOL Policy / release cycles

background

In general bugfixes, translations and softforks are maintained for 2 major releases. btcdrak proposed to makes this official into a software life-cycle document for bitcoin core in order to inform users what to expect and developers what to code for. Pull request for this document. Given the huge 0.12 changelog jonasschnelli asks whether shorter release cycles might be a good idea. Currently there's a +/- 6 month release cycle.

meeting comments

Gmaxwell notes he doesn't know how useful the backports are given there's no feedback about them, but thinks the current policy is not bad. "I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree." If no one is using the backports, it might not see sufficient testing. People generally agree with the 2 major releases approach.
The cyclelength also contributes to frustration and pressure to get features in, as it won't see the light of day for 6 months if it doesn't make the new release. For users it's not really better to have more frequent major releases, as upgrading may not always be a trivial process. There's also a lot of work going into releases. If the GUI and wallet where detached there could be more frequent releases for that part.

meeting conclusion

Policy will be: final release of 0.X means end-of-life of 0.(X-2), which means a 1 year support on the 6 month cycle.

Participants

wumpus Wladimir J. van der Laan gmaxwell Gregory Maxwell jonasshnelli Jonas Schnelli cfields Cory Fields btcdrak btcdrak sipa Pieter Wuille jtimon Jorge Timón maaku Mark Friedenbach kangx_ ??? Kang Zhang ??? sdaftuar Suhas Daftuar phantomcircuit Patrick Strateman CodeShark Eric Lombrozo bsm117532 Bob McElrath dkog ?dkog? jeremias ??? Jeremias Kangas ??? 

Comic relief

jonasschnelli maaku: refactoring? We have a main.cpp. We don't need refactoring. :) gmaxwell jonasschnelli: can we move everything back into main.cpp? I'd save a lot of time grepping. :P wumpus #endmeeting lightningbot` Meeting ended Thu Jan 21 19:55:48 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) btcdrak wumpus: hole in one maaku Did it right this time! gmaxwell Hurray! 
submitted by G1lius to btc [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-28)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
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

Logs

Main topics

Short topics

ajtowns has written some functional test scripts for OP_CSV which will be helpful for testing #7184(BIP 68) and #6564(BIP 112)

Refactoring window

background

jtimon asks when exactly this is and what it entails. Refactoring is moving code around to specific libraries or files to make things easier to read and to safely change parts of the code without affecting other parts. Mainly these will be moves to facilitate libconsensus, the part that will hold all the consensus-critical code.

meeting comments

Wumpus is fine with starting to merge moveonly stuff. The refactors might interfere with segregated witness, however waiting for it might cause the refactor window for 0.13 to be missed.

meeting conclusion

Refactor window is from now till -undecided- Review #7091, #7287, #7310 and #7311

outstanding issues for 0.12.0

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc2 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

We need to sign the win32 release with a new key for win7+ as the current key uses sha-1 which is broken. There's still some controversy how the changes for priority should be noted in the release notes. e.g. #7346 gmaxwell points out we never did anything about the issues with localhost being whitelisted which might cause issues with the new automatic hidden service creation. This issue was raised in the 2015/12/03 meeting

meeting conclusion

There will be a new key, if it takes too long to get it someone else can sign it this time. gmaxwell will change #7082 to only remove the privledging of localhost. The rest of the PR can be done for 12.1/0.13

how does this new "critical" OpenSSL release affect us

background

There's a new openSSL release which fixes some security issues. https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html Question is if and how this affects bitcoin. Since 0.12 bitcoin-core uses their own libsecp256k1 for ECDSA signature verification instead of openSSL.

meeting comments

BIP70 (Payment Protocol) might be affected. The parts of core that still depend on openSSL are entropy, AES (wallet) and BIP70. There's a plan to replace openSSL for entropy with fortuna (build by sipa and gmaxwell), which needs to be build into a separate library. There are many complications in making a safe random number generator, first among them is fork detection (fork= a unix operation which duplicates the entire process state which will lead to reuse of random numbers) Wumpus notes openSSL has the same issues and we only have to be better than openSSL, also bitcoin never forks so the problem is mainly for other applications using the library. It would be good if this was an effort which included non-bitcoin users (e.g. mailinglist & tor)

meeting conclusion

Long term goal is leaving openSSL only for BIP70.

Participants

wumpus Wladimir J. van der Laan jonasschnelli Jonas Schnelli gmaxwell Gregory Maxwell petertodd Peter Todd jtimon Jorge Timón cfields Cory Fields btcdrak btcdrak Luke-Jr Luke Dashjr paveljanik Pavel Janik maaku Mark Friedenbach 

Comic relief

19:47 wumpus note also that bitcoin never forks 19:48 wumpus gmaxwell: just add a disclaimer 'not fork safe' 19:48 jonasschnelli 'not fork safe'? HF or SF.... 19:48 jonasschnelli  
submitted by G1lius to btc [link] [comments]

WARUM BITCOIN GEFALLEN IST WARUM BITCOIN GECRASHT IST The Main Principles Of Bitcoin For Beginners - Blockchain ... WARUM DU BITCOIN KAUFEN SOLLTEST Easiest Way To Receive or Spend Bitcoin, Litecoin, Dogecoin and SwiftCash with Proof of Keys

Wenn Sie vorhaben, ein eigenes Bitcoin-Konto zu erstellen, dann sollten Sie einige Punkte beachten. Was Sie alles benötigen und wie Sie am besten vorgehen, erfahren Sie hier: Bitcoin ist eine sogenannte Kryptowährung, also ein digitales Zahlungsmittel. Aber wie kauft man eigentlich Bitcoins? FOCUS Online erklärt, wie's geht. These RPCs remove a private key from the wallet (turning it into a watch-only address), or forget a watch-only address and all transactions that were only tied to that wallet by that address. Bitcoin Wallet - A SPV wallet for Android, written in Java. bitcoinj - A library for SPV wallets, written in Java. btcd - A full node, written in Go. BTCPay Server - A cross platform, self-hosted server compatible with Bitpay API, written in C#. btcwallet - A hierarchical deterministic wallet daemon, written in Go. Bitcoin Wallet - A SPV wallet for Android, written in Java. bitcoinj - A library for SPV wallets, written in Java. btcd - A full node, written in Go. BTCPay Server - A cross platform, self-hosted server compatible with Bitpay API, written in C#. btcwallet - A hierarchical deterministic wallet daemon, written in Go.

[index] [39696] [49036] [5440] [44189] [24125] [35940] [6415] [16747] [34401] [31533]

WARUM BITCOIN GEFALLEN IST

Ich habe nun damit angefangen, mich mit Bitcoin auseinander zu setzen und möchte meine Erfahrungen mit Dir teilen! Im heutigen Video sprechen wir über die Gründe wieso der Bitcoin innerhalb ... На моём канале я делюсь с полезными аксиомами и правиламы разных МЛМ компаний ! Живем мы чтобы наслаждаться ... Online Wallet: https://goo.gl/s6wMpq Offline Wallet: https://amzn.to/2JVWhkD Hast du dir auch schon immer gewünscht, von Zuhause aus Geld zu verdienen, ohne etwas dafür zu tun? Ich habe nun ... Zu Besuch in der Bitcoin-Mine: Hier fließt die virtuelle Währung in Millionenhöhe. Mehr Galileo: http://www.galileo.tv/ Galileo auf YouTube abonnieren: htt... SWIFT's web wallet is an open-source wallet written in html, css and javascript. All signatures are handled on the client-side and private keys never leave the browser. To secure the account of ...

#