SHA-256 Algorithmus – Verschlüsselung – BitcoinWiki

To address concerns about my identity

Doubts about my identity seem to crop up, so I like to address all those once more. Hopefully in a comprehensive way.
First of all, to explain the situation from my article again, originstamp.org is my go-to service. Usually, 24h is plenty and suffices to timestamp everything.
But in this case, Core went quickly ahead with release information, which made the 24h window (due to fees) too small to conclusively prove ownership on the BTC chain.
But let's have a look in detail. This is the text that I wrote:
BitcoinABC does not check for duplicate inputs when processing a block, only when inserting a transaction into the mempool. This is dangerous as blocks can be generated with duplicate transactions and then sent through e.g. compact block missing transactions and avoid hitting the mempool, creating money out of thin air. awemany 
If you SHA256 this, it calculates to: 5c45a1ba957362a2ba97c9f8c48d4d59d4fa990945b7094a8d2a98c3a91ed9b6
Exhibit A: I timestamped that here: https://originstamp.org/s/5c45a1ba957362a2ba97c9f8c48d4d59d4fa990945b7094a8d2a98c3a91ed9b6
Note that there is a timestamp when it entered their system, which is before anything else became public and which is:
17.9.2018, 14:54:19 CEST
It shows it in your local time zone in your browser, a fact that Peter Todd apparently tripped over as well: https://archive.fo/W1gdf
Scroll down to "Submission to OriginStamp" at the end.
This timestamp is, however, just from their service and thus centralized. But if you think I faked that, that would mean that I must have hacked their service in time to do so. In the last few days. Furthermore, the window for this hack would be quite small, as there is also a later submission into the blockchain. So if you doubt this information alone, it would mean I'd had to hack the service in time (within a few hours window) just to claim this identity, leave no trace of all of this, face the risk of being called out by the true finder of the bug (who'd be different then) and write this long article ...
But there's more:
Exhibit B: For anyone who is a member of the BU slack, I posted a message that was the above hash (as I said in my medium article) and which is still sitting unedited on the slack as well, in the #general channel. There are likely several hundred members of this slack, and all of them who read it should have seen this message in time. I believe there are also (well-behaved) Core supporters in there. I would need to have hacked that service in an undetected way as well and fool or collude with all active members therein as well. That now creates a pretty big collusion, don't you think?
Exhibit C: Finally, let me close with this PGP signed message. I created a PGP key just to keep my identity separate, at least for a while, from my main pseudonym awemany. And in the email I send out to the developers, I have added myself as a recipient. Even though the message has not been signed (I didn't see any reason to do so at the time of release), my full key id is still in this message. And that is, as far as I know, a 128-bit hash for which it is practically impossible to find a preimage for. This explicit 'encrypt-to-self' is because I fucked up with PGP encryption in the past (because, as I say in my article, mistakes just happen) and I wanted to at least be able to read my own encrypted message later. I have created sitations for myself where I wasn't able to read my own encrypted emails. Yes, call me a crypto noob, say PEBKAC or whatever, it is exactly an example of why I am saying that I am not perfect but so is no one else!
Here is this message, which I am sure anyone owning the original disclosure email is happy for you to confirm that it is the same key id:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This messsage is signed by the beardnboobies GPG key that I created just in time for the vulnerability disclosure. In reality, I am awemany on reddit and elsewhere. -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEERGszUXtt2s3Wfkt1yydp8d93NcQFAlumBkAACgkQyydp8d93 NcQvegwAmcfqKSp/RZVE6HIyN9gbxa5oz2YFaaoeVCoQTsDZPX08zjBjp7jzMUGW izraVk+yOz8Yxdv7re8G+CBqnpgfpNvMoHPe75bgoyKzavTtukVSScDUHZ9Tu9D7 xQcfWnwZhsUjsTsxFD7B6PLAWzeh7cA3d0xUwrFJoa//hlOylnlC/76cbBspqSll ispvQgBcEM6NfKvmCTb9LItts2/QrXX891LK9I4vPC1WpOrXPA9lNnuuP8/S/ey9 O7iqwW+oCwGKLELQJE58hgwt7keQukrPEfwUtBXACW77gtk1dXaxRL5RqCkmMsMn rBMkTGmjDit+AVE/5oW+flds8/Hq+kQDXUZfaLbnOrleW50LTTi+etA/PPhHxe45 CUD7Jm8d2LbTIjFWsZT/Rq2Djsy3gBcHeKqFMRXEBI7WoFe431q38gVSyfvbCrPR R4AJsg2eGgysu0E/SZecHHULc4CU6RdLmCRrORRSv1T9tOyJcRpfwRlE4FnT9LTC /+5v9mXI =k2oE -----END PGP SIGNATURE----- 
And here is the public key which matches that key Id and which has likewise not been made public yet:
-----BEGIN PGP PUBLIC KEY BLOCK----- mQGNBFufufgBDADJ3N5xocCOSyRrF42nvrujUZXRPnaq+X3E0GjNlCwuCFZELNE9 l950cR4l+sNFbjcvWtlCgAdHPAggED3ZeutTO3fAIClN+LOgnyEF4txjdG72j9L4 NnCVMfKhT2yc7JZQh3lS+GHFSBS8joLq09GxllTORvdawuW34yzV4rzFZZ3NfK+/ 8BtNAf+nXvtafugw4Nlln5LPvGna9bmh/74RlZTAJeV52a/WsucBQ7kVuWTAERMy N+DuvUIxh7gG9KbSQXsPQ+1ZleO9+nWJs4pgX3ro6ZRMYvN9jeJsDjx2uQoL77zM RwMKNis5ifxnkHmExOG01SQxz3j9tw1anC8dFi2zs9jlr+qjUofSUT0RctKNJlga BgDV1dsu8dg11xxo4slH93D5LqJJs3lg+RjxHeWE6Oxvpz4SQpU+sLT4T73xOh/d GDw4UmLMUgKjjlYexVhlNk6FUamAkpYzuTgN35AeUt1iGj9D9XAbbi0G3MjKYSX6 tPkBC5h7XIGDzGcAEQEAAbQuQmVhcmQnbidib29iaWVzIDxiZWFyZG5ib29iaWVz QHByb3Rvbm1haWwuY29tPokB1AQTAQoAPhYhBERrM1F7bdrN1n5LdcsnafHfdzXE BQJbn7n4AhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEMsnafHf dzXEi0gMAL0StgXSH4mbHPeyj0pJOmzOpEsfm7S05EKoGnMzmB/ZfCxag9YvDSSQ Jz28jOmPIrnLLkuOFcf0BnSKmys2WbEpGm5SgRU0anSTiiaTy2RjPa8eC34F6X/q LjgJ6J4hvOoDkQAjOzfspayRjRmFewNzssMHn6JC2NWvP+8+nClsJA959E9rxJ5F xaPmPZ9g4AJFah/vpRXbv44JQGbjr42CdB2JUTYW3rd7WjYFdcGcPU0UQhRQSflL 2ZOCw8bJCdPRRXpy2xTewTPE4eVcrclvmbKDhDbDNkY9cqDSPqag2JG8GoPsl3Ym 33uwzN1Y5qkocfGoVxr3eEEFQgkPnqX27OyGAL1+MoEOYuLuhUaNX2E/WmPZwtU3 E5JdjdIRfVfzI+oWs6Mfn1mbxeePBikjHgNgr4vs2+DkujeenS8UsD5Y6qrk9Ypt Erh5GRT0BauSSV52U3mEboMyxRHriObFT+BQAK0cJ4ZZ9aAUVLZcC4TXps2PKcjZ ozJYgvFm1rkBjQRbn7n4AQwAx7JiWJSuwAidK0AcPS2kt5gpzsESgxq1qyoeELYg tNb6G2SihbFj4hVMjc8Ol+a0wtcd+3D7Wcyu5EDbfnIydfmytIvF6CABWCkKtulG lxKSydMg16QGMwWixqTLRo1FoCdAzvKJktTshIlARoRt1cII/5n0C+Ny33kdm809 c+5EPFW22Hu5cNZR6xjYkONoM+Gw9JVIo5O9DY1l2s7qaQhnnTQDMBJLZjtOVFZF l/QQjnM5SJZr7lkzNMOgdA3saCbjk7NVMnV8ledLHYZguR3lDfsfdwWvw9Q3tEp9 Ii5P3AHzzV7eu0g6T7xpjV4LNssP1abvrBBd/RFfA6A3ec9wXEWTk2ewXpZLkicm 9VBy3nsz5bedoAvcyTVB0HF80yHbo99eSwEUenlrs0K0Yv97hxJ2ioPrhx4y7M9Q XRWRXFRaLBgLT5GxvIs9jRWJq7jwtKknA7GSun06UFKnOmiT81dmVf4Dne1F9y/R U7ld9Doo7IARUYP11/twEh5HABEBAAGJAbwEGAEKACYWIQREazNRe23azdZ+S3XL J2nx33c1xAUCW5+5+AIbDAUJA8JnAAAKCRDLJ2nx33c1xMiGDACbqHLuXMZ2937O aDfuchIYJ7BoqLiY+Po0V78jenYcx4pXXnau2rL44f02B6nV5RK21b+PwFDX+SMh usQfAYdBBRxIb0uDePKx2/Vb0UC5yb456eprYBXOIN7odl0J68PpjUQik5kqizig n/vyrIMMQehnFFee88xdSUYK495I6URJtIp6YLCYoalFs49l3szLJZK57OcCmfsR gzQbBIsPqQ7uqKZlGYZY9a/PYEZd3Lb6qLF693jZyNjDZ8IIfBjvJa3ZwJiTtNXi NknfmW2KcokFljOa5Fvs6Gu11Q9KpbVRpkKeHF79TSN5lPSwvBjsBbx9j4KoFBum yNNQTclRMe+AWHfcnoIXooFemiv27n6HEwoFEyoKm3ita1V+RiDuZ1e3FEA4zUPO XlZv6e7p+Cd0coP4FDWR5mq1ck+SOFoFuqNrqpEIumrHEC4wKcIA7iy/jJ5frgab UjEcFa/MBAaZ7If9+3kHh2kpfPwLOT+7Mm7i9kD1Yu3UBvwoYOE= =DyTh -----END PGP PUBLIC KEY BLOCK----- 
I am not going to disclose the original email just yet, because there is exploit code in there. Even though I think that exploit code is quite simple and will likely not do harm, there is no reason to add more risk and this could also still be used against me by trolls by being called irresponsible. So I hope folks understand why I refrain from that for now.
submitted by awemany to btc [link] [comments]

Fragmented hardware wallet seed backups

I've been thinking about the best way to safely store the seed phrase of a hardware wallet - the piece of paper (or steel) has always seemed like a bit of a weak point to me. So I'd love a convenient way to be able to split my seed phrase into fragments using a 2-of-3 scheme.
So I came up with a quick-and-dirty approach. Here are the sheets I prepared for this approach:
LibreOffice: https://www.dropbox.com/s/307cqbpgubsz4sb/fragmented-wallets.ods?dl=0
PDF: https://www.dropbox.com/s/bi5geew2i99e7bp/fragmented-wallets.pdf?dl=0
(The LibreOffice version is better because you can edit the wallet name on the sheet)
The idea is to split a 24-word seed phrase into three groups of 8 words - and write down a different pair of two of the groups on each backup fragment. Now, it's certainly not Shamir Secret Sharing, but it's easy to carry out with little risk of error and requires no software or offline computer to carry it out.
By my calculations, the effort required to crack the wallet using a single backup fragment is roughly equivalent (approximately one order of magnitude harder) than cracking the traditional Trezor recovery method: that is, even making some very generous assumptions, it would require an adversory with the resources to design and fabricate HMAC-SHA512 hashing chips of comparable speed to existing bitcoin double-SHA256 chips, and build a cluster the size of the entire bitcoin network, and it would still take years, unless the arracker is very, very lucky.
So although it's not ideal, and not going to remain safe for ever.... Unless you have a lot of coins and some very powerful adversories, it's probably good enough for a good few years :-)
I'd be very interested in thoughts on this - particularly on whether I've correctly calculated the security of this approach. Note, this scheme is only plausibly safe for 24-word seeds. You should not attempt something similar for shorter seeds
Analysis:
The best fragment to steel is the one that contains the first two portions of ENT (which is fragment #2 using my sheets). This gives you 2x88 bits of ENT and leaves 80 bits unknown - so you need to test 280 ENT values.
(One of the other two fragments will give you 88+80 bits of ENT plus the 8-bit checksum. This leaves you with 288 values to test, but one in 256 will fail the checksum, so it's still 280 values to feed to PBKDF2, but with slightly more work to get there.)
Now, creating a seed from the phrase requires 2048=211 rounds of HMAC-SHA512 - so completely ignoring the cost of testing the resulting seeds, we have to do 291 rounds of HMAC-SHA512 to test every value, or 290 on average.
Assuming a cracking cluster that can solve HMAC-SHA512 at the same rate that the entire Bitcoin network solves double-SHA256, it would take an average of 2^90/(6600*10^15)/(31*10^6) = 6 years to crack the seed from a single fragment.
Thoughts?
submitted by roybadami to btc [link] [comments]

Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options | Colin Lacina | Aug 09 2017

Colin Lacina on Aug 09 2017:
I believe I have come up with a structure that allows for trustless use of
hybrid wallets that would allow for someone to use a hybrid wallet without
having to trust it while still allowing for emergency recovery of funds in
the case of a lost wallet. It would run off of this TX script:
IF
 1 2 CHECKMULTISIGVERIFY 
ELSE
 2 2 CHECKMULTISIG 
ENDIF
A typical transaction using this would involve a user signing a TX with
their userWalletPrivKey, authenticating with the server, possibly with 2FA
using a phone or something like Authy or Google Authenticator. After
authentication, the server signs with their serverWalletPrivKey.
In case the server goes rogue and starts refusing to sign, the user can use
their userRecoveryPrivKey to send the funds anywhere they choose. Because
if this, the userRecoveryPrivKey is best suited to cold wallet storage.
In the more likely event that the user forgets their password and/or looses
access to their userWalletPrivKey as well as loses their recovery key, they
rely on the serverRecoveryPrivKey.
When the user first sets up their wallet, they answer some basic identity
information, set up a recovery password, and/or set up recovery questions
and answers. This information is explicitly NOT sent to serve with the
exception of recovery questions (although the answers remain with the user,
never seeing the server). What is sent to the server is it's 256 bit hash
used to identify the recovery wallet. The server then creates a 1025 bit
nonce, encrypts it, stores it, and transmits it to the user's client.
Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.
Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
SHA512 on the combination of the identity questions and answers, the
recovery password (if used), the recovery questions and answers, and the
nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.
Finally, the already encrypted key is encrypted again for transmission to
the server. The server decrypts it, then rencrypts it for long term storage.
When the user needs to resort to using this option, they 256 bit hash their
information to build their recovery identifier. The server may, optionally,
request e-mail and or SMS confirmation that user is actually attempting the
recovery.
Next, the server decrypts the saved nonce, as well as the first layer of
encryption on the serverRecoveryPrivKey, then encrypts both for
transmission to the user's client. Then the client removes the transmission
encryption, calculates the 512 bit hash that was used to originally encrypt
the serverRecoveryPrivKey by using the provided information and the nonce.
After all of that the user can decrypt the airbitzServerRecoveryPrivKey and
use it to send a transaction anywhere they choose.
I was thinking this may make a good informational BIP but would like
feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170809/9d5ee7a8/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014819.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.14.2 released | Wladimir J. van der Laan | Jun 17 2017

Wladimir J. van der Laan on Jun 17 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.14.2 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.14.2/
Or by torrent:
magnet:?xt=urn:btih:b4fc7820df95b8b39603ad246c241272ec403619&dn;=bitcoin-core-0.14.2&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes

miniupnp CVE-2017-8798
Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error
(present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers
(within the LAN) to cause a denial of service or possibly have unspecified
other impact.
This only affects users that have explicitly enabled UPnP through the GUI
setting or through the -upnp option, as since the last UPnP vulnerability
(in Bitcoin Core 0.10.3) it has been disabled by default.
If you use this option, it is recommended to upgrade to this version as soon as
possible.
Known Bugs

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
control and smart fee estimation does not reflect any change in target from the
smart fee slider. It will only present an approximate fee calculated using the
default target. The fee calculated using the correct target is still applied to
the transaction and shown in the final send confirmation dialog.
0.14.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

P2P protocol and network code

Build system

Miscellaneous

GUI

Wallet

Credits

Thanks to everyone who directly contributed to this release:
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCgAGBQJZRRTMAAoJEB5K7WKYbNJdqk0IANF5Q49ID3B77b0CwSKzjTxk
Ktp0qgvtig0ZMnzVlgjULUsRW8EbecWCQwmgRo8uUoCGmNS2u7u+s28kIIkicELE
BpWcW4eC6NdCCjB1CSnmX/tno4gFwOZutVj/XUXJCBEuBbo6fIK0cVDas5vw8UVa
gXL5ytwXeCws3z9f3iiD1Nl0k+J+dRb0sJ2u0A1+XqoMFfInMUFiP/fa9XWaimKo
62jD07IJDKtH4PEKG8v+FLZounRP7t1lhU0AiQ0Uj67mBmllwWD0KeZi0f4SokMX
aezEH+2UIW3Ph/QbG+ktZYUzbDALnRIHEBP4GQUuWiUPZKo3vAS3yhvh1nvYUW4=
=VBdE
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014597.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

BIP: Using Median time-past as endpoint for locktime calculations | Thomas Kerin | Aug 18 2015

Thomas Kerin on Aug 18 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
In collaboration with Mark Friedenbach, we have drawn up a proposal for
using
the median time of the past 11 blocks in locktime calculations.
BIP: XX
Title: Median time-past as endpoint for lock-time calculations
Author: Thomas Kerin <me at thomaskerin.io>
 Mark Friedenbach <[mark at friedenbach.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)> 
Status: Draft
Type: Standards Track
Created: 2015-08-10
==Abstract==
This BIP is a proposal to redefine the semantics used in determining a
time-locked transaction's eligibility for inclusion in a block. The
median of the last 11 blocks is used instead of the block's timestamp,
ensuring that it increases monotonically with each block.
==Motivation==
At present, transactions are excluded from inclusion in a block if the
present time or block height is less than or equal to that specified
in the locktime. Since the consensus rules do not mandate strict
ordering of block timestamps, this has the unfortunate outcome of
creating a perverse incentive for miners to lie about the time of
their blocks in order to collect more fees by including transactions
that by wall clock determination have not yet matured.
This BIP proposes comparing the locktime against the median of the
past 11 block's timestamps, rather than the timestamp of the block
including the transaction. Existing consensus rules guarantee this
value to monotonically advance, thereby removing the capability for
miners to claim more transaction fees by lying about the timestamps of
their block.
This proposal seeks to ensure reliable behaviour in locktime calculations as
required by BIP65, BIP68, and BIPXX (OP_CHECKSEQUENCEVERIFY).
==Specification==
The values for transaction locktime remain unchanged. The difference is
only in
the calculation determining whether a transaction can be included.
Instead of
an unreliable timestamp, the following function is used to determine the
current
block time for the purpose of checking lock-time constraints:
enum { nMedianTimeSpan=11 }; int64_t GetMedianTimePast(const CBlockIndex* pindex) { int64_t pmedian[nMedianTimeSpan]; int64_t* pbegin = &pmedian;[nMedianTimeSpan]; int64_t* pend = &pmedian;[nMedianTimeSpan]; for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = 
pindex->pprev)
 *(--pbegin) = pindex->GetBlockTime(); std::sort(pbegin, pend); return pbegin[(pend - pbegin)/2]; } 
Lock-time constraints are checked by the consensus method IsFinalTx(),
or LockTime() under BIP68. These methods take the block time as one
parameter. This BIP proposes that after activation calls to
IsFinalTx() or LockTime() within consensus code use the return value
of GetMedianTimePast(pindexPrev) instead.
A reference implementation of this proposal is provided in the
following git repository:
https://github.com/maaku/bitcoin/tree/medianpasttimelock
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and 66,
with the
same thresholds, but for block.nVersion = 4. The new rules are in effect for
every block (at height H) with nVersion = 4 and at least 750 out of 1000
blocks
preceding it (with heights H-1000...H-1) also have nVersion = 4.
Furthermore,
when 950 out of the 1000 blocks preceding a block do have nVersion = 4,
nVersion = 3 blocks become invalid, and all further blocks enforce the
new rules.
It is recommended that this soft-fork deployment trigger include other
related
proposals for improving Bitcoin's lock-time capabilities, such as BIP
65, BIP68
and CHECKSEQUENCEVERIFY.
==Acknowledgements==
Mark Friedenbach for designing and authoring the reference
implementation of this BIP.
Thomas Kerin authored this BIP document.
==Compatibility==
Transactions generated using time-based lock-time will take
approximately an hour longer to confirm than would be expected under
the old rules. This is not known to introduce any compatibility
concerns with existing protocols.
==References==
[https://github.com/bitcoin/bips/blob/mastebip-0065.mediawiki BIP65:
OP_CHECKLOCKTIMEVERIFY]
[https://github.com/bitcoin/bips/blob/mastebip-0068.mediawiki BIP68:
Consensus-enforced transaction replacement signaled via sequence numbers]
[https://github.com/bitcoin/bips/blob/mastebip-00.mediawiki BIPXX:
CHECKSEQUENCEVERIFY]
==Copyright==
This document is placed in the public domain.
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJV0oi8AAoJEAiDZR291eTl2soP/1MOjgQDncoUdMptqfeqMLfU
ewENNPLQwXXje7PFn/gIVa+Ghxu+f9rrRHt6v8Udd4wsnDTqhz2gV6dKCyF0K4IS
seLTH2kyTfPGm1KOp6WSwvxoyc5iWLBH4wkSm4oI9WmXkLzDq0yEYUDE8t9yNYwf
0Fgrg1KPIP4bhoxWchEa237rrH/qTh0Zdxdj/N0YCrX9u4fBy+xoTM6gnt0bFCK2
SaGXvC8PsA23gkJjjwFnWh/JU0Q5BJTElUsq1re3gmwcnLNKyB5cx0bFephk2pFd
NC3rqEIIVPd7aLs+lWmD4/NXdm+VtUEQo3MmQ1YW5zwjeoJxZhfMfXwmQw3vw2f7
FSyExUXNNwh2lMoLCcWvWWEOKYaSV9iLX4TacvpbOSDQgz3rDl3iqeLmSgp3S8M3
Se1S9AzilJsT0jIe2Ob2hu/gXEXeBmI9k2kRJELSaIFgCWadUky63NwNNfRipiBq
USroBIym2dpXFLygcwgwf6F/yAYYg6/5QiUKclhqvxArxVEcijw18SHGZVYpW83S
Q0mzJnRVGF7yscJl84zHyAj5QMWoMFgKSqFbOLcmNDUPLoaFJxAGezGCLXNaHinA
LY5Qp0t0Vg4hXi6QcCiWv2U8E1K4oN5VZNSlagUyXsAHd3c4icZTVj+TTWKJ7GLB
Gmbe3i9G90rpgDbHWXFq
=EQdY
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010348.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

BIP proposal: derived mnemonics | millibitcoin | Jul 26 2016

millibitcoin on Jul 26 2016:
(not sure so sent again after subscribing (one use case added))
Dear Bitcoin developers,
Below is provided a draft BIP proposal for a master mnemonic sentence
from which other mnemonics sentences can be derived in a deterministic
non-reversible way (on an offline computer). This would make it much
easier to split funds into smaller fractions and use those in a
HD-wallet when appropriate (just by inserting 12 or more words), without
ever putting the master mnemonic at risk on an online computer. But
there are many more use cases.
A reference implementation, specifically for use with a Trezor, has been
generated and can be found at:
http://thebitcoinecosystem.info/DerivedMnemonics.html
I'm not a professional programmer or cryptographer, so the idea and
reference implementation will probably need a lot of reviewing but I do
think Bitcoin needs this extension and the corresponding ease of use and
improved security model.
In the hope you like the idea,
Regards,
sumBTC
BIP: ???
Title: Derived mnemonics from a master mnemonic.
Author: sumBTC
Status: For Discussion
Type:
Created: 2016-07-24
==Abstract==
This BIP??? uses a master mnemonic sentence, as described in BIP39, for
the deterministic generation of derived mnemonic sentences. The derived
mnemonics are of the same format as the master mnemonic but can consist
of a higher or lower number of words.
Binary seeds can then be generated for derived mnemonics (and master
mnemonic) as described in BIP39. Each of these seeds can be used to
generate deterministic wallets using BIP-0032 or similar methods.
==Motivation==
A mnemonic code or sentence is superior for human interaction as
described in BIP39 and can, for example, be written on paper or even
memorized. However, once a mnemonic has been used online, even through
the use of a hardware wallet, the mnemonic could be compromised. This
should be considered a bad practice from a security standpoint.
We therefore propose the generation of a master mnemonic offline and
from this generate (also offline) multiple derived mnemonics in a
deterministic way for online use. The master mnemonic is never used
online and the master mnemonic cannot be obtained from the derived
mnemonics. Examples of use cases are described below.
==Generating the master mnemonic==
The master mnemonic is first derived as a standard mnemonic as described
in BIP39.
==From master mnemonic to derived mnemonics==
From the master mnemonic a new string is created:
string = MasterMnemonic + " " + Count + " " + Strength;
Here, MasterMnemonic are the space separated words of the master
mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
given strength and Strength = numWords / 3 * 32, where numWords is the
number of words desired for the derived mnemonic and only integer
arithmetic is used in the calculation (e.g. for numWords = 14, Strength
= 128). Both Count and Strength are converted to strings.
This string is then hashed using sha512:
hash = sha512(string);
and turned into a byte array:
for (var i=0; i>> ((i%4)*8)) & 0b11111111;
}
This byte array is then used to generate a new mnemonic as shown in the
reference implementation using the method described in BIP39. The core
of the new code in the reference manual can be found by jumping to
"start: new code" in the reference software.
A passphrase for the master mnemonic has the same effect on the derived
mnemoncis (so must be included).
==Reference Implementation==
The reference implementation generates addresses based on BIP44 for a 24
word master mnemonic and is available from
http://thebitcoinecosystem.info/DerivedMnemonics.html
or
github (not yet)
==Checking the derived mnemonics using Electrum==
The displayed addresses in each of the reference implementations can be
easily checked using Electrum in the following manner:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Hardware wallet
Restore Electum wallet from device seed words
TREZOR wallet
Insert one of the mnemonics and check that the same addresses are
generated by Electrum
Check the private keys:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Standard wallet
Import one of the private keys and check that the correct address has
been generated.
Some checks should include a passphrase.
==Examples of Use Cases==
A person with 25 bitcoin splits funds using 5 derived mnemonics and
sends 5 bitcoins to the first address of each derived mnemonic. He can
then use a (hardware) HD-wallet and simply insert one of the derived
mnemonics to put only 5 bitcoins online and at risk at once. All funds
can be recovered from the master mnemonic.
A person wants to give 10 bitcoin to each of his family members, giving
each participant a derived mnemonic and sending bitcoin to each of them.
The donating person can always recover the derived mnemonic if one of
his family members loses his derived mnemonic.
For his Trezor wallet, someone wants to memorize only a 12 words master
seed but wants to insert a 24 words derived seed so a key logger on his
computer has 24! possibilities to check and not 12! (not a possibility
for the current reference implementation but trivial to add).
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012901.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.14.1 released | Wladimir J. van der Laan | Apr 22 2017

Wladimir J. van der Laan on Apr 22 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.14.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.14.1/
Or, by torrent:
magnet:?xt=urn:btih:0482be8fc8e1c0b02162871e3591efc3d1d34585&dn;=bitcoin-core-0.14.1&tr;=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fatrack.pow7.com%2Fannounce&tr;=http%3A%2F%2Fbt.henbt.com%3A2710%2Fannounce&tr;=http%3A%2F%2Fmgtracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fopen.touki.ru%2Fannounce.php&tr;=http%3A%2F%2Fp4p.arenabg.ch%3A1337%2Fannounce&tr;=http%3A%2F%2Fpow7.com%3A80%2Fannounce&tr;=http%3A%2F%2Ftracker.dutchtracking.nl%3A80%2Fannounce
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later.
Microsoft ended support for Windows XP on April 8th, 2014,
No attempt is made to prevent installing or running the software on Windows XP, you
can still do so at your own risk but be aware that there are known instabilities and issues.
Please do not report issues about Windows XP to the issue tracker.
Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.
Notable changes

RPC changes
These interface changes break compatibility with 0.14.0, when the named
arguments functionality, introduced in 0.14.0, is used. Client software
using these calls with named arguments needs to be updated.
Mining
In previous versions, getblocktemplate required segwit support from downstream
clients/miners once the feature activated on the network. In this version, it
now supports non-segwit clients even after activation, by removing all segwit
transactions from the returned block template. This allows non-segwit miners to
continue functioning correctly even after segwit has activated.
Due to the limitations in previous versions, getblocktemplate also recommended
non-segwit clients to not signal for the segwit version-bit. Since this is no
longer an issue, getblocktemplate now always recommends signalling segwit for
all miners. This is safe because ability to enforce the rule is the only
required criteria for safe activation, not actually producing segwit-enabled
blocks.
UTXO memory accounting
Memory usage for the UTXO cache is being calculated more accurately, so that
the configured limit (-dbcache) will be respected when memory usage peaks
during cache flushes. The memory accounting in prior releases is estimated to
only account for half the actual peak utilization.
The default -dbcache has also been changed in this release to 450MiB. Users
who currently set -dbcache to a high value (e.g. to keep the UTXO more fully
cached in memory) should consider increasing this setting in order to achieve
the same cache performance as prior releases. Users on low-memory systems
(such as systems with 1GB or less) should consider specifying a lower value for
this parameter.
Additional information relating to running on low-memory systems can be found
here:
reducing-bitcoind-memory-usage.md.
0.14.1 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

    • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
    • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
    • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
    • #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
    • #10204 3c79602 Rename disconnectnode argument (jnewbery)

Block and transaction handling

    • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
    • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
    • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)

