FPGAs are really nifty.  They can do all sorts of things.

The problem is that FPGA mining rigs use boards very few I/O lines, which means that if you want to reprogram the chip for a new life, you have to desolder and re-ball the package for almost any other application.  Still, there are plenty of people that can deal with BGA rework that salvage these things, and they are damn expensive new, so there is a thriving market for used ICs of all sorts.

*snip*

Heh.  You seem to be doing fine at that all on your own.

I'm going to mark today on my calendar.  I've seen your picture around the internet for years.  Never thought I'd actually meet you.

(paper)Gold and (paper)Silver are even worse than dollars.  You want physical, but you want to pay paper prices for it, or your books won't come out right.  Good luck doing that in enough volume for people to notice.

In practice, nations maintain national currencies primarily so that they can inflate their debts away, and secondarily so that their bankers can "tweak" the money supply to suit their imagined needs.

They rarely give up that power willingly.  A bunch of nations did that not too long ago because they were convinced that switching to the Euro would have benefits in excess of the price they were paying.  Their project does not appear to be working out the way they hoped it would.

Eventually though, bitcoin, or something very much like bitcoin, will rise up.  People will use bitcoin despite the special legal protections that governments grant to their own currencies, and governments will lose their powers of inflation and meddling, either by choice, or by starvation.

If I were a betting man, I'd bet that bitcoin (or something) will become the world's currency before it becomes any government's currency.  It is a very interesting time to be alive.

If the trillion dollar coin had come out as a surprise, it might have caused a bit of a panic.  Not that I think it even remotely likely to happen, but you know, if.

On the other hand, now that the story has made the rounds, everyone knows that raising the debt limit and striking the coin are effectively the same thing.  At worst, we'd all give a chuckle at them replacing one silly gimmick with another while the blogs that have been predicting armageddon since 1972 will continue to do so either way.

The truth is that these guys aren't idiots.  They know exactly what they are doing.  There was a crash coming, and they are trying to make it as soft of a crash as possible.  And the rest of the world is helping.  There is no panic dollar dumping, as bad as it is, because everything that you could dump your dollars for is worse.

PM sent.

Cool.  How do I go about proving my info to you?

Why would anyone need the key itself?  All of the information needed to make copies of that key is right there in the picture. 

I emailed about this a few weeks ago, and sent a PM on these forums yesterday, but haven't heard a response yet.  I figure you are busy and my messages may be lost in the flow, so I'll ask here where it is less likely to get lost.

I have an account on MPEX, and absolutely no interest in signing up for any of these new exchanges.  Can I get shares from my GLBSE claim transferred directly to my MPEX account?

Most people don't have to worry about getting too many addresses in their wallet.  There is no number that is "too many", because it depends on your computer.

Basically, for each transactions that comes in (whether by protocol or by block), your node needs to compare the inputs and outputs with all of your keys, looking for matches.  The good news is that modern computers are pretty fast.  The better news is that we can probably switch to bloom filters or something similar if it gets to be a widespread problem in the future.

People usually only get this problem if they accept tons and tons of incoming payments, like mtgox or other big names, and they understand that they have to find their own solution (for now).

As to your first question about the transaction tracking, looking backward is the only way to find out where coins were in the past, and what you are doing is about the best you can do.  There are no features in the system to make this step easier, because it is dangerous, not useful.  If you want to follow transactions around the network as an academic or intellectual exercise, feel free.  But please be careful that you do not delude yourself into thinking that you have found "the sender", as the concept does not exist in bitcoin.  If you need to collect state information about an incoming transaction, you must collect that information in advance and associate it with the payment address that you provide.

Ugh.  Lousy situation.  My opinions...

If there are dividends that have been deferred because of the chaos left in the wake of GLBSE's closure, or if new dividends come in before the asset transfer, those dividends are owned by the company (shareholders), not by the winner of the auction.  Effort should be made to secure those payments prior to the auction.  If this isn't possible and the dividends can only be paid to the winning bidder, I don't see what else can be done but to note it with the asset and let the potential buyers bid accordingly.

In the case of a debt repayment or a share buyout/buyback, it would depend a bit.  In the real world, there would be a court, and the court would not allow such an attempt unless the price met or exceeded the auction price (which would mean a temporary injunction, etc, etc).  In this case, I doubt that anyone has the power to place such a hold on things.  To the extent possible, usagi should consider those to be bids like all others, when he has the ability to refuse them.  Since he usually won't be able to refuse, not much can be done except add a clause to the auction agreement that he may need to involuntarily cancel some items.

