Check out chronobit.  The merged mining system allows arbitrary numbers of alt-chains to ride along with no additional cost to the bitcoin chain, beyond the first one.  Chronobit uses that system to create provable timestamps.  Oh, and it uses the p2pool sharechain to give (relatively) high precision, and to allow timestamping to anyone that can generate a p2pool share.

chronobit is really nifty.  If I had learned about it before making my timestamper instead of after, I probably never would have started.

This is a topic-of-one-thousand-threads, one of the many that keep popping up in here over and over again.

The short answer, for those that somehow managed to find this thread first, is that it is technically easy to do in any number of ways with various levels of niceness.  No systems are in serious use because there is no demand.  Which is funny considering how many times I've written this reply, but still true.

I guess if about 20 people all said "I have something that needs a provable trust-free timestamp right now, and it would be worth 5 cents to me if you would finish your service so I can use it tomorrow" to me, I'd get mine ready for public consumption and announce it here.

Indeed.  The world hasn't exactly been beating a path to my door to urge me to release my timestamper.  I made it because of posts here and chats on IRC about the topic, and promptly dropped it when I realized that I had no use for it, and neither did anyone else, so far as I could see.

Bitcoin timestamping has one huge advantage over other services; it is plainly and transparently verifiable.  Other services require trust. *

I might dust it off and polish it up some day as an amusement.  And maybe it'll even be useful some day.  Bitcoin is, after all, teaching all of us to live with trust-free money.  Perhaps some day, we'll have a good use for trust-free timestamping.

* Amusingly enough, this trust is already abused in real life timestamping systems.  Most courts will accept postmark dates as fact, but all serious offices have postage machines that print their own dates, so they are super easy to fake.  The good news is that the post office will scribble out your date and put their own on your mail if they notice something like that happening.  And not much pisses off a judge quite like a lawyer disregarding his duty as an officer of the court.

Not counting the time I spent writing encoders and decoders, and learning the raw transaction API, I'd say less than three hours.  But mine was intended to be a minimum-effort system that does nothing more than prove that some hash X existed prior to some block Y.

Hidden on my webserver, of course.  I tested the interface and the automation (by running the cron jobs by hand) and made sure it worked.  I just ran out of steam thinking about the next steps (security review, polish, release).  The bitcoin parts of it really are easy; anyone can write one.  Maybe I'll even finish mine some day.

Mine derives a pubkey using the hash of the list of hashes as the privkey and spends all collected fees to that address, then spends it back to a real wallet before publishing the final list.  Zero UTXO pollution, maximum of 2 transactions per block, usually MUCH less.  There was a minimum fee for the notary service with a long service window, and people could pay extra to hurry it along.  The holding time was calculated based on the fees collected and the ages of the documents, so that even a single document with the minimum fee would trigger it after 24 hours.

Really hard to say.  If you are already planning to replace the card, I wouldn't touch it, at least not without having a chat with their tech support first.

Nope.  As you point out, it doesn't have access to that information, so by definition, it can't say anything about it.  For that, you need something else.

I personally prefer having full nodes that provide that service (probably for a fee) to users.  I had a lengthy chat on IRC the other day about his proposal to have a fraud alert system, where allegedly honest nodes would shout if a transaction was a double spend, but I wasn't a big fan.  You could also extend the protocol to allow nodes to request data from a peer's UTXO (unspent transaction output) set, and have your client ask several peers just to be sure.

I'm sure there are other ways too.

Agreed.  This isn't something that should be in the reference client, nor widely deployed at all.  The correct way to do this is either with one of the zero-bloat merged mining systems, or with a web service that can collect a batch of hashes to reduce the blockchain load to one transaction per day, or hour, or block or whatever, and can respend the proof transaction to prevent UTXO pollution.

I've written such a web service.  It is pretty easy to do it right.

You actually need more than just the x-value, because a quadratic is used to find the y-value.  A single bit (parity) will allow you to distinguish between the two possible y-values and pick the correct one.

And in my opinion, it is compression, in the sense of that word that we normally use.  Redundant information is discarded, and enough is kept to reconstruct the original.

-- feel free to stop reading here --

There is a second flag involved in the compression scheme, by the way.  It is for the private key export format.

privkey(int256 value) -> pubkey(int256 x-value,int256 y-value) -> address
privkey(int256 value) -> pubkey(int256 x-value,int256 y-value) -> pubkey(int256 x,bool y-flag) -> address

(x-value,y-value) and (x-value,y-flag) give different hashes, and thus, different addresses.  While doing the ECDSA verification, both pubkeys will give the same result because the y-value is reconstructed if necessary.  But, the bitcoin software watches for transactions based on "secrets", and it only stores one secret per privkey.  So, when exporting a private key, it will attach the flag if the key is compressed, so that the importing wallet knows which secret to watch for, and which address to give to the user.

Just FYI, my refund appeared on my credit card's website as a pending transaction this morning.  I was order # 1167, placed on October 5th from btcfpga.com.

Yes.  Unless you are running some other software, in which case I have no idea how that software works.


It sounds like you do know how transactions are verified.  The inputs are looked up in an index kept for just that purpose.

Every node using the reference client is a "full node" with a full blockchain history.  But, it turns out that you only need a subset of the blockchain for most things, including transaction verification.  You can discard transactions after they are spent and just keep the unspent ones*.  The set of unspent outputs is relative small, like a couple hundred MB, rather than several GB for the full block history.