P2P protocol and network code

    • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
    • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)

Build system

  • - #9973 e9611d1 depends: fix zlib build on osx (theuni)

GUI

  • - #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)

Mining

    • #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
    • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)

Tests and QA

  • - #10157 55f641c Fix the mempool_packages.py test (sdaftuar)

Miscellaneous

    • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
    • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
    • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)
Credits

Thanks to everyone who directly contributed to this release:
    • Alex Morcos
    • Andrew Chow
    • Awemany
    • Cory Fields
    • Gregory Maxwell
    • James Evans
    • John Newbery
    • MarcoFalke
    • Matt Corallo
    • Pieter Wuille
    • practicalswift
    • rawodb
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJY+1YNAAoJEHSBCwEjRsmme+YIAIkJLCjimADYBJoM8bnHK2Dc
4KznlAjpXqFWb6taoSyWi+/6DtZxJF1MZm+iaDhqmTEy+ms313N2mBEd2xrSAPPL
nYf84e3tgnwq07sQmUxVZXyhZe2R+m/kgy75TTZw+bonyXwwA3384F0L8gvV5Iu+
kNNu6WggWUTvOADEFVKecgzWeT1FCYXklbNk+Z5T/YWWrKA8ATXgv45IIEKT8uI1
pqhKQxoqLM3ga7Df3VbzwXAYAOCaFzf+0nmTRoqDM5pX+FQ2hq0UM6joLnUNk2ee
G4/nsNWAKg/6eycrA7Wvawwcozr2iYAov/YDj6pEI8UoeGcOdlSh69Seb1cngHg=
=EHlY
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014228.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.13.2 released | Wladimir J. van der Laan | Jan 03 2017