P.S.  Glad to see that this is winding down nicely.

The hilarious thing is that for years, tons of blogs and commentators have been using terms very much like "fiscal cliff" to mean the whole stupid debt/entitlement situation that we've gotten ourselves into over the last 20/50/100 years.  I don't feel like digging through archives tonight, but I'd be totally amazed if there weren't thousands of uses of that exact phrase to be found in old posts from the last 5-10 years.

When I started hearing the term from ordinary folks, I nearly cried with joy, thinking that the idea had finally crept into mainstream consciousness.

Nope.  Just like "tea party", the media took a term in common internet usage and made it into something totally different overnight.  Fuck you, media!

I would absolutely recommend against forking openssl, for reasons that jgarzik gave, and more.  If a day ever comes when we must, then we must.  Until then, just because we can does not mean that we should.

So, how many more major developers need to show up here to explain that a spec would be 1) not very useful, and/or 2) actually dangerous, before you believe it?

There are nodes that intentionally relay non-standard transactions, and there are miners that intentionally mine them.  But most nodes won't relay them, and most miners won't include them.

It depends what you mean by "work".  I haven't read your script in detail, but I'm willing to take it on faith that it is capable of finding one or all of the pubkeys that previously controlled one or all of the inputs of the transaction that was sent.  In that sense, it can probably "work".

On the other hand, no one cares about that.  They want a return address where winnings or refunds can be sent.  And the bitcoin system has no concept for that.  Transactions do not identify people or entities, only keys.  And keys do not identify people or entities either.  In this sense, this won't "work" when the bitcoin-qt that the payment is sent from is not owned by the person nominally making the payment, for example if I make the payment for someone else.

Each block is allowed a single transaction without an input, which the miner normally directs to a key they know, effectively their reward for finding that block.  The size of that magic transaction is limited to not more than the sum of the fees (which are just the differences between the outputs and inputs of each individual transaction) plus the subsidy.

Ok, let me say this plain and clear, for the thousandth time:

There is no FROM address in the bitcoin system.  You are asking a question that is without meaning in the system.  The software you are writing will not do what you think it does, even if it appears to work more-or-less correctly most of the time.

I'm not talking about the protocol, I'm talking about accounting systems that also use 64 bit computers, and thus typically use 64 bit values.  You don't design an accounting package based on the money supply, you give it headroom.

Right now, bitcoins are worth about $13.50 each, and there will never be more than 21 million of them.  If we were using a scaling factor such that the entire 64 bit range was needed to exactly represent the fundamental units, we would need a 128-bit accounting package to deal with projects bigger than, say, a medium-sized office buildings.

That example is just a snapshot, of course.  In the past, 64 bits wasn't enough to feed a family of four, but in the future, it may very well be able to handle all global economic activity for a year.  The point is that having some room between the maximum number of currency units, and the maximum range of the native register size of common CPUs isn't a bad thing.

Well, in ordinary "pay to pubkeyhash (address)" transactions, the script is written by the sender.  But your client doesn't think that it is a payment to your wallet unless it is written in a very specific way.  If it isn't OP_DUP OP_HASH160 {your key} OP_EQUALVERIFY OP_CHECKSIG, then it isn't really "to" your address, and your node will ignore it.  Maybe you can redeem it with your key, or maybe not.  If a sender points to some gibberish transaction and claims that it is valid, the alarm bells in your head should be going off.

In P2SH, you create the script yourself, and hash the entire script, including any and all pubkeys needed to redeem it.  If you do that, when you see a transaction to the P2SH address (which is an encoding of that hash), you can spend it as usual.  If someone else gives you a P2SH address, and claims that it is for you, then again, alarm bells.

Things can get murkier in multi-sig transactions, but you aren't going to stumble into that situation by accident, you'll get there because of an existing trust relationship.  For example, you may pay to use a service that protects your wallet by storing a second set of keys, and then they can generate P2SH multi-sig addresses that can only be redeemed with both one of their keys, and one of your keys.  How much you should trust payments sent to those P2SH addresses that you were given will depend on how much you trust that service, but again, you aren't stumbling blindly into this situation.