SHA-512 Coins | CryptoRival

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]

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]

Bitcoin Core 0.11.0 released | Wladimir J. van der Laan | Jul 12 2015

Wladimir J. van der Laan on Jul 12 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.11.0 is now available from:
<https://bitcoin.org/bin/bitcoin-core-0.11.0/>
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
<https://github.com/bitcoin/bitcoin/issues>
The entire distribution is also available as torrent:
magnet:?xt=urn:btih:82f0d2fa100d6db8a8c1338768dcb9e4e524da13&dn;=bitcoin-core-0.11.0&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%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F 
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
Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.
Important information

Transaction flooding
At the time of this release, the P2P network is being flooded with low-fee
transactions. This causes a ballooning of the mempool size.
If this growth of the mempool causes problematic memory use on your node, it is
possible to change a few configuration options to work around this. The growth
of the mempool can be monitored with the RPC command getmempoolinfo.
One is to increase the minimum transaction relay fee minrelaytxfee, which
defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be
rejected, and thus fewer transactions entering the mempool.
The other is to restrict the relaying of free transactions with
limitfreerelay. This option sets the number of kB/minute at which
free transactions (with enough priority) will be accepted. It defaults to 15.
Reducing this number reduces the speed at which the mempool can grow due
to free transactions.
For example, add the following to bitcoin.conf:
minrelaytxfee=0.00005 limitfreerelay=5 
More robust solutions are being worked on for a follow-up release.
Notable changes

Block file pruning
This release supports running a fully validating node without maintaining a copy
of the raw block and undo data on disk. To recap, there are four types of data
related to the blockchain in the bitcoin system: the raw blocks as received over
the network (blk???.dat), the undo data (rev???.dat), the block index and the
UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once
it's been validated and used to build the databases. At that point, the raw data
is used only to relay blocks to other nodes, to handle reorganizations, to look
up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or
for rescanning the wallet. The block index continues to hold the metadata about
all blocks in the blockchain.
The user specifies how much space to allot for block & undo files. The minimum
allowed is 550MB. Note that this is in addition to whatever is required for the
block index and UTXO databases. The minimum was chosen so that Bitcoin Core will
be able to maintain at least 288 blocks on disk (two days worth of blocks at 10
minutes per block). In rare instances it is possible that the amount of space
used will exceed the pruning target in order to keep the required last 288
blocks on disk.
Block pruning works during initial sync in the same way as during steady state,
by deleting block files "as you go" whenever disk space is allocated. Thus, if
the user specifies 550MB, once that level is reached the program will begin
deleting the oldest block and undo files, while continuing to download the
blockchain.
For now, block pruning disables block relay. In the future, nodes with block
pruning will at a minimum relay "new" blocks, meaning blocks that extend their
active chain.
Block pruning is currently incompatible with running a wallet due to the fact
that block data is used for rescanning the wallet and importing keys or
addresses (which require a rescan.) However, running the wallet with block
pruning will be supported in the near future, subject to those limitations.
Block pruning is also incompatible with -txindex and will automatically disable
it.
Once you have pruned blocks, going back to unpruned state requires
re-downloading the entire blockchain. To do this, re-start the node with
  • -reindex. Note also that any problem that would cause a user to reindex (e.g.,
disk corruption) will cause a pruned node to redownload the entire blockchain.
Finally, note that when a pruned node reindexes, it will delete any blk???.dat
and rev???.dat files in the data directory prior to restarting the download.
To enable block pruning on the command line:
  • - -prune=N: where N is the number of MB to allot for raw block & undo data.
Modified RPC calls:
    • getblockchaininfo now includes whether we are in pruned mode or not.
    • getblock will check if the block's data has been pruned and if so, return an
error.
  • - getrawtransaction will no longer be able to locate a transaction that has a