Wladimir J. van der Laan on Jan 03 2017:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.13.2 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.13.2/
Or by bittorrent:
magnet:?xt=urn:btih:746697d03db3ff531158b1133bab5d1e4cef4e5a&dn;=bitcoin-core-0.13.2&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Microsoft ended support for Windows XP on April 8th, 2014,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is not clear
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes

Change to wallet handling of mempool rejection
When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error. The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.
This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.
Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).
0.13.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

Consensus

RPC and other APIs

Block and transaction handling

P2P protocol and network code

Build system

GUI

Wallet

Tests and QA

Miscellaneous

Credits

Thanks to everyone who directly contributed to this release:
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJYa2IbAAoJEHSBCwEjRsmmiQsIALbkHVVwO7nViQKH1Ub2qpD4
TplOuAP0/4vYotizuI12Gqdnu8SjPmhKwAgIXhVinE6TS4OzGNjy+6LtWGzpcpud
B1pcziZ72Mlfxdbdd1UhDMWEjoBumS9RmXMSqzTlMVlHRv4iiISzdaAROu1jHvdF
YTsnmKXB8OvcXOecxRMY9LrnpSzLALM2MYTDmYwlhhExHIA8ZqI2niky6GCfyfDi
KD7bgfIFJzlgFTpAdhQXOXtWoRV5iHqN7T29ot8Y+yIhVCRhHYXS93Z50GKbkqYV
MXsVAkpZF3qqcKYSPFjbif7faMdrMqcEiII6QhXdDTRGI/35IfuTDbWzzQlnVyY=
=ncCY
-----END PGP SIGNATURE-----
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013412.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Variable Block Size Proposal | Justin M. Wray | Aug 29 2015

