No it's not guaranteed— recently we've been talking some about removing this, reducing this, and will likely make it switchable. So far the initial commentary we've seen mostly appears to be people looking to use it abusively and in ways which will be detrimental to the Bitcoin currency.

No, withdraws are not happening.

MTGox has continually thorough the shutdown made a small number of what appear to be dust-cleanup transactions. Thats all these appear to be...

Ironically, someone of them like TXID: ed7ffa58fef651adaf1281ad10e98a4399eb2be40950345c7ccb7c8f76f067e1 in their liast are spending immature coinbases  (45d45286bac04311684ab7716ab170b50781cde6b094d9a644fb89ca07ae6888:31 is a coinbase with 67 confirms as I write this) and so it's not a valid transaction.  So even after all this time and weeks of outages for fixes MTGox is still producing invalid transactions.

The ntxid field is somewhat new, I first noticed it there a week-ish ago.

Thats nonsense, no one would run it regardless of what trumped up excuses were given.  And if you did— it would moot bitcoin, anyone who did run that would be stupid enough to deserve what they get.

BC.i knows the complete mapping of bitcoin addresses to accounts (and emails if provided).  With this information they technically have the capability to target specific users and replace their JS code at sign-on with new code that intercepts the private keys.  With the private keys in hand the coins could be diverted out of your control.

If you happen to not log in after such targeting begins and instead use an email backup of your wallet, then the only exposure is brute forcing the wallet encryption— though the encryption strengthening is not very strong, there are apparently GPU crackers that can test on the order of 1M keys per second, and most users are not capable of choosing keys which can withstand a strong attack (even— or especially— if they believe they are capable).

Hey, another ID could be useful to help with customer support—  really this is only because people are not using Bitcoin as intended: if all your withdraws were to unique scriptPubkeys then thats all the ID you need to know you've been paid.

Of course, there would be no reason to gate withdraws on being able to give people IDs to look up transactions:  For one, you could always have your own internal gox UUID (which they already issue) to list-of-txids. ... and even without _any_ improvements in that regard, an ID lookup is only relevant in some negligible number of odd transactions.  I'm pretty sure customers would understand "Withdraws are enabled and working fine, but if there is any issue with your transaction, you'll have to wait in a long support queue to get it sorted" and prefer that over the current situation.

What that additional ID has to do with the Bitcoin protocol I dunno— it would purely be a frontend feature, and it's not like bitcoin-qt is the most significant wallet frontend— esp since it doesn't normally index third party transactions at all. There is no place for something like that in the protocol itself, similar to how the protocol itself has no concept of addresses (only scriptpubkeys) or change.

There really was no premine and you can _trivially_ verify it for yourself. Please spend a few minutes actively investigating rather than believing charlatans on the forum, before wasting may more of ours.  This is the technical subforum, it's reasonable to expect you to be able to do a bit of your own homework.

There isn't currently a direct facility for it— because it's not generally something you're supposed to use.

OP_RETURN is like giving out clean needles to heroin addicts.  It's there as harm mitigation, but it isn't something thats generally good for the system.

When there is an actual application for using them in the software then that will be exposed— but just using it to cram data into transactions and externalize your storage costs onto the network? No.

... https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer

Correct, in fact because most pools charge a fee— and practically all except p2pool expose to to some risk of theft by the pool operator or to the pool being hacked— they reduce your income somewhat.

But they make payments more stable.  I strongly recommended p2pool— it eliminates the risk of theft and the centralization of network resources.  It doesn't provide as much variance reduction as other pools, though then again, if you're a very small miner you're not exactly counting on a payment every day to put food on the table.

Well, actually—

Zapwallet will fix these cases, in a kind of blunt way.

There is also a patch forthcoming that will release stuck coins (after, by default, something like 144 blocks).

The "free unit" (which is in a later patch) just brings the price to $7200/unit. People with December orders still paid $2400 more than January, which is a bit unfortunate.

Fwiw, CrazyRabbi  is a well known scammer on IRC who owes a lot of people a lot of Bitcoin: http://bitcoin-otc.com/viewratingdetail.php?nick=SupaDupaJenkins  I've suggested some of his creditors contact Bitmain and ask to receive those funds.

I'm hearing from friends with newbie accounts trying to conduct trades on here that the PM rate limiter is really annoying.

Maybe it would be good if every response someone sends you credits you with at least one free reply that doesn't count against the rate limiter?

They don't. Stock nodes will not relay these dust transactions.  Unfortunately, a lot of people have overridden the defaults, and the abuse we're currently seeing is the result.

If you're unhappy about it, go see what pools are mining them, and prod their hashing customers to ask their pools why they're mining abusive spam.

I dunno what to say but it's the right person.

I think you're misreading what was said there, I think he was referring to past work they've done, not the forum work.

Thats incorrect. They really are. Note the age of the account: I whitelisted it a while back for them on request.  It's the real deal.

FWIW, My unit works fantastically on P2Pool. I appear to get somewhat above the web ui reported rate, and the device has the lowest stale rate I've seen on any hardware device (0.23x of the Avalon batch 1's stale rate,  about 0.78x the bitmain antminer S1 which was the prior best I'd seen).

We already block most forms which can be blocked, this was a change in bitcoin 0.8 (that was, in fact, causing withdraws delays for mtgox because they produced transactions with invalid encoding).

The recent flood of transactions use a pushdata change. A patch to block it was written in September 2013, but didn't make it into the codebase until today. If your node is running git bitcoin, just update and you'll have it.

I ran mine for about a half hour on the lower PSU only (the other one doesn't power the internal controller) while I looked for an extension cord to reach another outlet on the other leg of my power.  Hashrate doubled after plugging it in, no fiddling or rebooting required.

What I did waste a bunch of time was on the fact that it's dhcp only, I was assuming it would have a default IP and wasted a long time looking.

Well constructed box... it's also AWESOME on p2pool, lowest stale rate I've seen from any mining hardware.

I'm a little concerned that some people might think using it makes reissued transactions safe— like apparently MtGOX does!— when it doesn't, you must double-spend for mutual exclusion safety.

But other than that, it sounded potentially useful to me.  Code at: https://github.com/sipa/bitcoin/commits/normtxid

I worry that if we don't use the Bitcoin transaction mechanisms for masking (as that patch does) it'll never get all the malleability right, but if we do people will have a hard time reimplementing in objective brainfuck correctly.

Probably beyond comment on that approach we need another implementation in not-C++ and do a test on the testnet and bitcoin blockchains and see that the implementations agree on all txn, then again with random fuzzing.