UTXO but where its block file has been pruned.
Pruning is disabled by default.
Big endian support
Experimental support for big-endian CPU architectures was added in this
release. All little-endian specific code was replaced with endian-neutral
constructs. This has been tested on at least MIPS and PPC hosts. The build
system will automatically detect the endianness of the target.
Memory usage optimization
There have been many changes in this release to reduce the default memory usage
of a node, among which:
    • Accurate UTXO cache size accounting (#6102); this makes the option -dbcache
    precise where this grossly underestimated memory usage before
    • Reduce size of per-peer data structure (#6064 and others); this increases the
    number of connections that can be supported with the same amount of memory
    • Reduce the number of threads (#5964, #5679); lowers the amount of (esp.
    virtual) memory needed
Fee estimation changes
This release improves the algorithm used for fee estimation. Previously, -1
was returned when there was insufficient data to give an estimate. Now, -1
will also be returned when there is no fee or priority high enough for the
desired confirmation target. In those cases, it can help to ask for an estimate
for a higher target number of blocks. It is not uncommon for there to be no
fee or priority high enough to be reliably (85%) included in the next block and
for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.
Privacy: Disable wallet transaction broadcast
This release adds an option -walletbroadcast=0 to prevent automatic
transaction broadcast and rebroadcast (#5951). This option allows separating
transaction submission from the node functionality.
Making use of this, third-party scripts can be written to take care of
transaction (re)broadcast:
    • Send the transaction as normal, either through RPC or the GUI
    • Retrieve the transaction data through RPC using gettransaction (NOT
    getrawtransaction). The hex field of the result will contain the raw
    hexadecimal representation of the transaction
    • The transaction can then be broadcasted through arbitrary mechanisms
    supported by the script
One such application is selective Tor usage, where the node runs on the normal
internet but transactions are broadcasted over Tor.
For an example script see [bitcoin-submittx](https://github.com/laanwj/bitcoin-submittx).
Privacy: Stream isolation for Tor
This release adds functionality to create a new circuit for every peer
connection, when the software is used with Tor. The new option,
-proxyrandomize, is on by default.
...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009400.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]

BIP 151 use of HMAC_SHA512 | Rusty Russell | Jun 28 2016 /r/bitcoin_devlist

BIP 151 use of HMAC_SHA512 | Rusty Russell | Jun 28 2016 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

How big will blocks have to be when we all have to move our coins at once to SHA512 or some other form of Quantum Computing resistant setup? /r/Bitcoin

How big will blocks have to be when we all have to move our coins at once to SHA512 or some other form of Quantum Computing resistant setup? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

[HELP NEEDED] Conversion from 12-word mnemonic to Sha256

I have a 12-word mnemonic which needs encrypting into a sha256 code, I've started trying to do it myself by downloading pbkdf2 from python and following the advice given on https://github.com/bitcoin/bips/blob/mastebip-0039.mediawiki#From_mnemonic_to_seed. I am familiar with programming but have absolutely no knowledge in cryptography and so I have a few questions:
  1. Can I simply enter the 12 word mnemonic as a password into the pbkdf2 function?
  2. What exactly do I enter as the salt (github link says the string "mnemonic" and the pass phrase, does that mean a simply concatenation of the 12-word mnemonic and the aforementioned string?)
  3. How can I select HMAC-SHA512 as the pseudo random function in the pbkdf2 function?
  4. I am confused as to what to do once I get the binary seed from this function, how exactly do I proceed from there?
I'm sorry for the lengthy question and for being an absolute noob, but please if only part of this question could be answered I would be very grateful!
submitted by Hummusbabaganush to cryptography [link] [comments]

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add funcs.mk to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old Makefile.am's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [link] [comments]

Groestlcoin 6th Anniversary Release

Introduction

Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

Windows
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.
OSX
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), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).

Features

Download

Source

Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.

Features

Download

Windows
Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py 

Source

ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Trading Crypto with BitHash API

Trading Crypto with BitHash API
BitHash Exchange offers cryptocurrency trading through a set of APIs.

How to start trading with Crypto Trading API

  1. Sign Up or Login to your BitHash account.
  2. Go to API key management page. You will see allyour API keys there.
  3. If you don’t have any keys, click the Create New API Key button.
  4. Use the Key Public value as the key parameter.
  5. Use your API Secret yo sign request to the endpoint.

BitHash API

Security Notes

Private endpoints use HMAC SHA512 signatures.
Use your API Secret to generate a signed query string. Signed query string should not contain a sign parameter itself.
For endpoints without any parameters you should sign query:
key=API_KEY×tamp=TIMESTAMP
API_KEY — your public key found on the keys management page
TIMESTAMP — current timestamp in milliseconds
You can find full BitHash Trading API (v4) guide here:
https://support.bithash.net/hc/en-us/articles/360039964551-Private-API-v4-

About BitHash

BitHash Cryptocurrency Exchange was established in 2016 in Singapore with more than 100 pairs available for trading cryptocurrencyBitcoin (BTC), Ethereum (ETH), Litecoin (LTC), Bitcoin Cash (BCH), Ethereum Classic (ETC), Dash (DASH), EOS (EOS), Monero (XMR), Ripple (XRP), Zcash (ZEC).
BitHash Exchange is operated by PHOENIX TRADING SOLUTIONS LTD (“BitHash”), a company incorporated under the International Business Companies Act of 2016 of the Republic of Seychelles with company number 214028.
submitted by BitHashExchange to bithash [link] [comments]

Gauging interest: prepare a fork in case ABC and BTC-favouring miners enforce the protocol tax on BCH

Posting this to start a public discussion about the possible solutions for the current issue.
I think the proposed tax and the way this cabal tries to force their way is analogous to Blockstream hijacking BTC.
I believe that there is no place for a protocol level tax and centrally planned redistribution of blockrewards in an independent protocol.
BitcoinABC and a few BTC miners seem to ignore all industry feedback and backlash currently which is again eerily similar to the tactics of Blockstream (despite all the outcrys they prevented lifting the temporary capacity limit on BTC).
I think it's highly important to prepare the code and start to engage the major service providers.
My proposal is to switch the mining algorithm to a CPU or GPU based one preferably a cryptonight variant, SHA512 or randomx based algo.
Would there be interest in preparing this? What are you thoughts?
submitted by usrn to bitcoin_unlimited [link] [comments]

Are there two chain codes in BIP32?

Got a bit confused when reading the section on Mastering Bitcoin about child key derivations in HD wallets
This image and this other image shows the HMAC-SHA512 taking the same inputs but giving different outputs.
In both images the parent public key, the chain code and index number are fed into the HMAC-SHA512 but in the first image it outputs a child private key and in the second one a child public key.
This seems like a contradiction, can someone clear this up? Are there two different chain codes?
submitted by johnturtle to BitcoinBeginners [link] [comments]

AsicVault - Frequently Asked Questions

When was AsicVault established and how is it funded?
AsicVault was established 2016. It is funded by founders and corporate investors. Please see Crunchbase.

How can it be 1,000 times harder to crack compared to other BIP-39 hardware wallets?
BIP-39 hardware wallets are working on very low performance microcontrollers or secure elements. They are doing only 2,048 iterations of PBKDF2 SHA-512 that is even less than old NIST recommendation of 10,000 rounds from year 2016.
Performing higher number of PBKDF2 SHA-512 is standard practice for good security. iTunes does it, LastPass does it and Veracrypt as well. Even Ledger agrees that this very low number is the main problem of BIP-39.
AsicVault specially designed SHA-512 accelerator inside high performance secure chip is at least 340 times faster than common microcontrollers. The number of PBKDF2 SHA-512 rounds is set to be exactly 1,000 times higher than BIP-39, hence the cost to crack AsicVault is also 1,000 times bigger.
Please read in-depth teardown review and validation of AsicVault SHA-512 performance here.
You can perform independent analysis according to this PDF and our device performance is shown on this video.

Does it support BIP-39 passphrase?
Yes, AsicVault supports all standard BIP-39 seed words and additional passphrase (so-called 25th word). You can restore your HD wallet account created by other hardware wallets (Ledger, Trezor, Keepkey) without any additional steps. AsicVault always opens standard security BIP-39 account and high security BIP-39 accounts at the same time.

Why two processors?
Common design practice, also followed by Ledger, is to separate secure and non-secure code. Our advantage is that these two RISC-V processors are inside a single secure chip. This way the Security CPU has full access to the Application CPU RAM. This makes it possible to do proper secure boot.

Why RISC-V?
Open instruction set. Possibility to have open source CPU and extensions. We have already implemented several custom instructions.

Do I need a computer to initialize the device?
No. You can supply power from wall adapter or battery bank. AsicVault supports true air-gapped environment.
You can perform full device initialization, seed word generation and seed word backup without connection to the computer. You can also charge the device and check the status the same way.

Can I use USB extender cables?
Certified USB2.0 extender cables can be used. We don’t recommend extender cables while using USB3.1 features of the device. The device can detect (some) bad cables and show warning messages about them. It is not recommended to use cables/extenders longer than 2.5m. In any case, cables with lower AWG value are better, such as AWG20.

How hot does the device get?
During normal operation AsicVault device temperature reaches 35-37C. High speed USB3.0 operation adds additional 7C. AsicVault utilizes full Aluminum enclosure as an effective heatsink. Internal chips can tolerate up to +85C, so you never need to worry about them overheating. There are no Lithium batteries inside the device that are known for leaking and not tolerating high temperatures.

How long does the active anti-tamper system work?
Active anti-tamper protects your device at least 2 weeks, possibly up to 45 days, after you have fully charged the device. It takes just 15 minutes to charge the supercapacitors again. It is advisable to connect the device to a power source at least once per week. Different anti-tamper settings affect the anti-tamper aggressiveness, sensitivity and power consumption.
It is also good practice to enter your passphrase weekly so that you will not forget it.

How often can I charge it? Do the batteries age?
You can charge it as often as you like, several times per day. Supercapacitors can be charged 50,000 – 1,000,000 times during their lifetime compared to common Lithium batteries that only allow 500-1,000 times. Therefore even 10 times per day for 10 years should be fine. At least weekly charging is recommended for best anti-tamper protection.

How long are private keys safely stored inside device before the memory gets weak and they are lost?
Data retention time of Flash memory inside the main chip is 20 years. Additional encryption keys stored inside FRAM can last for 40 years at temperatures below 70C. These values are higher than the expected lifetime of the device. In any case you must make paper backup(s) of your seed words.

Can it store the whole Bitcoin blockchain inside the device?
No. The device is not designed to store large amounts of data. Internal 128-megabyte Flash is used to store applications. There are thousands of copies of the blockchain, storing yet another copy is not meaningful or necessary.

What is FIPS 140-2 highest Level 4?
FIPS 140-2 is Federal Information Processing Standard.
Level 4 requires that:
  1. physical security mechanisms provide a complete envelope of protection around the cryptographic module
  2. with the intent of detecting and responding to all unauthorized attempts at physical access
  3. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate deletion of all plaintext CSPs
  4. Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature
  5. A cryptographic module is required to include special environmental protection features designed to detect fluctuations and delete CSPs
We have used these guidelines while designing AsicVault. We meet and exceed the requirements in the following way:
  1. AsicVault has full Aluminium/Titanium enclosure that is not designed to be opened. Passive antitamper mesh protects the electronic circuits inside the device. Main secure chip also has chip level metal layer anti-tamper mesh.
  2. Active anti-tamper circuit monitors all intrusion attempts and performs immediate device zeroization upon detecting any such attempts.
  3. AsicVault has temperature, voltage and many other sensors that are continuously monitored by the anti-tamper circuit. Additionally, AsicVault has internal supercapacitor-based power reserve to run Elliptic Curve calculations and other cryptographic functions. Therefore, external voltage fluctuations can’t affect our device while performing these critical operations.
  4. Zeroization not only deletes the private keys, it also destroys internal hardware design making it impossible to perform any further analysis of the hardware.
AsicVault has not participated in formal Cryptographic Module Validation Program since we are not targeting US government users at this point.

Can AsicVault device run Linux?
It is not our priority to run Linux since it has too big overhead for hardware wallet. However, our RISC-V processors and Mark II hardware can run Linux for your custom projects.

Where can I purchase the device?
Please contact your local supplier about availability.
submitted by photonreality to AsicVaultOfficial [link] [comments]

Hashcat benchmark on GeForce NOW

OpenCL Platform #1: NVIDIA Corporation

* Device #1: Tesla P40, 6144/24576 MB allocatable, 30MCU

Benchmark relevant options:

* --optimized-kernel-enable

Hashmode: 0 - MD5

Speed.#1.........: 32855.6 MH/s (59.28ms) @ Accel:128 Loops:512 Thr:1024 Vec:4

Hashmode: 100 - SHA1

Speed.#1.........: 11339.3 MH/s (86.21ms) @ Accel:256 Loops:256 Thr:512 Vec:2

Hashmode: 1400 - SHA2-256

Speed.#1.........: 3956.8 MH/s (61.48ms) @ Accel:128 Loops:64 Thr:1024 Vec:1

Hashmode: 1700 - SHA2-512

Speed.#1.........: 1283.4 MH/s (59.73ms) @ Accel:128 Loops:32 Thr:640 Vec:1

Hashmode: 2500 - WPA-EAPOL-PBKDF2 (Iterations: 4096)

Speed.#1.........: 527.4 kH/s (56.26ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 1000 - NTLM

Speed.#1.........: 56126.1 MH/s (69.61ms) @ Accel:128 Loops:1024 Thr:1024 Vec:2

Hashmode: 3000 - LM

Speed.#1.........: 25822.0 MH/s (76.24ms) @ Accel:256 Loops:1024 Thr:256 Vec:1

Hashmode: 5500 - NetNTLMv1 / NetNTLMv1+ESS

Speed.#1.........: 27994.2 MH/s (69.78ms) @ Accel:128 Loops:512 Thr:1024 Vec:1

Hashmode: 5600 - NetNTLMv2

Speed.#1.........: 2342.5 MH/s (51.96ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 1500 - descrypt, DES (Unix), Traditional DES

Speed.#1.........: 1129.1 MH/s (54.79ms) @ Accel:8 Loops:1024 Thr:256 Vec:1

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)

