--- Log opened Thu Aug 01 00:00:41 2013
18:33 < gmaxwell> realazthat: did you see that mill cpu arch stuff on hacker news?
18:34 < gmaxwell> it looks a lot more like the SCIP underlying machine than the tinyram stuff.. I wonder if it wouldn't make for a better implementation, assuming you had a good compiler for it.
18:37 < realazthat> mmm no gmaxwell
18:37 < realazthat> link?
18:38 < gmaxwell> https://www.youtube.com/watch?v=QGw-cy0ylCc
18:40 < realazthat> mmmm
18:40 < realazthat> I'll watch it part now part tonight
18:40 < realazthat> love the comment: "This is the most exciting new development in computing and hair fashion in ten years."
19:16 < petertodd> looks easier in some ways than bitcoin's forth-like...
19:18 < gmaxwell> yea, well, it's a limimted horizon single static assignment rolling window, actually looks a lot like a compiler register allocator.
19:19 < gmaxwell> I also though it looked like the routing topologies in the SCIP stuff, which is sort of interesting.
19:20 < petertodd> yeah, matches up nicely to how they actually work
19:20 < petertodd> I'm also thinking that on a really practical level, it'd be a nice way to refer to previous results more efficiently
19:20 < realazthat> yes
19:21 < realazthat> I think a RA would take such a FIFO into account
19:21 < gmaxwell> on the other hand, ssa form is pretty hard to read code in.
19:21 < realazthat> instead of doing RA
19:21 < realazthat> ie. it would store if it needs to remember something longer
19:21 < realazthat> is there only the belt?
19:21 < realazthat> I stopped in middle
19:21 < realazthat> he said he was splitting temporary storage off
19:22 < realazthat> but I didn't get to that
19:22 < realazthat> is there another register pool for short term storage?
19:22 < petertodd> gmaxwell: yes, although so is pure stack
19:22 < gmaxwell> There is really no belt in the actual implementation. There are a bunch of parallel lanes, one for each delays outputs, and then it shuffles from them into the end.  The belt is just a way of visualizing this delay line system. There is a logical belt per stackframe basically.
19:47 < realazthat> mmm
19:47 < realazthat> I'll finish the vid tonight
19:54 < amiller> i'm convinced there is a huge need for a really different cpu model
19:55 < amiller> circuits suck, turing machines suck, ram machines (including tinyram) suck, and term rewriting machines suck
19:56 < amiller> circuits are the only ones that map well onto modern crazy-crypto, term rewriting is the only one amenable to formal semantics
19:57 < amiller> they're all polynomially (like, quadratically) convertible in between but that's not very precise
20:08 < sipa> wow, impressive stuff
20:09 < gmaxwell> I've programmed for the VLIW DSP he's referring to (c64x) ... its a bit of a pain to program for. But works pretty nicely.
20:14 < sipa> i've watched most of the video
20:57 < amiller> hey i have a simple practicalish idea
20:57 < amiller> why not have block locked transactions
20:58 < petertodd> isn't that what gmaxwell and I have proposed in various ways?
20:58 < sipa> a practicalish idea?
20:58 < sipa> from amiller??
20:58 < sipa> :o
20:58 < amiller> where you can include a block hash such that your transaction is only valid if that block is in the ancestry
20:58 < amiller> this would basically allow you to limit what could happen if there's a reorg
20:59 < petertodd> right, gmaxwell's idea
20:59 < petertodd> also doable with my "getblockhash" opcode ideas
20:59 < amiller> that makes sense.
20:59 < amiller> welp, good one gmaxwell, i must have never understood it if i've seen it before :p
20:59 < sipa> iirc gmaxwell's idea does require the hash being present, but revokes fee claiming when it's not
21:00 < sipa> which sounds less dangerous in any case
21:00 < amiller> it's a nice simplification if you've already been living in a fantasy world where everyone's RationalClients automatically doublespend coins back to themselves, you know, just in case...
21:00 < gmaxwell> https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
21:01 < amiller> a getblockhash opcode is a good way of doing it
21:01 < gmaxwell> Transaction checkpoints. Each transaction (or signature?) should contain a block index and 32 (?) least significant bits of the block hash. The transaction's fees are only valid (or only their full value?) if they are mined in a chain they agree with. This would let people making bitcoin transactions 'vote with their wallets' on the identity of the chain they consider important. This isn't a viable POW replacement, but would greatly reduce
21:01 < gmaxwell> Nodes would typical checkpoint a few blocks in the past from their current height to avoid overstating their opinion unnecessarily.
21:01 < petertodd> amiller: you see my suggestions on how to add as many opccodes as you want with a soft-fork?
21:01 < gmaxwell>  Deep checkpoints could be automatically triggered by observing a crtical mass of coins-day-destroyed confirming them— creating a PoS-ish system, though this is subject to the 'nothing at stake' problem of PoS, and is probably very dangerous. (e.g. isolation risk for inewly bootsrapping nodes)
21:02 < amiller> petertodd, not sure which one you mean, link?
21:02 < amiller> petertodd, if you're thinking about opcodes, in general i think it is interesting to let transactions basically make 'queries' to arbitrary indices
21:03 < amiller> so if you support getblockhash, everyone must keep a index of at least query-by-blockhash
21:03 < petertodd> amiller: hmm... kinda buried in bitcointalk somewhere, but the basic idea is that OP_MAST_EVAL can be done as a soft fork, therefore any opcode can be
21:04 < amiller> the basic functionality is query-by-txid
21:05 < petertodd> hmm... I think the main thing with that king of querying, is figuring out a sane way to actually do it that is understandable
21:05 < amiller> and if we figure out how to make fees that encourage good behavior of the utxo, then you might as well figure out how to do it for arbitrary indexes
21:05 < petertodd> I'd suggest writing some example tx's to get a feel for what makes sense - I posted one to bitcoin-dev recently actually
21:06 < amiller> just think of the whole thing as a pay-per-use key-value-store and it's a little simpler imo.
21:06 < petertodd> well, sounds like you're getting away from something that's arguably bitcoin
21:06 < petertodd> at least my opcode ideas just feel like new opcodes
21:08 < amiller> sure, i'm just saying why not include an op_fetchfalue(keylen,key) that takes basically an arbitrary string
21:09 < amiller> then you can have blockhash:restofthekey and utxo:restofthekey as special cases of just one opcode
21:09 < amiller> maybe op_rangesearch lets you automatically sweep txes or something
21:09 < petertodd> ah right - think about how you'd encode this stuff though, we want efficiency for common cases
21:09 < amiller> well you could optimistically cache at the client support keys
21:09 < amiller> if it all goes in a leveldb it hardly makes a difference
21:10 < amiller> by 'support keys' i mean likely-to-be-used-standard prefixes
21:10 < petertodd> sounds like a worst-base-avg-case-best-case attack waiting to happen
21:10 < amiller> wat
21:10 < amiller> rephrase?
21:11 < petertodd> IE, caching anything makes the worse-case different than avg and best cases
21:11 < petertodd> for security having everything the same speed is much preferable in a consensus system like bitcoin; performance can break consensus
21:12 < amiller> ok well your leveldb already caches utxos so that's present anyway
21:12 < petertodd> sure, which IMO is kinda scary
21:12 < amiller> nothing about using one opcode and key prefixes really changes that
21:12 < petertodd> hmm...
21:12 < amiller> i think you're stuck with that anyway which is one reason to think in terms of the more general case
21:12 < petertodd> well, in any case, write up an example tx for arguments sake
21:12 < amiller> k
21:13 < petertodd> amiller: here is one I did http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02602.html
21:13 < amiller> i think i currently have two items on my "Write an example tx script or shut up" stack
21:13 < petertodd> ha
21:13 < petertodd> it was written as a semi-joke, although jdillon pointed out it actually worked, cheeky bastard
21:17 < amiller> ahh that's really cool
21:17 < amiller> you basically implement merkle tree traversal using the stack script
21:17 < petertodd> yes!
21:18 < petertodd> although read jdillon's reply, turns out it's not needed at all
21:18 < amiller> it has dup and hash and concatenate so it's actually straightforward to do that despite barely having support for anything else
21:18 < petertodd> crazy isn't it?
21:18 < amiller> yeah.
21:18 < petertodd> like, if we hadn't removed those damn opcodes, you actually could do a bunch of nifty stuff...
21:19 < amiller> yeah
21:20 < petertodd> speaking of, I figured out how you could have used codeseparator to delegate tx signing after the fact
21:20 < amiller> i wonder if traversing hash graphs in code was a main example underlying this script language actually
21:20 < petertodd> well, almost...
21:20 < petertodd> could very well be, on the other hand, could also just be satoshi quickly added a bunch of froth opcodes at the last minute figuring "why not?"
21:22 < amiller> we could probably implement an updateable tree/trie over this pretty easily
21:23 < petertodd> oh yeah?
21:23 < amiller> yeah updates aren't any harder than what you've written
21:23 < amiller> you just rehash on the way back up
21:23 < amiller> when you get back up to the top, you have a new root digest
21:23 < amiller> if you have enough reflection capability that you can place the new root digest in the txout
21:24 < amiller> you can basically make a bitcoin-script-quine
21:24 < amiller> like you could spend a txout with restrictions on how it could be spent later that way by making it propagate its own scripthash basically too
21:24 < petertodd> ah right, as in how I'm controlling the next script
21:24 < petertodd> I was going to reply to jdillon that a nice scheme would be to just have an index, and update it with +1 for each subsequent spend
21:25 < amiller> let me try to undersatnd how you refer to txin and txout in the current tx
21:26 < amiller> GET-TXOUT-SCRIPT and GET-TXOUT-VALUE basically hm
21:26 < petertodd> yeah, semi place-holders there
21:26 < amiller> and GET-THIS-SCRIPT for that matter
21:26 < amiller> well hm.
21:26 < petertodd> I mainly wanted to get the use-case down, and explore what uses for that, before commiting to what it would actually be
21:27 < amiller> so if you have EVAL
21:27 < amiller> unforutnately i think you almost-unvaoidably have an infinite loop
21:27 < amiller> however if you just take a hash of the GET-TXOUT-SCRIPT without executing it it's probably ok
21:28 < amiller> do you think you'd support, like, iterating over all the txouts?
21:28 < amiller> your example references exactly the 0th one
21:28 < petertodd> Ah, I was talking about relative addressing though
21:28 < amiller> oh i see
21:28 < petertodd> I'm not even sure how to do iteration properly, or if we want to do it at all - people do like static eval.
21:29 < amiller> yeah.
21:30  * amiller stops worrying and learns to love the stack machine
21:30 < amiller> you know stacks might be the right shape of that computing model i desire
21:31 < amiller> stacks themselves are easy to merkleize and compose
21:31 < petertodd> yeah
21:31 < petertodd> oh, did I ever show you my merkle mountain range idea? IMO the most intuitive way to do an incremental merkle tree
21:31 < amiller> there's this theoretical programming language called Call-By-Push-Value lambda calculus that has stack semantics but i haven't understood it too well
21:31 < amiller> petertodd, yeah we chatted about that a bit, i have a similar idea
21:32 < petertodd> ah good, glad to see it's something people come up with naturally
21:32 < petertodd> It's pretty similar to merkle skip lists in many ways, but it's just so simple and easy to describe compared to it.
21:32 < amiller> i think the last time we mentioned it i tried to convince you it leads to a really efficient work-sampling procedure for spv clients
21:32 < petertodd> yeah
21:32 < amiller> you only need to look at the peaks of the mountain range
21:33 < amiller> the high quality information is up there with the snowflakes
21:33 < petertodd> that's one version, my one was actually more the random sampling version
21:33 < petertodd> remember there's nothing inherently special about mountain range peaks, except in the summation version
21:33 < amiller> petertodd, yeah there's nothing special about the selection condition actually being zeros
21:33 < amiller> they're equivalent
21:34 < petertodd> ah, I think you're talking about something different then
21:34 < amiller> maybe.
21:34 < petertodd> merkle mountain ranges was just the way of essentially combining multiple perfect merkle trees into one commitment
21:34 < petertodd> as the number of root digests grows, the trees merge
--- Log closed Fri Aug 02 00:00:44 2013