Oh I know why, you've been using rebase. git commit --amend and git rebase don't update the commit timestamp and github must be going by commit timestamp to determine when the code was last changed. The --reset-author flag would reset the timestamp, but of course people don't care much about commit timestamps in general anyway.

I think you haven't pushed it to github yet; https://github.com/gavinandresen/bitcoin-git/tree/spendfrom/contrib/spendfrom shows HEAD as 2e9224d9f2 from 6 days ago.

I do agree that is a problem with the software. But it's an easy fix: just maintain a list of transactions that you received knowingly and only consider those transactions as candidate tx inputs. Any other transaction is simply ignored and never spent, nor does it have to be shown in your internal accounts. If you use a unique address per payment, which you should, this is easy to do. If you really want you can return unwanted transactions as well by simply resending them to one of the input addresses, or want, ask for a request signed by one of those addresses.

I think the more fundamental issue is that Bitcoin makes it publicly known that you can spend the funds. A "counter-sign to accept" protocol still has that problem, because you could simply publish the first part of that counter-sign proposal somewhere, and again, just like the blockchain, the recipient would be able to access the funds. The advantage of course is that it is less obvious, the real issue legally speaking. What you'd need to really lock things down is define your transactions to have an additional two steps: receiver signs an intent to accept, then sender signs the intent. Now transactions are forced to be interactive. In any case, Bitcoin can't and never will be able to support this mode of usage because it will always support non-interactive transactions.

P2SH already works that way. The sender of the funds makes an incomplete transaction which says "these inputs can now be spent if someone provides a valid script with this hash" If you want to receive those funds and send them somewhere else you take that incomplete transaction (called the first transaction on Bitcoin) and complete it with a second transaction to send the funds where you want.

I mean, seriously though you're arguing semantics. Ultimately Bitcoin allows you to put money in electronic lockboxes that can be opened by anyone with the correct key. Sure it looks like you're "sending" money on blockchain.info because it shows things in terms of account balances, but an equally valid way of looking at it is "I happen to have the correct key(s) to open these lockboxes" You can come up with window dressing to hide that fact, but fundamentally that is how Bitcoin works. We're better off it courts understand this - it's not much different than me calling you up and leaving a message on your voicemail with the secret account numbers of a swiss bank account.

For instance, I'm going to tell you right now that there is a unspent transaction on the blockchain that can be spent with the private key 0000000000000000000000000000000000000000000000000000000000000001 - I just sent you money, and you can't refuse it!

If you add the option 1 after the transaction hash in your getrawtransaction call it'll automatically decode the hex for you, saving that second call and some latency. At least that's how it works on the command line; I'm pretty sure the actual HTTP-json RPC interface is identical.

The latter transaction is taking longer because it's bigger. To be exact it's 26 times bigger, (5122 bytes vs 193) and it's taking 50 times longer, so pretty much exactly how much longer you'd expect it to take.

That said, Danny is right. Depending on the input address is almost always a bad idea.

Oh, and where I say "hash of a transaction" in the above, replace that with "hash of the signed part of the transaction + sigs with sig representation standardized to defeat the malleability problem"

Also, no need to call it a coin mixing or swapping system really, just call it fast off-chain payments with immediate settlement. If transactions have arbitrary inputs and outputs, and the blinding system works with arbitrary coin values, that's exactly what it is. For instance you could run satoshidice on this system and avoid the blockchain bloat completely.

Excellent post Mike.

You know, by pointing to HSBC and saying they failed to stop money laundering, you're sending the message that they should have tried harder, and by implication, Bitcoin should try harder too. It can't, so that implies Bitcoin should not exist at all. A much better message is to say you obviously don't care about HSBC laundering money, so why do you care that Bitcoin can be used for that purpose too?

It's for multisig transactions where more than one address can/is required to redeem. From tx 3d61531833ed89bd923956116c54d79bee9b0699e9c4357ec8afb096b6f31b9f:

For stuff like looking for forum sock puppets, sure, donations are ok. But in that case, you almost might as well just ask for payment; it's basically what 4chan does with their Bitcoin to avoid captchas scheme.

