I haven't heard anyone mentioning what I speculate happened, so time to throw my voice into the crowd.

We have a situation where MtGox has without warning disabled bitcoin withdrawals, then a couple days later announce/accuse a hole that permitted someone from getting more bitcoins than they deserved.

Days later another popular "exchange" said they were affected by the same vulnerability and had their entire wallet stolen by the process.

MtGox states that they are in full compliance with Japanese law, which requires all exchanges to be fully solvent while they are running.

What I speculate may have happened is that MtGox's online wallet was completely drained by this exploit and that may have caused bitcoin withdrawals to end.  They may have been smart and had an offline wallet as well (so they aren't completely bled dry) however being a very popular exchange they likely lost a large chunk of their coins in the process and are now bitcoin-insolvent.  They are still operating within the law in this case because Japan doesn't know what bitcoins are yet and they are still fully fiat-solvent.

It also means that their goal would not be to attract more dollars, but try to find some place to get more coins from.  Metering bitcoin withdraws at the beginning would make sense (until they run dry).  I believe they're also scrambling over trying to improve their code to plug the hole, especially with feedback (in threads on this site) as to how low their server code quality is.

Are we saying something here that MtGox is not running with 100% reserves or something?

I'm more concerned with people saying here that there is only one address being used to store all the value, just one person stealing a single private key and all that would go poof...

You know, considering that one purpose of the coin drops is eventually to get to zero and have everything be running off of transaction fees, perhaps some adjustment to the transaction fees should be made near these jumps so as to get some (not all) of the lost-gen in as increased fees?  I know that I hate paying fees myself, but if a block only generates 0.1 BTC for whoever creates the block then we're not gonna see much difficulty by the time we get to that point.

Any drop in difficulty when we get to 25 BTC I don't see as that problematic, it's when we get to the lower levels that I'm more concerned about long-term damage.

If you have ProcessExplorer, maybe grab a stack trace and see where the request originated from?  Run Fiddler2 in MITM-attack mode and see what it's sending?

It's possible that it's not the official client technically making this connection anyhow, perhaps there is a DLL inside the process that is initiating this action.  Your anti-virus/anti-adware up to date?

Considering that thebitcoinsun.com (that is what you are talking about, right?) was first registered this last May, I'm not sure what the definition of "dead" would be (although I do expect the half-life of Bitcoin-related businesses to be quite short)

