Thank you very much for doing this for us who couldn't attend.

I'm also very curious about Dan being worked up over POW and his prediction. Care to elaborate on what he said?

Hi!

Yes, it's a hash based on the content of the transaction. See the bitcoin wiki or this question:
http://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated

The answer to the second question is no. Furthermore that would be an undesirable feature of a hash function. See "preimage attack".

scrubadub, as long as out-of-band communication is ok, you can get the behavior of #2 by using a chain of transactions. No need for a hard fork.

1. Create a transaction Tx1 that spends the amount to an output requiring two pubkeys (sender and receiver). Broadcast.
2. Create a transaction Tx2 that spends the output of Tx1 to an address controlled by the receiver. Add preferred nLockTime, and set the sequence number to < UINT_MAX to not make it final. Sign and send to the receiver.

The receiver waits until Tx1 is in a block, and so the possibility of a Finney attack is gone. The sender has no control over the coins anymore. The coins are spendable to the receiver after nLockTime by first broadcasting Tx2.

A similar one to this and other fun constructs can be found in the article Contracts on the wiki

Mike, isn't this what you meant? Why do you say the risk of a Finney is reduced, and not gone?

// Fredrik

Sure sounds like it.

He gets it.

Good and fairly short article. Just one thing though:


Try 10% or more in some cases. That's the reality of small credit card payments 

Well done. Congratulations to BitPay and Jeff Garzik

I hope this is enough to authenticate me as past the newbie stage:
Bitcoin is a distributed timestamp server for contracts. It uses a programming language similar to Forth to describe the conditions under which bitcoin in a transaction can be spent (used by another transaction).

Now please get me out of here so I can reply to threads in the technical forum