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:
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.
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?
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
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
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
- #10410 321419b Fix importwallet edge case rescan bug (ryanofsky)
P2P protocol and network code
#10424 37a8fc5 Populate services in GetLocalAddress (morcos)
#10441 9e3ad50 Only enforce expected services for half of outgoing connections (theuni)
#10414 ffb0c4b miniupnpc 2.0.20170509 (fanquake)
#10228 ae479bc Regenerate bitcoin-config.h as necessary (theuni)
#10245 44a17f2 Minor fix in build documentation for FreeBSD 11 (shigeya)
#10215 0aee4a1 Check interruptNet during dnsseed lookups (TheBlueMatt)
- #10231 1e936d7 Reduce a significant cs_main lock freeze (jonasschnelli)
- #10294 1847642 Unset change position when there is no change (instagibbs)
Credits Thanks to everyone who directly contributed to this release:
Wladimir J. van der Laan
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
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:
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
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
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
The first positional argument of createrawtransaction was renamed from
transactions to inputs.
The argument of disconnectnode was renamed from node to address.
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)
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.
From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
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.
#9293 e591c10 [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
#9053 5b93eee IBD using chainwork instead of height and not using header timestamps (gmaxwell)
RPC and other APIs
#8845 1d048b9 Don't return the address of a P2SH of a P2SH (jnewbery)
#9041 87fbced keypoololdest denote Unix epoch, not GMT (s-matthew-english)
#9122 f82c81b fix getnettotals RPC description about timemillis (visvirial)
#9042 5bcb05d [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
#9194 f26dab7 Add option to return non-segwit serialization via rpc (instagibbs)
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:
Average Block Size for the last 2016 blocks: 4MB
New Maximum: 8MB
New Minimum: 2MB
Average Block Size for the last 2016 blocks: 2MB
New Maximum: 6MB (2 * 200% = 4, 4< 75% of 8, So use 8 * .75 = 6)
New Minimum: 1.5MB
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
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)
#7821 4226aac init: allow shutdown during 'Activating best chain...' (laanwj)
#7835 46898e7 Version 2 transactions remain non-standard until CSV activates (sdaftuar)
#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)
- #7715 19866c1 Fix calculation of balances and available coins. (morcos)
#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:
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
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.
From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
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:
Elimination of unwanted transaction malleability: Segregating the witness
allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.
Capacity increase: Segwit transactions contain new fields that are not
part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size. Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).
Weighting data based on how it affects node performance: Some parts of
each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain. One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different "weight" to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.
Signature covers value: A simple improvement in the way signatures are
generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed. For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.
Linear scaling of sighash operations: In 2015 a block was produced that
required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can't be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature method that doesn't suffer from this problem and doesn't have any unwanted side-effects.
Increased security for multisig: Bitcoin addresses (both P2PKH addresses
that start with a '1' and P2SH addresses that start with a '3') use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security---which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address. Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin's choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)
More efficient almost-full-node security Satoshi Nakamoto's original
Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto's method can't guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin's current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes. Although the problems with Nakamoto's method can't be fixed in a soft fork, Segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.
Script versioning: Segwit makes it easy for future soft forks to allow
Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.
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
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).
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 ...