Justin M. Wray on Aug 29 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hey Bitcoiners!
While I am an avid Bitcoin supporter, long-term user, and have done
development work on tools and platforms surrounding Bitcoin, I have
been very busy these past few weeks and haven't had a chance to fully
(or closely) monitor the Block Size debate.
I'm familiar with the basics, and have read abstracts about the
front-running proposals (BIP 100, 101, and 102). Though I've honestly
not read those in depth either. With that said, I was driving
the other day and thought of a potential idea. I'll be clear, this is
just an idea, and I haven't fully fleshed it out. But I thought I'd
throw it out there and see what people thought.
My Goal:
Provide a variable block size that provides for sustainable, long-term
growth, and balances the block propagation, while also being mindful
of potential spam attacks.
The Proposal:
Every 2016 blocks (approximately every two weeks, at the same time the
difficulty is adjusted), the new block size parameters are calculated.
The calculation determines the average (mean) size of the past 2016
blocks. This "average" size is then doubled (200%) and used as the
maximum block size for the subsequent 2016 blocks. At any point, if
the new maximum size is calculated to be below 1MB, 1MB is used
instead (which prevents regression from our current state).
Introduce a block minimum, the minimum will be 25% of the current
maximum, calculated at the same time (that is, every 2016 blocks, at
the same time the maximum is calculated). All blocks must be at least
this size in order to be valid, for blocks that do not have enough
transactions to meet the 25%, padding will be used. This devalues the
incentive to mine empty blocks in either an attempt to deflate the
block size, or to obtain a propagation advantage. Miners will be
incentivized to include transactions, as the block must meet the
minimum. This should ensure that even miners wishing to always mine
the minimum are still confirming Bitcoin transactions.
At the block in which this is introduced the maximum would stay at 1MB
for the subsequent 2016 blocks. With the minimum being enforced of 256KB
.
Example:
* Average Block Size for the last 2016 blocks: 724KB * New Maximum: 1448KB * New Minimum: 362KB 
Example: (Regression Prevention)
* Average Block Size for the last 2016 blocks: 250KB * New Maximum: 1MB * New Minimum: 256KB 
The Future:
I believe that the 1MB regression prevention might need to be changed
in the future, to prevent a large mining population from continually
deflating the block size (and keeping us at the 1MB limit).
For this, the hard limit could be changed in the future manually,
through a process similar to the current one, though hopefully with
far less urgency and hysteria.
Another option is to add an additional calculation, preventing the new
maximum from being lower than 75% of the current maximum. This would
substantially slow down a block-size deflation attack.
Example of Block-Size Deflation Attack Prevention:
This would provide a maximum growth of 200% per recalculation, but a
maximum shrinkage of 75%.
Request For Comments:
I'd love to hear your thoughts. Why wouldn't this work? What portion
is flawed? Will the miners support such a proposal? Would this even
solve the block size issue?
I will note that I don't find the 100% and 25% to be hard and fast in
my idea. Those we're just the values that initially jumped out at me.
I could easily see the minimum being anything below 50% (above 50% and
the network can never adjust to smaller block sizes). I could also see
the maximum being anything over 100%. Lastly, if a inflation attack
is a valid concern, a hard upper limit could be set (or the historical
32MB limit could remain).
I think the great part about this variable approach is that the
network can adjust to address spikes in volume and readjust once those
spikes dissipate.
Thanks!
Justin M. Wray
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJV4UXvAAoJENo/Q5Xwcn83ZWEP/iXAlNk5p9OlOPNSoHkECcxe
AcartxMLrmOvAZVudU4+239TEvwPydmYX/ptmBYgrvRJfm/TWmi0ZbTioxbxTIWM
IlNta1Y8IOHOEgBCtSW01j1PFHIzkBHQGIuqrKHhjcNVGbegXlPm3Da0gjNuTBIe
IV58gf1OfYK2XjuCMQMvo3VyXUKhqbOvBNnZXr+Qo2sAtanmxHQ+TU/gjA02L9LO
bb8WqQDj/veGnMexGh/X58tfQ5KCfLO401F7KnConDaFdKVDikp32zaSXZ7JWf/K
OeseHW1OHHVdYpHvh5VG5GLtYYB5rnq8g7B0/kyx5n4ldB6GkLxzH9CPB0vxpMnZ
dVCS/+EUe/wkHrpRVNhMwP8XfG+8gv9upKg6H/u39XmpL2H2G4cKeot5xRiWRNqY
oJclAeIhDTL1bx/9e/VqvM91ESWpBLs+O8Mh9OzgfbN3gKR6BuoWHNwM9jSMDAT1
YzwdneSvAEFzgELMlae2QIzAUHno9qkHMkDVbdY3bBtSM9Xz4ditGgnq1D40ZZ+J
zx5WVY7HCebgbk7T35xgKzSKQSEG9zFNW5Dvq66Se3Zpc5vCPw7Q2xwjjPz3zdXQ
Lub0ohVWTzKr05tN1e/nu6keiY5cXRZ0w2MtHb19jtdWyoHEWWHanfOZjgbVSsuA
saFCydA7O4E4BFxgtNze
=JthX
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010708.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.12.1 released | Wladimir J. van der Laan | Apr 15 2016