Speed.#1.........: 9874.0 kH/s (74.72ms) @ Accel:1024 Loops:1000 Thr:32 Vec:1

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32)

Speed.#1.........: 18809 H/s (48.98ms) @ Accel:16 Loops:8 Thr:8 Vec:1

Hashmode: 1800 - sha512crypt $6$, SHA512 (Unix) (Iterations: 5000)

Speed.#1.........: 166.6 kH/s (72.22ms) @ Accel:512 Loops:128 Thr:32 Vec:1

Hashmode: 7500 - Kerberos 5 AS-REQ Pre-Auth etype 23

Speed.#1.........: 373.7 MH/s (83.17ms) @ Accel:256 Loops:64 Thr:64 Vec:1

Hashmode: 13100 - Kerberos 5 TGS-REP etype 23

Speed.#1.........: 373.9 MH/s (83.08ms) @ Accel:256 Loops:64 Thr:64 Vec:1

Hashmode: 15300 - DPAPI masterkey file v1 (Iterations: 23999)

Speed.#1.........: 88325 H/s (56.71ms) @ Accel:128 Loops:32 Thr:1024 Vec:1

Hashmode: 15900 - DPAPI masterkey file v2 (Iterations: 7999)

Speed.#1.........: 49797 H/s (78.09ms) @ Accel:256 Loops:128 Thr:32 Vec:1