Right now, the protocol doesn't allow requesting or sending partial blocks, but they are working on it.  That will allow even lighter clients.

* Well, you need rollback history too.

This thread delivers!

pcm81, please, please keep posting.  I haven't laughed like this in weeks.  Hand drawn ASIC masks, mythological export restrictions.  Can't wait to hear what you think of next.

Sounds like the bearing or bushing is going out.  Some fans give access through the fan hub by peeling the sticker back.  If you can get to the shaft that way, a drop or two of teflon lube may help.  More likely, you'll need a new fan.

The good news is that it sounds like XFX has really good warranty policies.  You might want to contact them directly.

Version 0.6 released.

Lots of little changes, and a few big ones.

Biggest one is BFGminer.  The BFG configuration file is built on startup.  This means that it won't stay across reboots if you have persistent storage.  I use PXE in diskless machines, so I didn't notice this one yesterday.  If there are other misc BFG options that anyone wants the ability to adjust, let me know.

The old BACKUP_POOL= and TEMP_POOL= lines from your config are now the last places in the BFG pool list.  First place is localhost, and you can fill in between them with PEER[0-9]= lines.  I run a small cluster of boxes, each with 1-3 cards.  Now they can all fail over to each other, and the backup pool should only get hit if they are all booting at the same time.  It also means that you can use the same image and configuration for a mining-only box if you don't have enough RAM or flash to run a full bitcoind node.

The heartbeat script now pulls hashing rate from the BFG api instead of from p2pool.  The script isn't very clever, and just reports them in the order given by the BFG api.  It'll need some work before it can properly handle mixed-platform mining rigs.

The old restart logic was per-card and has been disabled.  BFG should recover from single card failures.  If you have external monitoring, that can handle whole-box failures.  In the next release, I'll fix the restart script to restart BFG to handle the odd cases where the BFG process has failed without crashing the whole box.

I also added packages for PHP5-cli and TOR.  I don't think that PHP works yet, and I haven't even tried TOR.  These are mostly included so that I can play with them on my own personal boxes.

By the way, people posting polls should probably read this article.

Except that it doesn't identify the source address, because, and this is very important, there is no such concept of a source address in bitcoin.  The only concept that applies is that of a source transaction.  Hell, there really aren't even addresses if you want to get deep into it.  The destinations of transactions are scripts.  You and I (and the software) use things we call addresses to help generate those scripts, but they don't really exist.

This may seem like I'm splitting hairs, particularly when virtually all transaction fit a particular mold and directly embed that abstraction that we use for our convenience.  But if you insist on thinking that transactions come from addresses, you are reading your map, not the territory, and you will run into problems when you get to the place where your map is wrong.

SatoshiDice probably gets caught every day.  We have no way of knowing how many people find the address and send coins from shared wallets.  In the future, when multiparty wallets and mixers get more common, we'll have no way of knowing how many people will make the same mistake with them.  How could we know, unless someone wants to make a public issue of it?  From our point of view, and from SatoshiDice's point of view, the transaction came in, and then went out.  It all looks the same to us.

They can get away with it because they don't care.  They don't care if they send your winnings into limbo.  They don't care if they piss off one gambler out of millions.

But most people can't get away with that.  They are in businesses that must care about customer service.  And if you think that you don't care about customer service, then you are probably hoping to make a clone, in which case, you have much bigger problems.

I don't know about stealing* exactly, but I agree that everyone has a duty to return things they know don't belong to them.  The extent of that duty varies a bit, but generally an involuntary bailee is held to a very low standard of duty, sometimes not much more than merely not injuring bystanders while they dispose of it.  In the case of an entity taking deposits, I think that most people would consider the bailment to be at least a tiny bit voluntary, and the duty somewhat higher.  How much higher is open to question.

But, I don't see any mention of the plaintiff taking any steps at all to rectify his mistake.  Would mpex have returned the money if asked?  We have no idea.  Perhaps the judges saw more evidence than I did, but based purely on the public part of the record, the punishment was not justified.

Perhaps we need a rota of appeals, and a supreme rota.  But I can't see how to get there from here, mostly because it compounds the reputation problem.  In the real world, this problem is mooted by simply having someone with the authority to impose obedience by force, an option that we clearly do not have.

* It is clearly unjust, and in most places, illegal.  I may very well have argued in the past for or against attaching the label of "stealing".  That is a matter of philosophy relating to intention, but is not important to my point.  I only make this footnote because I don't want people jumping on my in case I've contradicted any of my old posts.

My first thought was that DefCon is like $120 these days.  But it has been around forever, is huge, and has massive corporate sponsorship (in the form of blackhat).

I should know within a couple of weeks whether or not I'm going.  The sticky point for me isn't the admission cost, so much as scheduling.

Oh, and a discount for foundation members would have been nice, even a modest one, but I'm a bit biased in that regard.

As I've mentioned in a few dozen other threads, there is no "return to sender" in bitcoin.  There is no sender even.  Transactions redeem other transactions, and they can mix in funny ways.

If you need return functionality, you have three choices.

1.  Collect that information before you provide the payment address so that you can track them together.
2.  Wait for the payment message system.  This is basically a special case of option 1.
3.  Make assumptions about the system that are not true, in general.  You can get away with this most of the time, but sooner or later, you'll get caught.