Wladimir J. van der Laan on Apr 15 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.12.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.12.1/
Or through bittorrent:
magnet:?xt=urn:btih:25c4df2a822e840e972a50a31095632d87efadab&dn;=bitcoin-core-0.12.1&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
This is a new minor version release, including the BIP9, BIP68 and BIP112
softfork, various bugfixes and updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to
https://bitcoincore.org/en/list/announcements/join/.
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrade warning

Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every
fresh sync or reindex, the chainstate is not backwards-compatible with
pre-0.12 versions of Bitcoin Core or other software.
If you want to downgrade after you have done a reindex with 0.12.0 or later,
you will need to reindex when you first start Bitcoin Core version 0.11 or
earlier.
Notable changes

First version bits BIP9 softfork deployment
This release includes a soft fork deployment to enforce BIP68,
BIP112 and BIP113 using the BIP9 deployment mechanism.
The deployment sets the block version number to 0x20000001 between
midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for
deployment. The version number consists of 0x20000000 to indicate version
bits together with setting bit 0 to indicate support for this combined
deployment, shown as "csv" in the getblockchaininfo RPC call.
For more information about the soft forking change, please see
https://github.com/bitcoin/bitcoin/pull/7648
This specific backport pull-request can be viewed at
https://github.com/bitcoin/bitcoin/pull/7543
BIP68 soft fork to enforce sequence locks for relative locktime
BIP68 introduces relative lock-time consensus-enforced semantics of
the sequence number field to enable a signed transaction input to remain
invalid for a defined period of time after confirmation of its corresponding
outpoint.
For more information about the implementation, see
https://github.com/bitcoin/bitcoin/pull/7184
BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY
BIP112 redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV)
for a new opcode in the Bitcoin scripting system that in combination with
BIP68 allows execution pathways of a script to be restricted based
on the age of the output being spent.
For more information about the implementation, see
https://github.com/bitcoin/bitcoin/pull/7524
BIP113 locktime enforcement soft fork
Bitcoin Core 0.11.2 previously introduced mempool-only locktime
enforcement using GetMedianTimePast(). This release seeks to
consensus enforce the rule.
Bitcoin transactions currently may specify a locktime indicating when
they may be added to a valid block. Current consensus rules require
that blocks have a block header time greater than the locktime specified
in any transaction in that block.
Miners get to choose what time they use for their header time, with the
consensus rule being that no node will accept a block whose time is more
than two hours in the future. This creates a incentive for miners to
set their header times to future values in order to include locktimed
transactions which weren't supposed to be included for up to two more
hours.
The consensus rules also specify that valid blocks may have a header
time greater than that of the median of the 11 previous blocks. This
GetMedianTimePast() time has a key feature we generally associate with
time: it can't go backwards.
BIP113 specifies a soft fork enforced in this release that
weakens this perverse incentive for individual miners to use a future
time by requiring that valid blocks have a computed GetMedianTimePast()
greater than the locktime specified in any transaction in that block.
Mempool inclusion rules currently require transactions to be valid for
immediate inclusion in a block in order to be accepted into the mempool.
This release begins applying the BIP113 rule to received transactions,
so transaction whose time is greater than the GetMedianTimePast() will
no longer be accepted into the mempool.
Implication for miners: you will begin rejecting transactions that
would not be valid under BIP113, which will prevent you from producing
invalid blocks when BIP113 is enforced on the network. Any
transactions which are valid under the current rules but not yet valid
under the BIP113 rules will either be mined by other miners or delayed
until they are valid under BIP113. Note, however, that time-based
locktime transactions are more or less unseen on the network currently.
Implication for users: GetMedianTimePast() always trails behind the
current time, so a transaction locktime set to the present time will be
rejected by nodes running this release until the median time moves
forward. To compensate, subtract one hour (3,600 seconds) from your
locktimes to allow those transactions to be included in mempools at
approximately the expected time.
For more information about the implementation, see
https://github.com/bitcoin/bitcoin/pull/6566
Miscellaneous
The p2p alert system is off by default. To turn on, use -alert with
startup configuration.
0.12.1 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