Hashmode: 7100 - macOS v10.8+ (PBKDF2-SHA512) (Iterations: 35000)

Speed.#1.........: 16271 H/s (54.05ms) @ Accel:64 Loops:32 Thr:512 Vec:1

Hashmode: 11600 - 7-Zip (Iterations: 524288)

Speed.#1.........: 11789 H/s (59.33ms) @ Accel:128 Loops:128 Thr:768 Vec:1

Hashmode: 12500 - RAR3-hp (Iterations: 262144)

Speed.#1.........: 39596 H/s (72.02ms) @ Accel:4 Loops:16384 Thr:384 Vec:1

Hashmode: 13000 - RAR5 (Iterations: 32767)

Speed.#1.........: 43880 H/s (73.65ms) @ Accel:128 Loops:32 Thr:896 Vec:1

Hashmode: 6211 - TrueCrypt PBKDF2-HMAC-RIPEMD160 + XTS 512 bit (Iterations: 2000)

Speed.#1.........: 367.6 kH/s (82.29ms) @ Accel:64 Loops:32 Thr:1024 Vec:1

Hashmode: 13400 - KeePass 1 (AES/Twofish) and KeePass 2 (AES) (Iterations: 6000)

Speed.#1.........: 164.5 kH/s (62.68ms) @ Accel:512 Loops:128 Thr:32 Vec:1