However, here's an application where you really do want to be sure the Bitcoins are being thrown away: coin mixing. Or to be exact, coin swapping. While blinded chaum tokens are nice, you do need to trust the server, but that's exactly what a fidelity bond can let you do.

So Bob the banker opens shop by acquiring a fidelity bond for 100BTC, now tied to a keypair under his control. (note that for Bob's IT security, the actual implementation needs to support multiple keypairs for everything) Bob creates an advertisement, signed by that keypair, which contains the information about the fidelity bond, the address(s) that will be used to hold funds, and the public keys that will be used to sign the various denominations of tokens, along with the expiry times of those keys. (expiry block #'s might be safer, or just use nLockTime notation to allow either) Note that this advertisement needs to be something that can be amended and revised, a private blockchain of sorts.

Alice now decides to make a deposit. She downloads the advertisement and checks that the expiry date is sufficiently far into the future, that the fidelity bond is valid, and that the total amount of deposits Bob has accepted to the addresses is sufficiently low that Bob has an incentive to behave honestly. Note how that calculation also needs to include the rate of growth of deposits.

She now takes the scriptPubKey she wants the fund to go to and blinds it to create a chaum token. (I assume the actual implementation would need take the hash or something first? I'm not too familiar with how the math actually works)

Alice now creates a deposit request containing the blinded token and the hash of the transaction she will use to send the funds. Bob responds with a signed deposit acceptance message that includes the hash of his initial service advertisement, Alice's transaction hash and the hash of the signed token Bob will give Alice. (somewhere the # of confirmations required needs to be specified) Alice now publishes her transaction. Once a sufficient number of confirmations have happened Bob finally gives Alice the token itself.

To redeem the token Alice contacts Bob again sometime later anonymously, perhaps through Tor. Equally Alice could give the token to someone else to publish, possibly as payment itself if they are happy with the embedded scriptPubKey. Bob checks the signature and creates a transaction sending the funds to the scriptPubKey. Alice can now spend the funds as required.

Alice could also take that token and use it in a deposit request. She'll need to sign the request with the same keys that would be used to spend the inner scriptPubKey. She may also want/have to include a normal transaction to pay fees, and equally she could specify that the change is returned... of course this is looking kinda like a transaction isn't it...


If Bob doesn't give her the signed, blinded token she can prove Bob's fraud with the merkle path from the transaction to a block, and Bob's signed deposit acceptance message.

If Bob doesn't honor the redemption request she simply has to publish the signed unblinded token itself. Note how she does not need to reveal her identity to do this. (somewhere Bob needs to advertise a guaranteed payment response time)

On the other hand if the redemption wasn't honored because it's part of a previous swap of a token for a token, Bob just has to include the signed swap to prove he's in the right.


Now lets look at how Alice can grief Bob. First of all she can't do any harm by transfering funds to Bob's deposit addresses, without the deposit acceptance she can't show Bob has done anything wrong, so Bob is free to simply move the funds and keep the cash.

She can purchase a token and just sit on it to use up Bob's fidelity bonds, but the rules state that after the expiry time Bob is free to keep the funds. Bob just needs to set the expiry short enough that he'll still be happy with his return on the cost of the bond.

If she publishes fake message that Bob didn't send her signed token she wanted Bob just has to publish the token; nothing about the blinded token is private. At the other end publishing the signed token can be responded to by simply transferring the funds as requested. Note that this message needs to be timestamped.


Finally, so where are these fraud notices going to go? Well, I've got an idea that could be done right now, but I think you guys are going to hate me for it so I'll let you figure that one out for yourself.

Well, there is one really big incentive: in a fully decentralized system it might turn out to be the only way of posting a revocable bond. As for the "all parties problem", that's why I'm posting this idea now so that it's out there and people can think about it while they work on the hard parts of doing any of this stuff. I could write a Python implementation of the above with a nice API in a weekend or two, the rest of the stuff actually using it however could be literally months of careful work.


Saying it's decentralized is all well and good, but how exactly is that going to work? What is the technical mechanism that returns credits to the defrauded individual? What lines of software code actually implements it?

That's exactly it. You might fight this post by satoshi on that subject interesting: https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119

Congrats on your tx!

Agreed. A time window of 4 hours would have been quite reasonable too, although of course it's not worth it to change things now.


Ah, yeah I saw that earlier. Fascinating, if unfortunately impractical!

How many time sources is your computer synced to right now? Even of the people running NTP, the vast majority are connected to just a small handful of servers. You don't need to subvert all time sources, you just need to subvert a few for a few hours, because the average miner probably doesn't even check their mining computers daily. The system as it is can withstand a heck of a lot of neglect by miners, your ideas require active management and hence are fragile.

Again, what value to Bitcoin the financial network is there in having really accurate block timestamps anyway?


EDIT: on reflection, I think I misread what you were saying, in any case, digging through the below was quite informative for me.

The algorithm is more simple than you think. Every block of unknown validity, whether it's been given to us by a peer, or we're loading new blocks from disk with loadblock, first passes through the ProcessBlock() function. One of the first things ProcessBlock() does is it calls CheckBlock() which does the initial context-independent validity checks. CheckBlock() has only one timestamp-related check, and it's a really simple one:


That just means that if a block has a timestamp more than two hours in the future we will always consider it invalid under any circumstance. Bitcoin doesn't use the "wall-clock" directly, instead the GetAdjustedTime() function, defined in util.cpp takes the average of all the times reported to us by the nodes we're connected to, and ourselves, and uses that as "time". However it won't let that median change what we consider as "now" by more than 70 minutes; replacing GetAdjustedTime() with just GetTime() is fine if you're clock is accurate. Note how this means that if you set your clock back in time Bitcoin will think perfectly valid blocks are invalid.

ProcessBlock() itself has only one time-related check:


This code is only run if the block isn't part of what Bitcoin thinks is the best chain, and just makes sure that blocks before a checkpoint don't have a timestamp after the checkpoint. (this is why checkpoints have to be picked from blocks that don't have any blocks before in the chain with timestamps after them) Basically it's a sanity check to make sure that nodes can't DDoS you with fake blocks.

Once ProcessBlock has done its checks, it calls AcceptBlock() to do context-sensitive checks that depend on what previous blocks exist in the chain. It also has exactly one time-related validity check:


GetMedianTimePast() returns the median of the timestamps of the past 11 blocks, so basically this check is just ensuring that block timestamps are in fact going forward in time. Now there is also an implicit time-dependency in that the difficulty calculation, GetNextWorkRequired(), uses the block timestamps, but that's a second-order effect.

As you can see, all block validation is done without any reference to the current time at all, with the one exception that at any given moment we will consider any block invalid if it has a timestamp more than 2 hours into the future.

The reason why that one little rule leads to relatively accurate block timestamps is simply because miners want other miners to build on their blocks, so it makes sense to try to keep your timestamps accurate enough that the vast majority of miners will accept them as valid. Notably a 51% attacker who doesn't care about other miners can make the blockchain timestamps say whatever they want them too.


Why do you need to do this?

FWIW I'm planning on setting up some servers that will automatically timestamp Bitcoin blocks as they come in against public RFC3161 timestamp servers - there are a variety of public ones run by certificate authorities and other trusted entities - and making the archives of those timestamps publicly available. That type of idea may be what you really want.

You know, I shouldn't call it a reputation, I should call it purchasing a fidelity bond.


Think of it like a bond, where if you behave honestly you get to continue using it, and collecting more fees from your service. Bob might only have 10BTC of deposits at any one moment, but if the velocity of those deposits just has to be high enough for him to collect 2BTC/month in fees to earn a pretty good 24%/year return on his 100BTC investment. Of course, the acceptable bond/deposits ratio can evolve over time, subject to market forces. As is already true in industries like security, being able to advertise a hefty fidelity bond is valuable.

In particular being able to sell these bonds helps solve a very important problem: making sure services behave honestly when they decide to close up shop. Similarly if Bob has just fallen on hard times and needs cash now he's better off behaving honestly and selling some or all of his bond to someone else than taking the smaller amount of deposits and running.

You have to remember that the only reason blocks have timestamps in the first place is so that nodes can determine how long the last 2016 blocks took to mine for the purposes of adjusting the difficulty. That's it. Even two hours off compared to the 2 week/2016 blocks retarget period is only a 0.5% error. Also asking for the timestamp to be accurate within 30 seconds is pointless when the block interval is ten minutes; the whole idea behind a long block interval is to give the network time to ensure that a new block spreads to 100% of the nodes in a short time so miners aren't wasting their effort mining out-of-date blocks.

Another consideration is that if the allowed timestamp variance is that low miners are going to be using ntp to keep their clocks in sync. Now anyone with control of an ntp server used by a large number of miners, governments for instance, has the ability to split the network, with disastrous consequences. Similarly a screwed up daylight savings update (one that wrecks the computers idea of what UTC is) could throw vast numbers of computers +- an hour off relative to others, again splitting the network.

Your average computer has a cheap internal clock with roughly 100ppm overall accuracy. Thus in 1 year you can expect a maximum of about 0.9 hours of drift. Roughly speaking the existing timestamp protocol rules mean that the worst case scenario of an unattended mining computer without ntp, left drifting for a year and suffering a botched daylight savings update still has a 50:50 chance of producing valid blocks. That's a good thing!

It's notable that litecoin stuck with Bitcoin's 2 hour rule, and p2pool, even though it has a 10 second share interval, went with one hour.

Heck, I'm very slowly puttering around with a timestamping-via-bitcoin project myself, so believe me I'd love it if block timestamps were more accurate. But accurate block timestamps just aren't very important for Bitcoin's core purpose as a financial network.


If you come up with something let us know. An easier way of messing around with custom transactions would be handy.

Speaking of, here is an exercise for you: why must the locktime be an absolute number? Why can't it be a relative number?

Doing that means anyone with access to the private keys of those organizations donation addresses can defraud you without consequences. It's even worse because the whole point of this mechanism is automated validation, so even if such theft is detected anyone who fails to update their software's "well-recognized donation address" is at risk.

It's just game theory. Lets suppose you want to accept an IOU from some identity, a good example would be a digital bearer certificate issued as part of a microtransactions or chaum-based coin-swapping system. To know if you should accept that debt from the identity you need to be able to figure out the value of the identity, determine how much the identity owes others in total, and be able to publicly prove the identity has done something wrong to destroy it's reputation. My proposal allows you to solve the first problem by providing a way of assigning a known value to the identity.

Suppose you, Alice, want to know if you should accept a 0.001BTC micro-transaction certificate issued by "Bob" as payment. You know (somehow) that the total value of all such certificates issued at this time is 10BTC. Bob has used the above mechanism to provably throw away 100BTC of value. Thus if Bob simply keeps all his deposits he'll get to keep the 10BTC of deposits, but he's thrown away a reputation that cost him 100BTC to aquire. Thus it's in his interest to honor the deposit certificates.

What's nice about this proposal is that the proof of value is just a list of transaction pairs, and if you include the merkle paths up to the block header even SPV clients can validate the proof. You can also make these reputations securely exchangeable by using their outputs as smartcoins, and again SPV clients can validate the proof by giving them the transaction history - if a "reputation" can be sold it means that an identity that wants to shutdown a service still has an incentive to pay back outstanding debts because the reputation still has value. (although you'll need to limit what the reputation can be used for, see below)

Of course, the value assignment is the easy part... Creating efficient mechanisms for determining the total amount of outstanding debt as well as ways of publicly publishing and automatically validating proofs of wrong doing is much more complex and will depend on exactly what sort of transaction is being done. (similar to what OpenTransactions attempts to solve) Either way this mechanism will work best if people can agree on one way to do it, and helps strengthen security by promoting mining too.

The reason why you were able to spend that tx is because of this. What you've done is made a transaction that can't be spent in any block before block #3, which was over four years ago.

What did you expect to happen?

Look into the Raw Transactions API first, but be careful, it's easy to screw up and accidentally lose your coins with it. Test whatever you are doing on testnet first. What are you trying to do exactly?

As for creating fully custom txin-scripts and txout-scripts, if you've read the "Scripts" page on the wiki you might not already realize that there is a set of standard transaction types that the network supports - any transaction other than that isn't easy to get into a block. As far as I know there isn't any easy to use software to create special transactions. When I've done it I've just edited the raw hex bytes produced by the raw transactions API.