RPC and other APIs

  • - #7739 7ffc2bd Add abandoned status to listtransactions (jonasschnelli)

Block and transaction handling

  • - #7543 834aaef Backport BIP9, BIP68 and BIP112 with softfork (btcdrak)

P2P protocol and network code

    • #7804 90f1d24 Track block download times per individual block (sipa)
    • #7832 4c3a00d Reduce block timeout to 10 minutes (laanwj)

Validation

    • #7821 4226aac init: allow shutdown during 'Activating best chain...' (laanwj)
    • #7835 46898e7 Version 2 transactions remain non-standard until CSV activates (sdaftuar)

Build system

    • #7487 00d57b4 Workaround Travis-side CI issues (luke-jr)
    • #7606 a10da9a No need to set -L and --location for curl (MarcoFalke)
    • #7614 ca8f160 Add curl to packages (now needed for depends) (luke-jr)
    • #7776 a784675 Remove unnecessary executables from gitian release (laanwj)

Wallet

  • - #7715 19866c1 Fix calculation of balances and available coins. (morcos)

Miscellaneous

    • #7617 f04f4fd Fix markdown syntax and line terminate LogPrint (MarcoFalke)
    • #7747 4d035bc added depends cross compile info (accraze)
    • #7741 a0cea89 Mark p2p alert system as deprecated (btcdrak)
    • #7780 c5f94f6 Disable bad-chain alert (btcdrak)
