Another way to look at this is that Kano deserves kudos for manually pushing out those last payments to our core wallets. Had they waited for the usual block confirmation cycle, you'd be getting them post-fork and you'd only have them on your BTC chain.
The Coinbase transaction stoppage is only for a few hours. Supposed to be 4 to be exact. Ya know, Coinbase covers all this in their UAHF/UASF FAQ and that is better info than people just guessing about it.
In short they will temporarily suspend withdrawals, purchases, and exchanges -- nothing said about not accepting direct BTC deposits to wallets.
On a related off-topic note, Bitmain is also suspending BTC as payment. Received this in an e-mail from them today:
Quote
We will stop accepting any Bitcoin payments from 8 AM on 31 July 2017 to 8 AM on 3 August 2017 (GMT+8). If we receive any Bitcoin payments during this period, we will not be able to confirm receipt of the payment until the end of this period. Although we plan to re-open Bitcoin payments after 8 AM on 3 August 2017 (GMT+8), please wait for our confirmation message before sending any Bitcoin payments to us.
Found an interesting address ... looks like someone has been giving away $2.5million over the last 2.5 months. https[Suspicious link removed]x9KyM1jUhDnK2W
They seem to like sending lots of single transactions to a set of addresses with the same first character ... very unusual Some of it landed in the pool address just now.
Odd indeed.
Stranger now with the addition of the self-referencing link to this thread in the above-referenced address' referenced (mentioned) links. (Click on the link that Kano provided - this discussion is in the "Mentioned" list now.)
... to send them to my bitcoin node I have on a headless linux box.
The two "do-it-yourself" ways would be
to try to issue abandontransaction "txid" in the command console of your core. I've had limited success with that.
restart core with "-zapwallettxes=2, which will give you back control of the unconfirmed funds - just know that the unconfirmed transaction still exists. The goal now is to usurp the unconfirmed transaction and respend the same funds with adequate transaction fees. The "second" spending of the funds will get confirmed, causing the network to mark your original transaction as an invalid double-spend.
More details can be acquired by googling the core commands given above. If you're adventurous, add "rawtx" and "sendrawtransaction" to the search terms for the do-it-yourself transaction accelerator.
...does any one have any idea what the heck could of caused one of the ribbon cables going to one of the hash boards on one of my 9s to be all melted and burned?