Perhaps it would be good for you to start your own news-related website and if it is good (and sticks around long enough) have the other papers merge with it?  The biggest issue I would see with this is the need for content over the long haul, if you can prove that you can have staying power above and beyond what you see elsewhere (I get my bitcoin news primarily from http://www.bitcoinwatch.com/ anyhow), then you may find the other papers you see no longer as relevant (or better still, competitors).

I'm seeing recent posts like this that seem to indicate that I can go as far as create my own transactions (and even gives a webpage where you can feed them back into the system without writing or interfacing with your own client)

I'm guessing that it would be rather difficult to get this to work with coins that you currently use with the official client?  Is there a way to get to the private keys without completely shutting down the client and writing a separate program to open up the keystore?

Not saying it isn't legit (and if the problems get too bad it can be disabled as mentioned above or we can use DHT or something) but I've seen a couple AUPs that explicitly mention IRC as something Not To Be Done.  Quick google search shows a thread from 2003 about a datacenter that banned it.

Get as mad as you want at this, a lot of people don't even know what TELNET is these days (recently went to a meeting where someone tried to explain the concept and how it differs from the web).

[Edit] Will "excessive twitter activity" be soon seen as suspicion of a botnet?  What about putting the two concepts together and getting a Bitcoin Twitter botnet?

I've been using the Bitcoin GUI for a little while and am feeling a bit like it is "trying to make things easy for me" a bit more than I would like.  One example is that I would like to consolidate the coins I have been mining over time.  I have already done a "payment to myself" using the client (unfortunately I have to go to blockexplorer to get any details about it other than the base value).  I'm just wondering how difficult it would be to do the following:

• Specify the coins (or at least the addresses) in the "in" side.  I have multiple addresses in my wallet with different histories and would like to avoid linking them in the same transaction if possible.
• A better description or control over transaction fees.  I've paid transaction fees before for a reason I didn't fully understand, best guess is that the client was prioritizing new coins over older ones for some reason (I've heard mention of smaller coins being used first, no matter their age).  This may be an extension of the first item, in the event that no aged coins are available (or transaction fees are suggested for other reasons) I'd like to declare a low-priority transaction that I don't really care whether it takes a few weeks to complete.
• Option to avoid "change".  This also extends from the first item (i.e. if you know/choose your coins you can just total them up), especially when consolidating I'm not really in the mood for creating a low-value coin whose only purpose is to be swept into the next consolidate action (where it likely is so small and fresh that it will force a transaction fee)

I think in the end this question is along the lines of "how can I use the tools out there to explicitly build a transaction, using my current wallet file and without the requirement that I have to manually calculate private key hashes?"

I have expect this to end up being a "RTFM".  I am seeing the CLI for the bitcoin client, which does move forward a little bit, the <from-address> isn't available in the GUI for instance.

Also, (reading the same webpage I saw the OP_FALSE on) I do see that a number of commands were disabled "for security reasons", so there already are plenty of eyes ensuring that malicious scripts can't crash the blockchain.  The disabled commands are described as: 4 commands to split or combine strings, 4 bitwise operations, and 7 commands that multiply or divide numbers.

The descriptions of the opcodes also describe this as a push-zero (alias OP_FALSE) rather than push-nothing (there are already 11 NOP opcodes, why do we need another?)

This script appears to me to be potentially solvable if OP_0 is a NOP, unsolvable otherwise.  However it does feel to me like interpreting it as push-zero makes a lot more sense.

I do recognize that this opcode is unlikely to have been used anywhere, but any use of it (or any successful claim of these coins) would make it impossible to make some kind of change here without causing a netsplit.

I recognize that I've probably gone badly off-topic with respect to this topic title now...

Just a quick observation, Bitcoin is an experimental alternative "currency".  The "experimental" part of it means that people can tinker around with it or (since the whole point of BitCoin is that all the rules are baked in at the start, of course with exceptions) branch off different alt chains to see if there could be an incremental improvements that can be made.  The fact that the alternatives appear to be inferior to BitCoin (so far) speaks incredibly highly to how well the original design was thought out.

I recognize that as soon as Real Money is involved that "experimental" tag tries to get removed rather quickly (after which people start getting jealous of any alternatives, remember that fiat currencies behave the same manner) but as long as things don't get out of hand I welcome experimentation on incremental improvements to what was a surprisingly strong design.

I hope I'm not over-posting here, but as long as you're trying to clarify things.  BlockExplorer currently describes this as "OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG".

With your explanation here, (assuming the "0" is "OP_0") the "0" sounds like it might be a bit... confusing.

Also, with OP_0 being an effective no-op (rather than push-zero), the datatype checking method I was mentioning prob wouldn't have done anything useful here (I doubt you're much surprised).  I'm also marking this back down from "structurally impossible" to "very improbable", there *may* be a path to claim, but it wouldn't be worth the effort to discover.

If SolidCoin had come first then we wouldn't have had this decision at all, it wouldn't have gotten the kind of mindshare that BitCoin got at all.  It may have gotten popular for a little while, but probably would have quickly gotten in trouble and faded.  In many ways it's riding the coattails of BitCoin, trying to say "we're like BitCoin, only better!".

And if you haven't heard of SolidCoin, about half the threads in alt coin have been talking about it, I think it's been the favored piniata in these forums.  A couple "run away! run away!" threads have appeared in this forum as well.

As far as I know the only purpose of "activation" is to prevent fraud.  Otherwise the cards would be active as soon as they were swiped through the register.

Considering how few "strange scripts" there are on blockexplorer (although it's not reporting any more with the huge flood from this one block), I'd say that the moment you start writing your own scripts or not just copy/pasting the two scripts that are used everywhere you are pretty much running without a safety net.

I'm not quite sure I understand where the "polynomial time" came from, although there's a strong whiff of Gödel in that statement.  While I recognize that we cannot prove absolute correctness we can at least do some structural sanity checks, assuming there is an indeterminate number of items of arbitrary type on top of the stack or something.  Heck, Java does a heck of a lot heavier check than this when loading code.  And I don't see how this would change Bitcoin at all, or eliminate any possible "strange scripts" people could come up with.

I don't really understand the "minor is not the gatekeeper of transactions" thingy either.  What prevents double-spend transactions from entering the blockchain?  I'm assuming that anyone can broadcast anything they want almost by definition (i.e. we have to accept that badly-performing clients exist).  Either the miner has to block malicious transactions or we have to ignore malicious transactions that are already in the block chain.  I recognize that misformed scripts are nowhere near "malicious", but the same rules could apply here.  We don't need 100% buy-in by miners either, this doesn't really change Bitcoin, miners already are permitted to accept all or none of the transactions at their discretion.

I realize that I'm entering a very intense firestorm with this opinion and would probably immediately be declared too inexperienced and/or wrong

If this is a case of "bad datatype" then rather than just "extremely unlikely success" then it seems like it could be mechanically verified as impossible to complete.  I know there are an infinite number of possible transaction scripts, but they should be able to match parameters to function calls and do basic type checking...

[EDIT] Also, we can still potentially "make democracy work" and void this transaction at any point.  It does require >90% buy-in though (i.e. for everyone to adopt a client with modified rules).  Of course, another "good luck" on getting that to happen without a *REALLY* good reason...

I'm not sure I'm convinced that these coins are "unspendable".

Wouldn't this just be an extremely-high-difficulty problem to solve?

Anyone wanna guess how many Thash it would take to get an address that hashes to zero?

I think you may have gotten people nervous when stating that you were having difficulty getting past an anti-fraud protection system.  Asking a random person to pose as you in unlocking a card using a method that records the phone number the call originated from (in a forum where people have seriously proposed methods previously used by the mafia to launder money) is likely to raise more than a couple eyebrows, even if no one can figure out what is precisely wrong with what you're proposing.

With the reputation that IRC in general has gotten over the years, I wouldn't be surprised if any IRC-like communication is declared malicious...