Credits

Thanks to everyone who directly contributed to this release:
    • accraze
    • Alex Morcos
    • BtcDrak
    • Jonas Schnelli
    • Luke Dashjr
    • MarcoFalke
    • Mark Friedenbach
    • NicolasDorier
    • Pieter Wuille
    • Suhas Daftuar
    • Wladimir J. van der Laan
As well as everyone that helped translating on Transifex.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJXELrMAAoJEHSBCwEjRsmm75EH/0iyqFxXuJDbfzMmBbMTkXD2
/CXEeyMvs62F2ZeODE0SSqo9sXo4foiT9WI5Dq7BwAiF6jh/XE4QwBvc91BbPyGZ
1nOGEab+oe37xEOkn8MyGbHfCutsUldyKltVQjA3y685MxlSgTjl/nX6Pbpbxped
vZRog3KHRrpWAMrHdi6p/xgqX0ajxE6K1P16JMOx4W/gE9QgOPyy7+l/4WT6SyBj
k/pOLqJc+yQIOa9szS4pjLUqaSOirhsjXfro9FYjHqiTWQwAdvuK4xXgo1GrGIW1
PWs419uLmGl4bhg9jdY6v+PyPz4iUilRzoixVi8op1Rt9/AoNN1ViJ/LT15Hagw=
=h4Wp
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012607.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.13.1 released | Wladimir J. van der Laan | Oct 27 2016