Hashmode: 6800 - LastPass + LastPass sniffed (Iterations: 500)

Speed.#1.........: 2843.7 kH/s (59.11ms) @ Accel:64 Loops:62 Thr:896 Vec:1

Hashmode: 11300 - Bitcoin/Litecoin wallet.dat (Iterations: 199999)

Speed.#1.........: 5949 H/s (51.52ms) @ Accel:64 Loops:32 Thr:1024 Vec:1

Started: Tue Sep 03 08:29:05 2019
Stopped: Tue Sep 03 08:38:50 2019
submitted by KennyRX to hacking [link] [comments]

New game launch - “BLAST” !

We will soon release our new game Blast! To make this game provably fair, we announce our methods here.
A chain of 1 million SHA512 hashes was generated (starting with a server secret.)
The final hash is:
d3fc772bf79bf90f74c4cfe63b3534cd007f5956ec5d65a189475a3e5e3d7b635b4f0c86d2d69b67f46292f156bbef6f552c62c0e50710860b51854655235cb6
Bitsler will go through the hashes (in reverse order) and use each hash to determine the crash result. So the hash of our first game's hash is the same as our published final hash.
To ensure we didn't pick a hash chain that has some advantage for us, we will use a future bitcoin block hash as "client seed" to generate the final crash results. We will use the block hash of bitcoin block 608891 (around 4:30 AM GMT on Fri 20 Dec 2019.)
The code to generate each crash result is:
$hash = hash_hmac('sha512', $gameHash, $blockHash); $number = hexdec(substr($hash, 0, 13)); $multiplier = 98 / (1 - ($number / (pow(2,52)))); echo max(100, floor($multiplier)) / 100; 
This blog post will be shared on our social media channels and archived by several archive websites. Therefor we cannot edit the final hash (and therefor hash chain) nor the future bitcoin block number anymore. This makes our new game Blast completely provably fair.

