Bitcoin Forum
January 20, 2019, 12:19:57 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 »
101  Bitcoin / Bitcoin Technical Support / MOVED: Help transaction not confirmed 24hrs from!! on: May 05, 2017, 03:25:41 AM
This topic has been moved to Trashcan.

Duplicate topic
102  Bitcoin / Development & Technical Discussion / MOVED: where is coinbase parameter in breadwallet open source ios version? on: April 28, 2017, 01:04:53 PM
This topic has been moved to Trashcan.

103  Bitcoin / Bitcoin Discussion / Antbleed: A remote shutdown backdoor in antminers on: April 26, 2017, 09:22:30 PM
Antbleed is a backdoor introduced by Bitmain into the firmware of their bitcoin mining hardware Antminer.

The firmware checks-in with a central service randomly every 1 to 11 minutes. Each check-in transmits the Antminer serial number, MAC address and IP address. Bitmain can use this check-in data to cross check against customer sales and delivery records making it personally identifiable. The remote service can then return "false" which will stop the miner from mining.

Read for more info

The shutdown backdoor has been independently tested by multiple people.


I have analyzed the code and I have determined how this is happening and most likely why it was put there.
First, let's start with the how. The firmware will spawn a thread which calls the send_mac function which, as the name implies, sends data about the machine to the AUTH_URL The device then will attempt to receive data from the server and check if the response is false. If it is, the function returns true which sets the stop_mining global variable to be true.

When that variable is true, in the temperature checking thread, it will set the status_error global variable to true. That will then tell the work update function to not send out jobs so it is no longer mining.

Now for the why.

Bitmain previously was going to launch a service called Minerlink. This service never launched, but it was intended get the "real-time miner status remotely". There is probably a feature that allows you to make sure that the only miners submitting work for you are your miners, hence the need for an auth url. It is also possible that another feature was to allow you to remotely stop a machine from mining if it were misbehaving. This would explain why this code was put there in the first place. However, since minerlink does not exist, this functionality is now a liability and should have been removed long ago.
104  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.14.1 Released on: April 22, 2017, 01:45:29 PM
Bitcoin Core version 0.14.1 is now available from:

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:

To receive security and update notifications, please subscribe to:


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.


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:

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)
  • #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)
  • #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 test (sdaftuar)
  • #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)

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.
105  Bitcoin / Development & Technical Discussion / MOVED: Latest dependencies for compiling on: April 20, 2017, 02:53:16 AM
This topic has been moved to Trashcan.

Duplicate topic
106  Bitcoin / Development & Technical Discussion / MOVED: Core Team has been bought by banks! (repost, they deleted it) on: April 19, 2017, 06:33:02 PM
This topic has been moved to Trashcan.

Duplicate. Your original thread was moved to Bitcoin discussion:
107  Bitcoin / Bitcoin Technical Support / MOVED: How im can modify my Sapphire nitro RX480 4GB to to reach 30-31 mh / s ?? on: April 12, 2017, 03:07:02 AM
This topic has been moved to Trashcan.

108  Bitcoin / Bitcoin Technical Support / MOVED: Delete Private Keys on: April 06, 2017, 12:57:05 PM
This topic has been moved to Trashcan.

Duplicate thread
109  Bitcoin / Development & Technical Discussion / MOVED: Elastic Securities: a regenerative supply measurement of encrypted currencies on: April 05, 2017, 09:27:16 PM
This topic has been moved to Trashcan.

Duplicate. Wrong forum anyways.
110  Bitcoin / Bitcoin Technical Support / MOVED: i cant seem to set my gridseed bitcoin miner up at all on: April 03, 2017, 09:23:21 PM
This topic has been moved to Trashcan.

Duplicate thread. Original here:
111  Bitcoin / Bitcoin Technical Support / MOVED: cant unlock my funds when i lost my password but have my seed on: April 02, 2017, 07:51:52 PM
This topic has been moved to Trashcan.

112  Bitcoin / Armory / Armory's position on hard forks on: March 28, 2017, 07:56:28 PM
Today we published a post on the Armory website outlining Armory's position on hard forks and what to do if BU forks. You can read the full post here:
113  Bitcoin / Armory / Fixing the "transaction timed out"/"transaction broadcast failed" issue on: March 28, 2017, 07:52:10 PM
Update: 0.96.0 has been released. Update to that if you are still experiencing this problem.

Many of you may have noticed that with the Armory 0.95.1 and Bitcoin Core 0.14.0, Armory tends to fail to broadcast transactions and give the "Transaction timed out" and "Transaction broadcast failed" error messages.

The underlying issue that is causing this problem has been fixed for Armory 0.96, which will be released soon. However, in the meantime, downgrading to Bitcoin Core 0.13.2 will fix the issue. Once 0.96 is released, you will be able to use Bitcoin Core 0.14.0 again.

To downgrade to Bitcoin Core 0.13.2, just download the Bitcoin Core 0.13.2 binaries from and install them as you would normally install a new version of Bitcoin Core. There is no need to redownload the blockchain nor reindex Bitcoin Core's databases nor rebuild Armory's databases.

Now for the technical details about the problem, for those of you who care.

I first noticed this issue back in December, but only very recently have I nailed down why this problem cropped up in the first place.

Bitcoin Core 0.14.0 merged a change back in December which changed how Bitcoin P2P messages were being broadcast. Previously, the p2p message header and the message payload were sent all at the same time using the same kernel call. However, during their net refactor and cleanup, this mechanism was changed to send the message header in one call, and then the payload in a separate call. This is more robust and allows for better code separation, but it also causes problems for Armory.

The implementation in Armory 0.95.1 for receiving the p2p messages is not able to handle that the two parts of a p2p message are essentially sent separately. It interprets the message header as one p2p message, and the message payload as another p2p message. This means that it is incorrectly parsing the messages. The crux of the issue is that every so often Armory will receive a ping message from Bitcoin Core. However the payload of the ping message is only 8 bytes, but the message header must be 24 bytes. When Armory interprets the ping payload as a separate message, it will throw an exception because it thinks the message is too short. This exception causes the data processing thread to exit and disconnect from Bitcoin Core. Once it disconnects, it will typically reconnect, but the reconnect does not always mean that it will actually be receiving new blocks and transactions and actually remaining up-to-date with the blockchain. Thus, because of this disconnect, when you go to send some Bitcoin, it will fail to either connect to Bitcoin Core or the reconnected connection is messed up and the transaction broadcast times out or just fails entirely.
114  Bitcoin / Alternative clients / MOVED: Can someone tell me where i find my private key in Bither? on: March 28, 2017, 02:26:40 PM
This topic has been moved to Trashcan.

115  Bitcoin / Development & Technical Discussion / MOVED: Distribution on: March 27, 2017, 12:51:26 AM
This topic has been moved to Trashcan.

116  Bitcoin / Development & Technical Discussion / MOVED: You can now permanently sign, store and verify any file in less than 30 seconds! on: March 25, 2017, 07:19:52 PM
This topic has been moved to Trashcan.

Duplicate topic
117  Bitcoin / Bitcoin Technical Support / MOVED: Transaction stuck? on: March 23, 2017, 05:01:14 AM
This topic has been moved to Trashcan.

Duplicate of
118  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:22:28 AM
This topic has been moved to Trashcan.

Duplicate of
119  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:17:33 AM
This topic has been moved to Trashcan.

Duplicate of
120  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:17:24 AM
This topic has been moved to Trashcan.

Duplicate of
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!