Wladimir J. van der Laan on Oct 27 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.13.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.13.1/
Or through bittorrent:
magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn;=bitcoin-core-0.13.1&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
This is a new minor version release, including activation parameters for the
segwit softfork, various bugfixes and performance improvements, as well as
updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Microsoft ended support for Windows XP on April 8th, 2014,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is not clear
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes

Segregated witness soft fork
Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:
Activation for the segwit soft fork is being managed using BIP9
versionbits. Segwit's version bit is bit 1, and nodes will begin
tracking which blocks signal support for segwit at the beginning of the
first retarget period after segwit's start date of 15 November 2016. If
95% of blocks within a 2,016-block retarget period (about two weeks)
signal support for segwit, the soft fork will be locked in. After
another 2,016 blocks, segwit will activate.
For more information about segwit, please see...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Octobe013265.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin Core 0.12.0 release candidate 2 available | Wladimir J. van der Laan | Jan 25 2016

Wladimir J. van der Laan on Jan 25 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Binaries for bitcoin Core version 0.12.0rc2 are available from:
https://bitcoin.org/bin/bitcoin-core-0.12.0/test/ 
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.12.0rc2 
This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.
Preliminary release notes for the release can be found here:
https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md 
Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.
Diff since rc1:
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJWphBHAAoJEHSBCwEjRsmmh0EIALopACCwaCYRt9vl6fadDLxL
JMTyEPsGUaEX82iwuXeAhdReyvZDlC00ACZy6agp7oOuS1ryqOeYAsc33N+WtHE0
iETNyvRZVD1ASopHkdJrRW1a9X63Yvcvk/d6nVbO5auUAG5gPUFLrSTrqpSzR2D4
QtY1ofifXrYdqdQmPFJ5hnWg/Z1rko99sD8Pu3ebD6Dof5zuvJKHkLmXunGGXn/n
GOn8roS5LXEFHwCcL0zgNzfDywt/dhKiUHMKSNPsnz5qEDRg7WPzsNiQA/HVDlcp
v6akQ4ykZ56Lik8cVLi0NRW2dozSDti/XKBfWQHqWjGUJGUOS+lPJaWLv81oMwc=
=WlQm
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012275.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Hash Fucker X V1.0 By D3rkknight SHA-512 calculator How to calculate SHA-256 hash without any software? - YouTube What is a Bitcoin hash and SHA-256 - YouTube How to Calculate Mining Profits - YouTube

SHA512 hash calculator This utility computes the SHA512 hash for the provided text. SHA512 is a cryptographic hash function that when applied to the provided input results in a 128-digit hexadecimal number that is highly unlikely to match the value produced for a different input. the initial hash values h0 through h7 are given by the SHA-512/t IV generation function, the output is constructed by truncating the concatenation of h0 through h7 at t bits, t equal to 384 is not allowed, instead SHA-384 should be used as specified, and; t values 224 and 256 are especially mentioned as approved. The SHA-512/t IV generation function evaluates a modified SHA-512 on the ASCII ... For hash-with-RSA[padding] signature, the storage or transmission of the signature depends only on the key (modulus) and is unaffected by the hash. Compute-time may vary some, and for verifying (only) won't be rendered negligible by the modexp time, though as you note this difference could go either way. – dave_thompson_085 Oct 26 '19 at 1:44. add a comment 50. The only real advantage that ... Designed with by xiaoying riley for developers - Ein privates Projekt von Henrik Thesing, Zum Oberhof 52, 45307 Essen - 0179 / 4744112 - E-Mail - www.henrikthesing.de by xiaoying riley for developers - Ein privates Projekt von Henrik Thesing, Zum Oberhof 52, 45307 Essen - 0179 / 4744112 - E-Mail - www.henrikthesing.de My issue here is that the final output (base64 encoded) in php doesn't match my final output (also base64 encoded) in swift, but they do match if I use php hash() method with his third parameter set to false (not raw binary value).

[index] [44423] [12660] [8274] [23695] [47139] [46116] [28459] [50220] [37154] [28780]

Hash Fucker X V1.0 By D3rkknight

Java Tutorial - Hash functions (MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) - Duration: 12:33. Zoran Davidović 15,197 views Bitcoin 101 - Elliptic Curve Cryptography - Part 4 - Generating the Public Key ... 21. Cryptography: Hash Functions - Duration: 1:22:01. MIT OpenCourseWare 96,938 views. 1:22:01. Píldora ... This is Hack Jack. In this video you will know how to calculate SHA-256 hash, also about what is it and additionally how to by-pass evilzone.org register ver... Hash Fucker X V1.0 By D3rkknight Super Fast & Super HQ Best & Only True UnHashing Program Support All Hash Types(MD5,SHA1,SHA256,SHA512 ... Bitcoin Hash Calculator use to calculate the profitability of Bitcoin and the tool to find good return bitcoin miners to buy. You can easily calculate how many Bitcoins mines with your hash rates ...

#