Link list

submitted by BitslerCasino to u/BitslerCasino [link] [comments]

Do there exist any code implementations ECDSA with 512 bits of security?

Just how bitcoin uses the SECP256k1 elliptic curve to operate, and keys can be generated from a SHA256 hash, does there exist SECP512xx that could take in a SHA512 hash and have points on the elliptic curve that now have 2^256 times more security against a brute force attack?
submitted by bhag_v1 to crypto [link] [comments]

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]

What is Ravencoin?

Ravencoin is a digital peer to peer network that aims to implement a use case specific blockchain, designed to efficiently handle one specific function: the transfer of assets from one party to another. Built on a fork of the Bitcoin code, Ravencoin was launched January 3rd, 2018, and is a truly open source project (no ICO or masternodes). It focuses on building a useful technology, with a strong and growing community.

How Ravencoin works

A Ravencoin post on Medium from November 2017 references Game of Thrones when introducing this experimental currency:
“In the fictional world of Westeros, ravens are used as messengers who carry statements of truth. Ravencoin is a use case specific blockchain designed to carry statements of truth about who owns what assets”
Launched on January 3rd, 2018, the ninth anniversary of bitcoin’s launch, Ravencoin is an open-source project designed to enable instant payments to anyone around the world. The aim of the project is to create a blockchain optimized specifically for the transfer of assets such as tokens from one holder to another.
A fork of the bitcoin code, Ravencoin features four key changes:

This algorithm is intended to address the centralization of mining caused by ASIC hardware. In the X16R algorithm paper, the team behind the currency explains that the fixed order of ordinary hashing algorithms lends itself to the construction of ASIC miners.
However, the X16R algorithm aims to overcome this problem by constantly disrupting the ordering of the hashing algorithms – it uses the same algorithms used in X15 and SHA512, but the ordering of those algorithms is changed based on the hash of the previous block.

Unique characteristics of Ravencoin


submitted by Aolga1965 to u/Aolga1965 [link] [comments]

Bitcoin Cash is now fully supported by BitCloak mixer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm happy to announce that BitCloak mixer now also supports Bitcoin Cash. You can select Bitcoin Cash from the menu, or add /bch to the base url. It comes with all the usual mixer features, pgp-proof and api included. To prevent mistakes the bch version only accepts the new CashAddr format. Other updates: - - new domain added: https://bitcloak.ru/en - - api is now open to everybody, no more api keys needed. - - new section and api feature to check your mix status. Will continue to improve and update the service, BitCloak -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJa7cukXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDIwNUMxQTQ3QUQwNTA1MkFCQjQ1MTFF RkVGQjNGODg2RDM2MjQyAAoJEO/vs/iG02JCSq4QAMRNy4EhqDlwUkdiWCxubIkI SmPRWjm8z4schBqJahuLNoURJs/uU3fMZAznTu6Kj+3B0Cpm7n5A5EYmgjHBQqgi zu9iZAfZ1oJFewFgeusMf16IeVwiNH7lfK11r7KwxE68YEYTG/hRLntPoLseKf5e 31h2hvE5jr6+doEOHhlibPW1b8DI3IYy7Nm5Q4SwI8IanT8KIYQRJer+XAnv78K6 OuwAmaF/6nyV9Og4rfXs5KffTt7b6qJn6VnGlcbnTvSpW1l3q48EhWd8PAUB+I Y+7oBe6YnNtuVoQj6x8OU46xatn77EGlRDTuO1/hNLf82cc3uZiWg/YBV7afof9V k+MlWDfvjzcf0MirhWY4CGYsSP3lhcCL0rtI0nNc22lKbuWaZWd10hZehRUrVCMO 0vCqs/P5mbrPeIOVNEtOKBPKTsQYmfy9APnh3ld3j5E+B0J79fADmlF4hs4IX12d Pi3eQk0i7n8gcPwIrH83PxG1iPhNyDxUzoXdehu/S6+TaRQDFP1NvZSzCPMHnD2S 7q2TCWANrN7ZhXXbIbuMiij+Eq4UHylZNRO/MGzh+TPPyD/qJ9ZyvjOokAfnHQOY DiCwKZkK1BZOTGxUrWhKgF9Nes8i0A2NjeHWIhpx8LIz7XU4820p5y26VlaSO1s2 Lu8wk703x8Xzr8p5gNEK =SCz/ -----END PGP SIGNATURE----- 
submitted by BitCloak to btc [link] [comments]

