Topic: Bitcoin source from November 2008. - page 2. (Read 15308 times)

Yeah, I figured there are hairy problems about scripts depending on arbitrary other transactions.  Maybe Satoshi gave up on making script really work because he didn't know if he could do it right.  Best to get a solid foundation first.

Just having more information about the transaction itself and a bit of global state could be useful.  E.g., maybe locktime could be implemented in script, if the script could know the time.  A script could check that its inputs are evenly distributed N ways across its outputs, for fair splitting of funds between partners or something.  I guess multisig and other collaborative tx signing allows the key holders to mediate these kinds of things themselves.

I have thought about scripts being able to "call" prior transactions' scripts, to recycle useful but complex behavior, if the reference and some optional "patching" is shorter than duplicating the script itself.  But as you say, this kind of thing would be a nightmare of inefficiency and DoS attack surface even at merely today's blockchain size.

I agree with you that script would be drastically more useful if a script could examine the blockchain, look for another tx, etc.

But there are logistic issues. 

It's already the case that spends using outputs from other transactions not yet at least (confirmation depth) in the blockchain are assigned low priority. 

But in a universe where a spend of those outputs caused a script with the ability to examine the blockchain to run, I'd want the script to only be able to examine the blockchain up to (mining output confirmation depth) *prior* to the spend.  Which could be long after the transaction containing the script was made, but could not be very soon before the transaction *spending* that output was made.  In any case it would need to be considerably longer than the current "confirmation" time, and spends should outright fail rather than just have low priority.  This is because a script may reveal information pertinent to the continuing blockchain. If it does so in an orphaned block, then that information is revealed when it ought not have been. We don't want information pertinent to the blockchain that's not getting orphaned revealed based on a view of history that might possibly still get orphaned.  Also, the same restriction is necessary because it should not be possible for a valid spend (where the txin scripts return true) to later become invalid based on additional information getting added to the blockchain.

Finally, it makes checking transactions more expensive, and checking tx would require accessing the blockchain out of sequence.

All these difficulties can be overcome of course, I'm just saying the design criteria are actually pretty finicky.

Yeah, a more apt name would be OP_DO_BITCOIN or something, since it rolls so much core functionality into one inflexible "opcode."  The rest of Script seems like pointless toys, since not even the most trivial inspections of the transaction or blockchain is possible.  It is cool to see the hash collision bounties that have been published using some of the other Script opcodes.  (I'd be interested to see other novel uses, too. Maybe smarter people have found that Script is not as useless as I think.)

Wow this is messed up, the whole thing is unsigned integers; it's all addition. It's an interesting design choice, not just prevents charge-backs but simplifies a lot of the math, you can remove some of
the steps but at the cost of understandability.

... rich vein this one, imo.

I wonder what a Forth expert would make of Satoshi's choice of opcodes. Did he lift it from somewhere, does it look like the work of an experienced Forth hacker? My only experience with Forth is playing around with PostScript a bit, so I can't tell.

I think there was, because the fields are already named scriptPubKey and scriptSig. It was probably preceded by an implementation that had no scripts, just public keys and signatures. I wonder if there was an intermediate phase that allowed multiple keys per output, but not yet full scripts. Maybe the concatenation business made sense in such a context.

Also note that SignSignature and VerifySignature aren't in the files here, although that would be the obvious place to put them. I suspect they used to be there in an even earlier version and were moved to script after that was split off. And script may have been too immature for Satoshi to share just yet. Then again, it's interesting to see that it does already include nLockTime and transaction replacement.

I've also wondered if maybe there was an earlier implementation that used balances, not outputs, as that is what I would have started with. The most obvious starting point might be single input, single output, single signature transactions between accounts. But there is no evidence of this, and maybe previous ideas discussed in the literature already chained individual coins.

I strongly suspect that in November 2008 there was no script. It always felt like a last minute addition to me. It's not mentioned in the white paper at all and everything we know about it was reverse engineered out of the source. And as noted the design is a bit screwy - CHECKSIG feels like something that was refactored out of a pre-existing code base rather than something you'd actually sit down and design on paper.

Isn't this expected? Unless Satoshi was a prophet, he shouldn't know "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in November 2008

A pity that script, VerifySignature and SignSignature aren't included. It might have shed some light on why OP_CHECKSIG works the way it does.

Nice find. Thanks for this.

Extremely nerdy, very cool idea. 

Here's a fun game we can play: could you use something like virtual-notary.org or proofofexistence.com to upload a hash of a (properly padded) string containing the name of the individual? If the name ever leaks out, we can see if your guess was correct.

I may have figured it out.  At least I know someone who had the motivation, skills, and time to have made it, had no need for all the money Satoshi hasn't spent, and who also had a good reason to withdraw from the community when Satoshi did.  But there's no proof, and I'm not motivated to share my speculations.

Got a decent question who the hell is S.N. Have we figured that one out yet?

Wow, thank you so much, it is mind blowing to see this, I'm reading all the code now.

I also have these files, sent to me by one of the early reviewers of the code.
Another interesting fact (I talked in laBitConf) is the fact that there was already a genesis block in it, which was obviously discarded after testing was done.

Still other interesting facts are these comments in main.h

 ///static const unsigned int MINPROOFOFWORK = 40; /// need to decide the right difficulty to start with
static const unsigned int MINPROOFOFWORK = 20;  /// ridiculously easy for testing


So Satoshi may had the capability of 2^40 hashes per 10 minute interval (but he finally fixed it at 32).

These were the latest changes during that period:
 
* Two more decimal digits for BTC denomination
* Added nSequence to TxOut
* Added nVersion to Block
* Changed nBits from zero bit count to compact target format.

Regards, Sergio.

Yeah, someone's been sending 'dust' to old addresses all along the blockchain.  If I understand it correctly, it's an attempt to link the owners of those accounts to purchases being made today. 

The automatic coin selection in the client picks up the extra txOut and may spend it along with other txOuts next time you buy some alpaca socks.   And then somebody somewhere knows that the same person who owns that older txout is the person who bought those alpaca socks.

This is when they can't figure it out just by looking at the transaction history, of course.  But that little bit of dust is someone trying to figure out who owns the account.

Three posts back?

Ok, this is interesting.

So can we get the actual files posted somewhere?

Edit: ooops just saw that been posted ...