Create unique bitcoin address per order without access to a private key?

I have a service for which I would like to use bitcoin payments. An item to be payed for is represented by a hash. I would like to generate the unique bitcoin address for the payment either on the client, or on a server with a "watch-only" wallet.
Is it possible to generate a bitcoin address from a public key+hash, such that later the the bitcoins are accessible with private key+hash?
To clarify, I think I should:
Is this possible? Is there already an address-generation scheme that allows this?
Note: I could use a single bitcoin address and put the order hash in OP_RETURN, but as I understand this is not currently supported by QR codes/bitcoin URIs.
submitted by tomtomtom7 to Bitcoin [link] [comments]

Hướng dẫn check md5 sha-1 sha-256 sha-512 SHA-256 The Center Of Bitcoin - Andreas M. Antonopoulos George Levy - What is a SHA-256 Cryptographic Hash Algorithm? SHA512 Encryptor How to crack MD5, SHA and BCRYPT passwords 2020

The SHA-2 family of cryptographic hash functions consists of six hash functions. These are: SHA-224, with 224 bit hash values; SHA-256, with 256 bit hash values SHA-512 is a function of cryptographic algorithm SHA-2, which is an evolution of famous SHA-1.. SHA-512 is very close to Sha-256 except that it used 1024 bits "blocks", and accept as input a 2^128 bits maximum length string. SHA-512 also has others algorithmic modifications in comparison with Sha-256. SHA-512 is the same as SHA-256, however, it is 50% faster and uses a 64-bit platform, rather than a 32-bit platform.It uses more memory and more power. Below is an example of SHA-256 and RIPEMD-160 being used to validate part of a Bitcoin/Bitcoin Cash transaction. Here we instantiate the WebAssembly versions of SHA-256 and RIPEMD-160, then we hash pubkey first with SHA-256, then with RIPEMD-160 to get the correct pubkey hash. Description: Part of the SHA-2 Group. The SHA2 group, especially SHA-512, is probably the most easily available highly secure hashing algorithms available.

[index] [13707] [8336] [2642] [19230] [1724] [6335] [1501] [18170] [13655] [6649]

Hướng dẫn check md5 sha-1 sha-256 sha-512

Get the Hash Cracker : http://w-coder.blogspot.com/2013/09/wccracker-v2-very-fast-and-powerful.html Visit my website for tutorials, tools, networking, make m... What the Hash? - How Bitcoin and Blockchains use Hash Functions - Duration: 5:55. Blockmatics 16,977 views. 5:55. SHA-256 The Center Of Bitcoin - Andreas M. Antonopoulos - Duration: 1:22:48. How to quickly verify MD5, SHA1 and SHA2 (SHA256, SHA384, SHA512) Checksums in Windows 8 and Windows 10 using Command Prompt Monetize your Clicks and Downloa... Andreas is the author of three books: “Mastering Bitcoin,” published by O’Reilly Media and considered the best technical guide to bitcoin, “Mastering Ethereum: Building Smart Contracts and ... What is SHA 256 - How sha256 algorithm works sha 256 bitcoin sha 256 blockchain sha2 in hindi - Duration: 10:28. Geeks Prix 4,305 views

Flag Counter