00:00:47jtimon:mhmm I don't know how something that is not powed can be very strong
00:01:06petertodd:jtimon: how is it not PoW'd?
00:01:46jtimon:oh, I see, each chain mines on top of the previous timestamp, not the previous block of the subchain, no?
00:02:00jtimon:what if one chain goes faster?
00:02:09petertodd:heh, well, interesting question!
00:02:46petertodd:you can probably come up with a scheme where the actual headers, just not the block contents, are known to both miners, and you adjust difficulties appropriately
00:03:24petertodd:but that's far from the most interesting part of this stuff
00:03:54jtimon:the most interesting part is having ligher miners, no?
00:04:20petertodd:jtimon: well, that's why you'd do it, but in the process you've made it succeptable to new attacks that didn't exist before
00:05:12petertodd:like I say, if the data for one chain isn't available for whatever reason, things get ugly, and less than 50% of total hashing power can attack the chain that way
00:08:09petertodd:one thing you can do is have "challenges": pick a nonce in the top timestamp chain, and make the rule be unless the data from that subchain turns up - along with an appropriate proof - the way you decide what is the best block changes such that you *can* reorganize that subchain with <50% hashing power
00:08:23petertodd:(normally you can't due to the timestamp property)
00:09:02petertodd:at least then if subchian data gets accidentally lost, somehow, the state of the system can recover.
00:10:00petertodd:that also somewhat protects you against malicious attackers, essentially because you can temporarily pay higher fees to get the rest of the miners to force some <50% attacker to spit up the data you actually need to make your transaction
00:10:16petertodd:and once you make a robust scheme with two subchains... it trivially extends to a full on tree
00:10:20jtimon:mhmm, I don't know...it seems very complex, maybe we just need to think about another way of sharding
00:10:37petertodd:it is very complex, but my suspicion is that sharding inherently is complex
00:10:48petertodd:just handwaving and assuming global consensus is *way* easier
00:10:59petertodd:pity it doesn't scale though
00:13:19jtimon:yeah, I've been thinking about other sharding-like schemes but for now they were broken (well, the first one actually just needs every node to trust each other, that is, is centralized)
00:13:40petertodd:heh, well doing it with trust is easy :)
00:13:40sipa:jtimon: nah, that's just called ripple
00:14:10jtimon:sipa: no, I don't mean ripple, I mean something scalable
00:14:28petertodd:jtimon: heck, just arbitrarily saying "OK! it's 8 block chains now!" will probably work in practice, even if really the security isn't as good as it could be
00:14:42petertodd:jtimon: ripple is scalable technologically, socially OTOH...
00:14:45jtimon:well, I haven't seen any centralized markets infinitely scalable
00:15:06petertodd:jtimon: ripple the idea isn't centralized
00:15:18sipa:i've mentioned it before, but i'd like to stop confusing the word 'centralized' with 'trust-free'
00:15:47jtimon:can the ripple.com network process 1 billion tx/s ? definitely no
00:16:03sipa:sorry, 'decentralized' with 'trust-free'
00:16:07jtimon:petertodd: 2PC ripple is compltely scalable
00:16:28petertodd:jtimon: exactly, ripple.com is an abomination and we shall not mention it again
00:16:44sipa:i shall resist.
00:17:07sipa:anyway, you could have a bitcoin-like system, where instead of script verification, there was just one huge datacenter computing zero-knowledge proofs of the validity of the chains
00:17:31sipa:it would be totally centralized (as in central point of failure), but to an extent trust-free
00:17:50jtimon:well, I think my centralized system is completely scalable, but maaku and I have to actually test that
00:18:01maaku:jtimon: another Joy-derived language that might be useful http://www.cat-language.com
00:18:05petertodd:sipa: which is roughly what my fidelity-bonded foo ideas were about, especially the fidelity-bonded ledgers version
00:18:26sipa:also, a bunch of N nodes all talking to eachother that all trust eachother is perfectly decentralized, but not trust-free at all
00:18:32jtimon:maaku I read that one has strong typing instead of dynamic
00:18:54maaku:yes, which would be a good thing i think
00:19:14petertodd:sipa: yes, and with some changes to the way blocks are structured you certainely could have groups of miners who trust each other co-operatively create and mine blocks with individually low-bandwidth nodes
00:19:36petertodd:sipa: I think you can even pull that off as a soft-fork
00:20:08sipa:anyway, i'm not making any particular suggestion here
00:20:26sipa:just trying to point out that 'decentralized' is ambiguously used in bitcoin context
00:20:27jtimon:well, I try not to use ZKP or snark/scip when designing, haven't learned black magic yet...
00:20:45petertodd:jtimon: if it can't be done with hashes, it's not really bitcoin
00:21:39jtimon:sipa: I get your point, sometimes just trust-less is enough
00:22:53jtimon:maaku: why do you think strong typing would be better? the little I read about joy sounded very good
00:23:52maaku:jtimon: enforced strong typing is less likely to result in consensus bugss
00:23:54jtimon:like if I could even like the language and all
00:24:04petertodd:maaku: are you thinking of including those languages as libraries or what?
00:24:06jtimon:I see
00:24:24jtimon:replacing the current scripting I think
00:24:36maaku:petertodd: currently hypothetical replacements for script
00:24:54sipa:any reason why you'd use a stack-based language, and not something ast-based?
00:25:14sipa:(i've been following about 1% of the discussions here the past weeks, i've certainly missed a lot)
00:25:30jrmithdobbs:rust txn scripts please!
00:25:38petertodd:maaku: right, because I was going to say, I think you're much more likely to avoid consensus bugs by just making the underlying opcodes/interpreter simple - screw what actual language you end up with
00:26:16petertodd:maaku: strong typing means you have types, and types themselves are a bunch of code with potential consensus failures
00:26:39maaku:sipa: it'd be (relatively) easy to transition from script to some other Forth-like language - essentially just write a translator between the two
00:26:59maaku:and it's nice that, like LISP, the syntax is simple enough that you can code directly and don't really need a compiler
00:27:14sipa:you can do the same for an AST like language
00:27:20sipa:well, in one direction at least
00:27:48sipa:and i'm sure it's much closer to the domain we're representing
00:28:12jtimon:maaku wasn't there more reasons to chose a concatennative lang ? http://en.wikipedia.org/wiki/Concatenative_programming_language
00:28:23petertodd:sipa: I think the big question is do you need the self-modifying code that forth makes possible?
00:28:32petertodd:sipa: for quines it's certainely useful
00:28:49sipa:quines? what do you need that for
00:29:02maaku:sipa: covenants
00:29:15sipa:another thing i need to read... :'(
00:29:16petertodd:sipa: IE things like SPV-verifiable colored coins
00:29:52petertodd:sipa: write a script that forces the transaction spending it to have a certain form, propagating the colored coin definition like a virus
00:30:10jtimon:basically, forcing the outputs of the next transaction to have certain code in their scripts
00:30:29jtimon:well, maybe only some of the outputs
00:30:48maaku:and Forth-like languages are really good for this sort of thing, although not required
00:31:09maaku:since you basically just have to test the prefix of the output script
00:31:12petertodd:also, merklized abstract syntax tree schemes *are* very forth compatible, even the self-modifying quine versions
00:31:24jtimon:actually petertodd the colored coins example was confusing to me because of regular colored coins and freimarkets
00:31:36petertodd:forth is just symbol tables, and symbol's can just as equally be merkle hashes
00:32:47maaku:petertodd: re simplicity, that's why i'm looking at Joy/Cat. it's basically two dozen or so combinators + builtins
00:32:53maaku:and a syntax that is even simpler than LISP
00:33:23petertodd:maaku: incidentally, keep in mind that as complex as these sharded blockchain ideas are, they can also make these computationally intensive consensus schemes more viable by spreading the computation and space across more miners
00:33:47jrmithdobbs:forth has seemed like the obvious choice since i first saw the script ... first thing to come to mind was "why isn't that forth"
00:33:51petertodd:maaku: syntax has nothing to do with what goes in the chain necessarily... :)
00:34:07petertodd:jrmithdobbs: because satoshi didn't want a complex symbol table!
00:34:16panicearly:panicearly has left #bitcoin-wizards
00:34:16petertodd:jrmithdobbs: script is even *simpler* than forth
00:34:20jrmithdobbs:petertodd: i know
00:34:42jrmithdobbs:petertodd: but forth is such a great fit for this use case ;p
00:34:44maaku:jtimon: yes i don't think the colored coin example is good for explaining the purpose, but IOU with a buy-back option is a good succinct example
00:35:21petertodd:jrmithdobbs: agreed
00:35:53maaku:i don't think satoshi realized that you could prefix an execution counter to the scriptSig to solve most of the turing-complete worries
00:36:09gmaxwell:sipa: petertodd pointed out that you can make colored coins where the network tracks the color for you by using a covenant scriptpubkey that basicially handles the task of making the network track which coin is colored.
00:36:19gmaxwell:maaku: I don't think a counter is sufficient for resolving "worries"
00:36:37petertodd:maaku: I'm sure he did, and thought of additional issues
00:36:52maaku:gmaxwell: i think the DoS preventions I mentioned in the scrollback solves the remaining worries
00:36:56maaku:is there something I'm missing?
00:36:56petertodd:maaku: though then again, counting sigops in un-exectuted scriptPubKeys was a damn stupid idea
00:37:24jrmithdobbs:petertodd: ya i was going to say, i think you're inferring too much credit there
00:37:53petertodd:jrmithdobbs: indeed
00:38:10sipa:i don't think satoshi considered several of his changes (disabling opcodes, limited block size, counting sigops) as hard rules, just temporary anti-dos measures
00:38:23petertodd:maaku: the DoS preventions work even better when you do per-tx PoW schemes
00:38:26gmaxwell:maaku: engineering ones, like operation counting bugs creeping in when people implement faster execution engines, or sandbox escape when people implement faster execution engines.
00:39:10jtimon:petertodd how don't you hardcode the per-tx pow?
00:39:11petertodd:gmaxwell: the latter problem isn't specific to execution counters, heck, even the former isn't totally
00:39:20jrmithdobbs:gmaxwell: or emulating some other form of state/etc through some other trickery that would hurt everyone's head
00:39:23petertodd:jtimon: why would it be hardcoded?
00:39:30jrmithdobbs:gmaxwell: those are the really scarey ones imho
00:39:34maaku:gmaxwell: yes, well that's why I'd prefer a simple language with a minimal number of primitives and implementation complexity ...
00:39:38gmaxwell:petertodd: no but IP counting is actually much harder when you've implemented a tracing JIT.
00:40:01maaku:i think you could implement Joy/Cat with the same or less lines of code as current bitcoin script
00:40:07gmaxwell:(A significant fraction of all code execution bugs in firefox have been in the JITs)
00:40:14jtimon:patertodd is just the simplest scheme that comes to mind, just want to know what you had in yours, what's your diff filter?
00:40:32petertodd:gmaxwell: well, that's an argument against sophisticated scripting in general too...
00:40:47gmaxwell:maaku: right but when people actually use it there will be a lot of pressure to replace it with a JIT. And a lot of room for bugs resulting in sandbox escapes and instruction counting glitches.
00:41:06petertodd:jtimon: well, *absolutely* simpliest is to say a block has a single tx in it :)
00:41:18gmaxwell:petertodd: it is, indeed. but a JIT for a non-turing complete language is FAR easier to make safe. Esp since it can work with dumb template matching much of the time.
00:42:31jtimon:I thought it was per-tx pow apart from block pow, the thing I'm more confortable with are "optional pow fees"
00:43:13petertodd:gmaxwell: that's nice, but it all comes down to "is programming scripts easy enough and fast enough to be practical?" especially when we're talking things like covenants
00:43:57jrmithdobbs:gmaxwell: is replacing the script being seriously considered or just a toy conversation?
00:43:58petertodd:jtimon: I think it makes most sense when the only pow is in tx's, although exactly what that'd look like is an interesting question
00:44:26sipa:jrmithdobbs: even gavin has mentioned it (though i'm sure he's thinking about much less exotic changes)
00:44:45maaku:jrmithdobbs: jtimon and I are seriously considering it in the context of trying it out on an altchain (freicoin)
00:45:08petertodd:maaku: and it's on my list of things that I need to research for MSC
00:45:09gmaxwell:jrmithdobbs: most of this is speculative conversation. The thing I'd want to replace it with isn't yet realistic to deploy.
00:45:19maaku:although given all the other more important stuff on our plate, it's still a very hypothetical conversation
00:45:28jrmithdobbs:gmaxwell: which is?
00:46:10jtimon:with covenants we could replace we could replace some freimarkets stuff and already have a use case that was actually a missing piece for p2p lending
00:46:13petertodd:maaku: well, for me it's a top priority
00:46:21sipa:if i was asked today to write a script language for bitcoin, i think it'd be an AST with slightly lower level crypto operations than bitcoin has now
00:46:33gmaxwell:using some form of ZK-SNARK instead of doing fancy things directly. (I'd still be in favor of improving things generally, e.g. M-AST)
00:46:46petertodd:sipa: mostly agree there, what's interesting is what types of data would that script have access too?
00:47:02sipa:i don't think byte arrays as data type is such a bad idea
00:48:27jtimon:gmaxwell sipa will an AST really be simpler for script coders?
00:48:47gmaxwell:(since I don't think it ever would make sense to use a SNARK to accomplish a 'simple' (X and Y) or ((X or Y) and 2of3(Q,R,Z)).
00:48:48jrmithdobbs:jtimon: huh? of course it would
00:48:48maaku:gmaxwell: the SNARK would still have a language it understands though, right? (e.g. tinyram)
00:49:21gmaxwell:maaku: no. What I'd do is just implement a generic snark validation, and providing the snark verification key in the transaction.
00:49:22petertodd:sipa: that's not what I mean actually, I mean does the script have access to things like txins, txouts, blockchain headers?
00:49:30sipa:petertodd: for bitcoin, no
00:49:32jtimon:jrmithdobbs I mean simpler than Joy, not simpler than the current one
00:49:52sipa:petertodd: well, generalizing the hashtypes may be useful
00:50:25maaku:sipa: if you give the script access to the transaction, block header, and utxo data, a lot of interesting covenant-related stuff becomes possible
00:50:31sipa:but that's not really an interesting discussion - i'm being intentionally conservative here
00:50:48gmaxwell:maaku: it's pretty hard to write a compact script to do things with that access however.
00:50:49petertodd:sipa: yeah, where I'm really more focused on something you'd need for MSC, day job and all :P
00:51:08gmaxwell:It would be nice if people would write some hypothetical scripts.
00:51:25maaku:gmaxwell: hard to write a compact script? howso?
00:51:27petertodd:gmaxwell: that's also on my priorities list
00:51:29gmaxwell:E.g. we know that enabling xor or add on hash outputs gets us a bunch of things, and what we have to do to get those things.
00:51:35maaku:do you mean the interpretor, or the script(s)?
00:52:24gmaxwell:maaku: no, go write a script using the disabled opcodes that and a hypothetical PUSH_OUTPUT_N and PUSH_INPUT_N that achieves a non-trivial covenant.
00:53:09gmaxwell:it's pretty easy to end up with a painfully complicated script just to do something conceptually simple.
00:53:27petertodd:maaku: you ever written any assembler code?
00:53:39maaku:ok, you mean in bitcoin script, yes
00:53:43sipa:jtimon: an AST is really equivalent to a stack language where every operation only consumes the N last entries (with N known before evaluating them) and produces a single one
00:53:51maaku:petertodd: look at the scripts we have in the back of the freimarkets paper ... yuck
00:53:55sipa:and you have end up with a single output
00:54:27jtimon:sipa, yeah, this http://en.wikipedia.org/wiki/Abstract_syntax_tree
00:54:39maaku:that's why I'd like a more powerful scipting language - even with opcodes re-enabled it's still a mess
00:54:59gmaxwell:maaku: but the problem with more powerful is that as soon as you color outside the lines you're back to a mess.
00:55:04sipa:jtimon: yeah sure, just saying that it can't be harder to implement, it's pretty much a subset of what we have now
00:55:41jtimon:I meant that something like joy seems more powerful, thus simpler for the scripting language users
00:55:53sipa:scripting language users?
00:56:07sipa:i don't care about that - go use a compiler if necessary
00:56:08jtimon:the hackers writing bitcoin scripts
00:56:09gmaxwell:sipa: well there are complications, because we'd want M-AST but the merkelization should be optional... because it doesn't make sense to merkelize something which is smaller than the hash and which you don't need to keep private.
00:56:20jtimon:sipa: good point
00:56:29jrmithdobbs:gmaxwell: btw speaking of language semantic stuff ... please go yell at someone to implement higher order kinds in rust so that functor can be implemented correctly already ;p
00:56:44gmaxwell:Thats what an assembler is for. Plus for any real use of this you'll want an assembler with a theorem prover in it so you can actually know if your script works.
00:56:55sipa:jtimon: i care about easyness by which an implementation (script interpreter) can be judged to be correct
00:57:28maaku:sipa: is there a specific AST that is a good match to bitcoin?
00:57:49sipa:give me a day and i'll write you one
00:58:24gmaxwell:E.g. when eligius proposed using a multisig script for controlling their emergency pool recieving address the policy they decided they wanted was (X and Y) or ((X or Y) and NofM(Q,R,Z...)) and we wrote a script to achieve that... but we had no way to tell for sure that it was safe!
00:58:33maaku:i just mean i'm wondering if you had something in mine, like lisp/scheme or the spineless, tagless machiens of Haskell
00:58:43gmaxwell:and it wasn't so simple that you could just look at it and tell for sure it was safe.
00:59:41maaku:jtimon: btw theorem prover mentioned by gmaxwell is why you'd want static typing
00:59:51gmaxwell:(for _sure_ not just 'sure'... as it would potentially have hundreds of BTC assigned to it in a day)
01:00:25petertodd:gmaxwell: so these theorem provers, what kinds of languages don't they exist for?
01:00:31gmaxwell:so it would be nice if I could throw that into a theorm prover and ask it "is there any way to satisify this script that doesn't provide sixX or sigY"
01:01:44jtimon:oh, gmaxwell, I forgot that open problem
01:01:48gmaxwell:petertodd: the provers themselves are seperated from the languages, and there exist tools to convert code into inputs for them for a variety of languages.
01:01:57sipa:maaku: ok, there's a data stack that is initially populated with the script inputs (scriptSig data pushes), and a program, which is a serialized abstract syntax tree
01:03:03sipa:maaku: AST nodes are: access[i] (retrieves the i'th element on the stack, counting from the top, and returns it without modifying the stack)
01:03:14gmaxwell:In C I use a tool called frama-c that can drive a dozen different backend provers. (probably one of the best of the provers for proving things about program execution is http://alt-ergo.lri.fr/ )
01:03:14sipa:maaku: const[x] (just returns x)
01:03:47petertodd:gmaxwell: exactly, so I assume for non-turing complete AST's basically the provers are easier, but as you're saying, sounds like they exist for interpreted stuff as well - hence the desire to have a prover available is not directly a consideration for the language itself (at the consensus layer)
01:04:11jrmithdobbs:petertodd: they exist in compilers like he wants, even, for that matter
01:04:23jrmithdobbs:petertodd: (haskell does some forms of this during compilation)
01:04:28sipa:maaku: let(expr1,expr2), which evaluates expr1 and puts it on the stack, evaluates expr2 using that modified stack, and then pops the element again
01:04:45gmaxwell:petertodd: certantly the language design could influence how easy it is to have a prover. For C it's a complete cluster@#$@ and the provers are not terribly complete E.g. there is no _sound_ prover for the full C language.
01:04:47sipa:maaku: and then some basic arithmetic/crypto/string/... whatever operators
01:05:12maaku:sipa: i see. thank you this helps
01:05:22gmaxwell:petertodd: because things like pointer deferences make life insanely hard for the provers. (though, they're not completely impotent)
01:05:23petertodd:gmaxwell: right, and again, this sounds like you're just getting pushed to what I've always thought is the most obvious way to do it: merklized forth
01:05:34sipa:maaku: you can map this indeed to a lazily evaluated functional language
01:05:49sipa:maaku: which would for example mean you don't need to evaluate expr1 in a let, if its expr2 never refers to it
01:05:50jrmithdobbs:also, I'm somehow watching 3 different conversations about this same basic subject in 3 different channels in the same window at the same time and I have no idea how that happened but it's confusing
01:06:13gmaxwell:yea, I do think that stack langauges can result in easy life for the prover, though there is still the free variable of how types work.
01:06:35maaku:sipa: i've been favoring strict over lazy due to implementation compleity and risk of consensus errors
01:06:42maaku:does the laziness gain you anything?
01:06:52jrmithdobbs:sipa: tbqh, a limited haskell98 with no IO monad would be perfect and without IO the runtime gets tiny
01:06:59gmaxwell:maaku: if we merkelize the untaken branches it also can get you improved privacy and reduced program size.
01:07:12jrmithdobbs:sipa: something like fay
01:07:52maaku:jrmithdobbs: more than that Haskell core language is quite simple and probably something worth looking at, or the even more low level STG machine in GHC
01:07:53jrmithdobbs:sipa: which is haskell98->js compiler sans typeclasses (so no monads period)
01:08:14gmaxwell:maaku: e.g. if your transaction can be redeemed way X or way Y and Y is some 4of5 of 5 pubkeys ... then you (1) save all that space in the transactions spending it way X, and also (2) don't disclose the details of way Y unless you use it.
01:08:52sipa:yeah, adding a choose operator that evaluates one of two branches, and takes a hash for the other, is easy enough to add here
01:09:29gmaxwell:One thing to keep in mind is that what we put in a scriptsig does _NOT_ need to be a copy of the program. What goes into the scriptsig is a _witness_ that proves the program was correctly evaluated. This doesn't require including the whole program.
01:09:48jrmithdobbs:ya that's the key part satoshi missed i think
01:09:51gmaxwell:This mental model obviously applies directly to the snark stuff, but it even works in conventional execution.
01:10:29jtimon:gmaxwell not with p2sh, does it?
01:10:50sipa:so, to elaborate a bit further
01:10:54gmaxwell:jtimon: we're talking about a generalization of P2SH that works recursively, effectively.
01:11:03sipa:you associate a hash with every ast node
01:11:24maaku:gmaxwell: what was that point about merkelizing in response to?
01:11:35gmaxwell:sipa: I still think you need to have non-hashing nodes in your AST, because its wasteful to hash for a single operation.
01:11:44gmaxwell:17:06 < maaku> does the laziness gain you anything?
01:11:49sipa:gmaxwell: yup, that's easy to do
01:12:10jtimon:gmaxwell so you're saying that without the snark you need the merklization for what you want, got it
01:12:20jrmithdobbs:that question seems so backwards to me
01:12:22sipa:instead of associating a hash with every node, you only associate one with every "tree piece"
01:12:24maaku:oh i meant lazy vs strict parameter evaluation (e.g. Haskell)
01:12:29jrmithdobbs:after doing nothing but writing haskell for the last 2 months
01:12:40sipa:tree pieces are delimited by choose operators
01:12:42maaku:yes you definately need lazy/short-cut conditionals
01:12:51petertodd:gmaxwell, sipa: remember that one potential way of doing this is rather explicitly with OP_EVAL and OP_HASH160 (essentially)
01:13:09gmaxwell:sipa: I think you could go further and have two kinds of choose operator, one that hashes and one that doesn't.
01:13:39sipa:gmaxwell: well there can be a regular ifthenelse operator
01:13:44sipa:that has no choose magic
01:13:50gmaxwell:right. fair enough.
01:14:00sipa:i'm saying the same thing i think
01:14:27sipa:except choose is special in that it explicitly takes a hash as argument, and not an expression
01:15:21petertodd:sipa: note that simple if-else-endif isn't sufficient if scripts or script fragments can return a value before reaching the end of the block - you might not want the rest of the block to be public
01:15:32sipa:but so is const or access, they don't take subexpression eithet
01:15:54sipa:petertodd: these are not imperative programs, there is no return operator
01:16:02sipa:they're just expressions
01:16:18petertodd:sipa: right
01:16:44gmaxwell:petertodd: even if there were you could always wrap hte hidden data with another choice.
01:16:57petertodd:gmaxwell: true
01:17:16sipa:yeah, choice is there to hide pieces of the script
01:17:22sipa:either because they are large
01:17:27sipa:or because they are private
01:17:53petertodd:sipa: hmm... so when is choice not something you can do with an if block?
01:19:05gmaxwell:(kind of a fun thing where we could make standard addresses a choice with ecdsa in one branch and then a hash based quantum hard signature in the other... and if there is a compromise of ECDSA we soft fork to deny ecdsa redemption while people redeem coins via the hash based signing.)
01:19:09sipa:i don't think it's really an if in any caze
01:19:18sipa:let me come up with an example
01:19:35sipa:to do a 1-of-2 multisig
01:20:07sipa:let's say scriptA is something that fetches a sig from the stack and verifies it with pubkeyA
01:20:08maaku:hrm. I just realized that by executing code from the stack Joy/Cat makes it difficult to Merklize...
01:20:21sipa:scriptB is the same, but for pubkeyB
01:20:45petertodd:sipa: right
01:21:22petertodd:maaku: you can still merklize the initial code up to where the stack is executed
01:21:23jtimon:maaku: that seems right, I guess AST-script it is
01:21:31sipa:now you construct a script of the form choice(scriptA,scriptB), and put its merkle root in the output
01:21:40sipa:however, to spend it
01:22:00sipa:you either use choiceL(scriptA,hash[scriptB])
01:22:18sipa:or choiceR(hash[scriptA],scriptB)
01:22:33petertodd:sipa: see, I'm not sure how that's any different from IF ELSE ENDIF
01:22:43petertodd:sipa: which is how I always envisioned MAST to work
01:22:54sipa:it's an if then else, but the if/else is hardcoded
01:23:00sipa:it cannot be an expression
01:23:54sipa:its runtime semantics is just the identity
01:24:06sipa:it only affects how the hash of the script is computed
01:24:51sipa:note that choiceL(scriptA,hash[scriptB]) evaluates to just scriptA
01:25:08petertodd:right, and by that I mean in the binary representation of a script, you'd have some way to signify a IF code block that must never be executed, followed by the hash, vs. one containing actual opcodes
01:25:56sipa:right, but i don't like to think of it in term of executable operations
01:26:23sipa:it's just a tree with certain parts covered, by giving a hash instead
01:26:39petertodd:well, we're using similar words for the same thing :)
01:27:06sipa:but i think your original question really was
01:27:21petertodd:see, my real point is, with merklized forth it gets even more sophisticated, because your symbol table is hashes of code, and potentially at runtime you'd do something more sophisticated there just get some chunk of code dynamically
01:27:36petertodd:yet you can still arrange such that code that's never executed is never provided
01:27:42sipa:that's over my head :)
01:28:32sipa:one question is if there are other merkle-choosing-like operations possible
01:28:52sipa:which do not mimick if-then-else
01:29:53sipa:i think if you have some for(i in [0..n], f(i)) operator
01:29:58petertodd:sipa: tl;dr: forth can do the magic that lisp can do, not with macros, but with self-modifying code
01:30:01sipa:with n a constant integer
01:30:15sipa:then you can have a merkle version of it as well
01:30:32sipa:that takes the hash of the non-evaluated loops
01:30:36petertodd:and for that matter, you can do tail-recursion for loops too...
01:30:49petertodd:and that can still be merklized
01:31:40sipa:without needing to reveal how many loops you wanted to be possible
01:31:55gmaxwell:sipa: well ... if you have a homorphic hash you can do 1 of N execution more efficiently. Though I'm not aware of any way to do that which we'd consider in scope for this discussion.
01:32:08maaku:petertodd: how are you going to merklize forth?
01:32:57maaku:ah, are you thinking of replacing a quoted block with its merkle hash?
01:33:35petertodd:maaku: remember, we're merklizing the potential code that can be run
01:34:13petertodd:maaku: so if you end up with code that defines new symbols, but doesn't use those symbols, then the symbol definition doesn't actually need to happen if that particular execution trace doesn't use them
01:35:26gmaxwell:sipa: so, linear iterative compression.
01:35:38gmaxwell:say you have some straight line code that can stop at some point.
01:35:49maaku:petertodd: ok, in Joy at least "if/else" is handled like so (I think it's the same for Forth): [quoted-true-block] [quoted-false-block] OP_IF
01:36:05maaku:in other words, push the code on the stack before execution
01:36:11petertodd:maaku: correct
01:36:50maaku:so I suppose we can replace the branch not taken with OP_RETURN (when executing), plus an affixed hash value for what was there
01:36:57gmaxwell:ins0 1 2 3 4 5 6 7 8 you compute H(ins0....H(6|H(7|H(8))...) and then if you execute and run to step 4 and stop, you'd provide 0 1 2 3 4 H(5...H(8)).
01:37:05maaku:ok that would work
01:37:13petertodd:maaku: and a symbol is a chunk of code, so you have Symbol1 Symbol2 OP_IF, and symbol2 never executes, then where the symbol is defined in the first place can be replaced with just the hash of the opcodes that would have been put there
01:37:21gmaxwell:I think that structure is not equal to choices.
01:37:24sipa:gmaxwell: that's exactly what i meant
01:37:29sipa:with the for loop
01:37:37gmaxwell:okay, good then I came about to the same thought.
01:37:58gmaxwell:is there something that generalizes those two? are there more?
01:38:09sipa:very good question!
01:38:27sipa:but it's really about some parametrizable control flow
01:38:59sipa:oh um
01:39:09sipa:this is an expression language
01:39:17sipa:a for loop doesn't really make sense
01:39:23sipa:but you can replace it by a fold
01:39:55sipa:fold(3,f,x) computing f(f(f(x)))
01:40:04petertodd:sipa: you know, you can replace a for loop with repeated opcodes, and zlib compression...
01:40:24sipa:where that recursive hashing becomes much more apparent
01:40:25maaku:jtimon: see above ^^
01:41:00sipa:petertodd: that doesn't allow hiding the number of iterations from the root hash
01:41:02jtimon:"Combinators in Joy behave much like functionals or higher order functions in other languages, they minimise the need for recursive and non-recursive definitions."
01:41:45jtimon:maybe it's relevant although I'm starting to get tired and following your interesting conversation gets harder
01:41:52petertodd:sipa: ah, your example of a for loop is to loop based on a stack constant, not a symbol constant?
01:42:14sipa:petertodd: based on a constant given in the spending script
01:42:24petertodd:sipa: yeah, that's different
01:42:30sipa:petertodd: but NOT given in what goes in the root hash
01:42:44gmaxwell:fundimentally the _maximum_ depth of the loop could be hidden. (mean I can describe a language that allows this)
01:42:45petertodd:sipa: yup
01:43:32sipa:yes, you need to know a maximum iteration count
01:44:30sipa:but you don't have to reveal it
01:45:46gmaxwell:might be interesting to describe a hash based winternitz compressed signature in this language, assuming there exists an OP_PUSH_TX_HASH ... I propose that if our choice operator(s) are good then a maximally efficient winternitz signature will be completely natural.
01:46:49sipa:.. you lost me
01:47:35gmaxwell:sipa: you know how a lamport signature works, right?
01:48:49sipa:more or less, yes
01:48:55gmaxwell:for each message bit x, reveal either preimage_x or H(x) depending on if the message bit is 1 or 0. The public key is just the root hash over this data.
01:50:25sipa:i need to see that on paper
01:50:27sipa:but now now
01:50:47gmaxwell:winternitz optimization: take your message bits in groups of— say— 4 bits. so your 256 bit message becomes 64 4 bits words. you have then 64 preimages. H( ... 16hashes total ..H(H(preimage_n))) and your message word selects how deep in this structure you reveal.
01:51:31sipa:so you weigh a smaller signatures over deeper hashes
01:51:59gmaxwell:that bit itself isn't secure, since someone could find another message where all the words had higher values than your message, but you can add a couple more checksum words, e.g. 3 for the case of 64 words. with their heights set to a sum of the others such that you can't reduce any of the message words without increasing at least one of checksum words.
01:52:13gmaxwell:in any case, that covers both the kinds of branching we've talked about.
01:54:03gmaxwell:so I suspect that if our language is done well, it actually reduces to one of these hash signatures... it's just doing some extra execution along the way. :P
01:54:21gmaxwell:or at least these signature schemes should express themselves very naturally in the script.
01:57:09gmaxwell:sipa: so here is another kind of 'choice': a choice where the permitted script is provided by the ScriptSig, validated by a key provided in the script and a checksig instead of a hash in the script.
01:57:15sipa:gmaxwell: actually, that fold operator can just be encoded using choice
01:57:49sipa:at every iteration you do a choice that just contains another instance of f
01:57:51gmaxwell:choiceL( choice(choice()))
01:58:38sipa:of course, if you provide a normal language construct for fold
01:58:47sipa:as an optimization
01:59:00sipa:you could provide a merkleizing one too
02:01:38gmaxwell:adam3us: So, is there a way with ECDSA, given three messages pick a pubkey,r,s such that pubkey,r,s is a valid signature of any one of the three messages?
02:02:25gmaxwell:I guess pubkey,r,s isn't going to be smaller for just three. Alas.
02:02:38gmaxwell:(so much for my ghetto homorphic hash idea. :P)
02:19:56jcrubino:is there a workbook for bitcoin wizards in training?
02:22:29gmaxwell:No. I suppose I should make a references list?
02:22:40gmaxwell:a lot of the things we discuss have no references though.
02:22:58gmaxwell:E.g. I can't cite anything for merkelized abstract syntax trees.
02:25:44enodios:enodios has left #bitcoin-wizards
02:30:03sipa:roconnor came up with those in an IRC pm with me :)
02:44:13petertodd:jcrubino: I keep threatening to write a book
02:44:30jcrubino:petertodd: I'll help
02:44:44jcrubino:Is it possible to download the dev mailing list from source forge?
02:45:09petertodd:jcrubino: I don't think so
02:45:15petertodd:how far back do you want?
02:47:43jcrubino:As far back as can be got
02:47:48jcrubino:I would like to do this: http://www.princeton.edu/~achaney/tmve/wiki100k/browse/topic-presence.html
02:47:53jcrubino:for the mailing lists
02:48:48jcrubino:tldr: topic modeling of the message contents
02:49:28petertodd:jcrubino: I've only got just under a years worth
02:50:48jcrubino:I could post to bitcointalk to ask for donations; but not sure how uniform they will be comming from different mail clients
02:51:05petertodd:jcrubino: well, test should be same I guess?
02:51:13petertodd:you can compare against different peoples copies by message id
02:56:17jcrubino:petertodd: how close to live release is mastercoin?
02:56:37petertodd:jcrubino: it has been released, for some value of "release"
02:56:52petertodd:jcrubino: there's live code out there that lets you move mastercoins around - is that useful however? good question
02:56:57jcrubino:true enough
02:57:45jcrubino:I was going to ask what is going to be the first real workd use case and then I remembered Willets original slide presentations
02:58:24petertodd:...and what did you remember?
02:58:29jcrubino:A better question then is how far is bitcoin from 2.0?
02:58:41sipa:we're not even at 1.0...
02:58:44jcrubino:The good and the bad; he included it all
03:01:47jcrubino:sipa: will we have no idea what 2.0 will be untill we get there?
03:02:04sipa:i suppose
03:02:05petertodd:jcrubino: huh, interesting view of it... I'd say JR didn't include much at all, at least from what I remember
03:02:20petertodd:jcrubino: there will be multiple competing 2.0's is my prediction
03:05:53jcrubino:ok wizards what is the most important thing to grok about bitcoin at the protocol level for wizards in training to be effective developers?
03:07:20sipa:i doubt wizards are a subser of developers
03:07:39sipa:here it's much more about things that are cool to think about, beyond-bitcoin
03:07:47sipa:some that may be far from ever being implemented
03:08:44sipa:i see myself much more as a developer than as a wizard (mostly because of lack of time to keep up...)
03:09:37petertodd:sipa: agreed, and in the exact opposite situation personally
03:11:05andytoshi:jcrubino: the first reference i was given here was about random oracles, and that led me through a very enlightening reference chase:
03:11:06petertodd:jcrubino: I think the most fundemental thing I've discovered is the concepts of how mining can be separated into timestamping and proof-of-publication
03:11:37andytoshi:also see the fiat-shamir paper and 'probabilistic encryption' by goldwasser and micali
03:11:55andytoshi:if you can grok all those, that's enough background to ask intelligent questions re the crypto discussion
03:12:54andytoshi:petertodd: you have a writeup about this which i think is a very concise introduction to that idea
03:13:09andytoshi:i've lost the link and i didn't actually read it the first time, but that was my impression from the first few paragraphs :P
03:13:43petertodd:andytoshi: thanks
03:13:55jcrubino:thank you all, looks like some great reads
03:14:12petertodd:andytoshi: and I think that good writeup is also another important wizard lesson about Bitcoin: it's actually got very little to do with cryptography as you normally think of it
03:15:24andytoshi:petertodd: agreed, the regular crypto is necessary to banter about specific signature schemes (and to understand security models), but distributed consensus is its own field
03:17:16andytoshi:people here are very good at designing protocols which use bitcoin as a secure timestamp oracle, something i haven't quite got the hang of
03:17:26petertodd:andytoshi: yeah, and furthermore *decentralized* distributed consensus is it's own field again, notably a field where discussions of things like politics actually are relevant
03:19:34andytoshi:petertodd: yeah, i had a non-bitcoin-related political discussion earlier today and i realized that my naive libertarian beliefs have been greatly changed by discussion here about incentive structures in decentralized systems
03:20:01andytoshi:at that distance, i suppose it's just game theory, but decentralized distributed consensus systems give a very efficient model of this
03:20:27andytoshi:where a lot of the noise of human interaction is removed (by design) thanks to the trustless protocols
03:22:24petertodd:yup, and a very unforgiving model too, where you get to deal with relatively non-ideal participants
03:22:38gmaxwell:well when you spend a lot of time thinking in an adversarial model it changes how you think.
03:23:22gmaxwell:Normal thinking is strongly biased to thinking about the common cases, adversarial model thinking is biased to spend time thinking about the worst possible outcome.
03:25:30petertodd:which is what the non-wizards find so hard to deal with - witness the discussions of GHas.IO for instance
03:29:40gmaxwell:petertodd: I've found it interesting that people think there is no issue, then they get this "51% attack" idea in their head and think that like— if ghash.io gets 51% then suddenly all the bitcoins will be theirs— and then that misconception is removed and they're back to saying that there is no issue at all.
03:30:13gmaxwell:I guess this happens with all things. Foo causes cancer! No it doesn't. Oh great! Everyone eat foo! Wait wait.
03:30:55petertodd:gmaxwell: suggests to me that people don't really understand the nature of the signatures in transactions, heck, likely they don't understand them at all
03:31:43CodeShark:most bitcoin users still probably believe that their bitcoins actually reside on their own computers and that addresses are where they are actually kept
03:32:18petertodd:CodeShark: oh, that's a good addition to the -wizards basic training list: understand semiotics and the distinction between sign, signified, and signifier
03:32:22gmaxwell:CodeShark: well the whole question of 'residing' deserves a Mu.
03:35:21gmaxwell:The answer "in the blockchain" is also wrong thinking— what happens if a blockchain is MMR compressed and only you have the data to prove your coins exists? Is it back in your possession now? What if that data has been further split into multiple parts with an error correcting code and spread to multiple machines. Now where does the coin reside?
03:35:34andytoshi:gmaxwell: oh, Mu is a very clean answer, thanks
03:36:18petertodd:gmaxwell: a good counter-question to that falicy is to ask people where does the song "Happy Birthday" reside exactly?
03:36:21andytoshi:gmaxwell: i spent an hour with a math grad the other day describing various cryptosystems and asking "where is the information stored"?
03:36:24gmaxwell:(and of course even ignoring MMR and whatnot wizards wank, it's kind of surprising to say something "resides" someplace public but can't be taken from there by anyone with access)
03:38:02gmaxwell:But also equally insane to say something like a coin resides with its private key, when the private key could be on a relativistic rocket and forever causually disconnected from any payments to it... :)
03:39:50gmaxwell:Fact of the matter is that we use analogies to understand thing by approximation. But there is no need that the (best) analogies need to be physically intutive, in fact basically all of higher mathmatics is about manipulating abstractions which are in no way physically intutive.
03:40:05petertodd:gmaxwell: also equally insane if you postulate an insecure signature algorithm that can be broken with 2^64 work
03:41:36petertodd:gmaxwell: I'll add to my wizards list that if you successfully got through a hard first year calc/analysis course with emphasis on proofs you're going to understand crypto-currencies much better
03:42:19gmaxwell:well, either that or it broke you completely and you're unable to reason without a pile of symbology in front of you.
03:45:42petertodd:gmaxwell: probably a good thing I failed second year calc - the alternative was to be broken by it
03:46:14andytoshi:petertodd: second year calc is crap, it has no business being in a math degree
03:47:06petertodd:andytoshi: what did you do in second year calc?
03:47:43andytoshi:petertodd: half a dozen methods for computing second-year-calc integrals, and something about taylor series i think
03:48:06andytoshi:standard calc 2 fare, "here are some algorithms, run them by hand without ever checking hypotheses, hundreds of times"
03:48:42petertodd:huh, we did taylor in first year; second year was all about multi-variable versions of first year stuff, as well as a bunch of set theory stuff
03:48:43andytoshi:mathematical analysis was probably more difficult, but made far far more sense and was better motivated
03:49:20gmaxwell:I like that they don't even bother teaching people the chain rule in basic undergrad calculus anymore apparently.
03:49:37andytoshi:(analysis is when i switched into math honours and decided to take my degree seriously .. and also where i met my girlfriend :P)
03:49:49petertodd:gmaxwell: wtf?
03:50:09petertodd:andytoshi: typical, impressing a girl...
03:50:10andytoshi:gmaxwell: they do at UTexas at least ..
03:50:46gmaxwell:andytoshi: whew. okay perhaps I was just talking to idiots then.
03:51:38andytoshi:petertodd: that's pretty-much it, a bit ironic that now i'm in grad school 2500km away from her
03:52:02andytoshi:gmaxwell: i'd guess so, first-year calc only has 3-4 derivative rules plus a collection of limit stuff, there isn't much room to trim
03:52:41petertodd:gmaxwell: this is the second year calc curriculum that I took: Sequences and series. Uniform convergence. Convergence of integrals. Elements of topology in R2 and R3. Differential and integral calculus of vector valued functions of a vector variable, with emphasis on vectors in two and three dimensional euclidean space. Extremal problems, Lagrange multipliers, line and surface integrals, vector analysis, Stokes theorem, Fourier series, ...
03:52:47petertodd:... calculus of variations.
03:52:48andytoshi:well, UT has room to trim, there's a ton of theoretical stuff that doesn't connect properly, so the course feels very rushed and confused
03:52:57andytoshi:petertodd: holy shit
03:53:09gmaxwell:andytoshi: I think this is because they don't teach differentation in algebra classes, but instead just teach people a bunch of rules which actually are differentiation, but don't explain why they work?
03:53:37petertodd:gmaxwell: first year was this: A theoretical course in calculus; emphasizing proofs and techniques, as well as geometric and physical understanding. Trigonometric identities. Limits and continuity; least upper bounds, intermediate and extreme value theorems. Derivatives, mean value and inverse function theorems. Integrals; fundamental theorem; elementary transcendental functions. Taylors theorem; sequences and series; uniform convergence and ...
03:53:43petertodd:... power series
03:54:15petertodd:gmaxwell: well, almost, they changed the curriculum around and moved more of what I was taking into the harder class (that's the harder classes current description)
03:54:17andytoshi:gmaxwell: i think that's right, i explain to my classes what they are actually doing, and they (a) appreciate it and (b) act like they were completely unaware of it before
03:54:18petertodd:instead just teach people a bunch of rules which actually are differentiation, but don't
03:54:27petertodd:andytoshi: heh, I don't feel so bad failing it then :)
03:55:16petertodd:andytoshi: the hard version of second year is this: Topology of Rn; compactness, functions and continuity, extreme value theorem. Derivatives; inverse and implicit function theorems, maxima and minima, Lagrange multipliers. Integrals; Fubinis theorem, partitions of unity, change of variables. Differential forms. Manifolds in Rn; integration on manifolds; Stokes theorem for differential forms and classical versions.
03:55:22andytoshi:petertodd: that's a serious calc sequence, what you listed was calc 1/2/3/4, two analysis classes, a variational calc class, and a bit of a third analysis class
03:55:52andytoshi:not that my school was terribly difficult, i spent the latter half of my undergraduate doing reading courses with professors instead of the standard sequence..
03:56:02petertodd:andytoshi: ha, lovely, and I did that after like six years doing a fine arts degree
03:56:18petertodd:andytoshi: that's UofT fwiw
03:56:53andytoshi:petertodd: wow, good to know then
03:56:59nessence:* nessence wonders how many UT folks are @ cointerra
03:57:11andytoshi:i was told that grad students who go there teld to be unhappy, that the profs don't pay attention to them..maybe this is why
03:58:40petertodd:andytoshi: interesting - the teachers in first year weren't very good, and second year downright atrocious. You literally had TA's who were too shy to speak to students and spend the whole class facing the chalk board mumbling.
03:58:51jcrubino:petertodd: your my hero now with your calc story
03:59:21petertodd:jcrubino: lol
03:59:33andytoshi:petertodd: fwiw, at SFU we had very slow sequences as i described, then a serious problem with fourth-year students who had no knowledge of mathematics, but we had to give them degrees since we'd led them on for three years, and they'd be incomprehensibly stupid
03:59:49petertodd:andytoshi: ha! nah, uoft just fails people instead :P
04:00:03petertodd:andytoshi: first year calc we quite literally had about 90% of the class drop out
04:00:32andytoshi:yeah, that's an extreme workload especially if the teachers are all crap
04:00:44andytoshi:it'd be almost reasonable with excellent professors and TAs
04:01:35petertodd:yup, and a heck of a shock coming from art school - see, at art schools even the best in the field often take teaching jobs to earn some more money... I suspect with math it's a lot harder to attract talent on a budget
04:02:27andytoshi:yeah, generally there are rich schools who get ~2-400 applicants per year and get to choose -- then there are the rest who have perpetually open positions but terrible offers
04:02:46andytoshi:(UTexas is in the former, they accepted 30/400 applicants last semester o.O)
04:03:30petertodd:ha, uoft has 50k students
04:03:47petertodd:heck, they have more teachers then my previous school had students
04:03:51andytoshi:yes, it is very irritating when they make half the grad department TA calculus <.<
04:03:59mr_burde_:mr_burde_ is now known as mr_burdell
04:04:29mr_burdell:mr_burdell is now known as Guest84632
04:04:29petertodd:ugh, and it seems that uoft actually takes their better TAs and teachers and has them teach the easier math classes aimed at the non-math students
04:04:43andytoshi:16k math students, 8k in the calculus sequences in any given semester, which means around 80 calc TAs i guess
04:05:07andytoshi:( UTexas has similar total numbers to UofT i think)
04:05:15petertodd:probably about right
04:05:44andytoshi:petertodd: ugh, that's terrible
04:07:43petertodd:andytoshi: heh, well I still managed to learn enough from it to have some hope of learning more math :)
04:08:46Guest84632:Guest84632 is now known as mr_burdell
04:09:26andytoshi:very true, i was suprised to hear you (and gmaxwell) have so little formal math education
04:09:53andytoshi:i guess i don't really either, i have the papers but the upper-division part of my degree was almost entirely reading courses
04:10:05petertodd:gmaxwell is way ahead of me with math you know
04:10:21andytoshi:and i did a grad course in QFT, i had a fun time explaining to the physics chair who i was and what i was doing there :P
04:11:15gmaxwell:I don't know anything, but seeing as how I don't know anything I am also not afraid of anything.
04:11:15petertodd:decentralized consensus systems are probably the only "theoretical" branch of crypto I'll ever have a hope of coming up with new ideas in - notice how even my intuition for things like how ECC signatures work is relatively shakey
04:12:36petertodd:andytoshi: lol, quantum anything just sounds scary, and relatively useless :P
04:12:55andytoshi:petertodd: i did not notice that, your blockchain/MMR stuff is so advanced that i assumed you were a math/cs genius :P
04:13:21andytoshi:petertodd: quantum field theory is -very- shakey, it was a great course to learn what physicists are up to but i knew i didn't want to deal with it after that
04:13:38andytoshi:scott aaronson has somewhat changed my mind on that point tho, to the extend that he calls what he does "physics"
04:14:03gmaxwell:everything understandable to more than a few people is understandable to almost everyone if approached from the right perspective.
04:15:03petertodd:gmaxwell: +1
04:15:24andytoshi:gmaxwell: that's my feeling, i've managed to explain SNARKs on a conceptual level to people who haven't had any experience with crypto
04:15:44andytoshi:they have to let me talk for two hours about cryptography, though, so maybe i'm filtering people..
04:15:46petertodd:andytoshi: lol, I keep on thinking "what the fuck symbol am I supposed to use for foo?"
04:15:59petertodd:andytoshi: every time I try to write anything vaguely resembling a paper
04:16:14petertodd:andytoshi: were they smoking pot at the same time?
04:16:15andytoshi:petertodd: haha, that's the worst part
04:16:32andytoshi:petertodd: in one case, yes, he was the guitarist of a band at the bar near the math dept
04:16:51andytoshi:he kept getting ahead of me tho, and it turned out later that he had a tech startup 30 years ago and walked away with millions to play guitar..
04:17:03andytoshi:so i think he might've secretly known it all
04:17:42petertodd:andytoshi: it's so much easier in analog electronics... oh wait, I took MIT's second year course on that... :P
04:18:04petertodd:andytoshi: damn!
04:19:30petertodd:andytoshi: you know, it's interesting how many former comp-sci/physics/math/etc students you find in art school - I met easily two dozen, including ones that had pretty substantial degrees.
04:20:15andytoshi:interesting - in math departments, almost all the really good students are musicians, and some are even art school dropouts!
04:20:31petertodd:andytoshi: oh! I never met anyone with an art background at uoft
04:21:06petertodd:andytoshi: well, there was one cute girl who had been reluctantly pushed into biology by her parents in a physics class :P
04:21:25andytoshi:petertodd: nice :P
04:21:52petertodd:andytoshi: every day she dressed like she was going to some kind of anime con
04:22:19gmaxwell:to be fair, music may be far too practical for some mathematicians I've met…
04:22:43petertodd:andytoshi: although what was more sad I thought was the sheer number of med students in that class trying desperately to impress admissions to residency or whatever it is exactly :(
04:23:09andytoshi:petertodd: ugh, we had those at SFU too, it was so competitive and so sad
04:23:42andytoshi:but i like this talk of anime con girls, my gf took me to a con once and it there were a lot of them there :)
04:23:45petertodd:andytoshi: did you ever take any summer classes? this was in the summer...
04:24:51andytoshi:petertodd: yeah, one summer i took a variational calc class -- and joined the physics soccer team -- i met a few med students then
04:25:12petertodd:andytoshi: heh, what's funny about it is she was in first year, and I'll bet you had she gone to ocad like she wanted she would have quit that by second year in favor of being a hipster
04:25:38petertodd:andytoshi: exactly
04:26:52andytoshi:petertodd: yeah, in general i found the students at university should not have been there
04:27:30andytoshi:they'd really drag down the classes in later years, hence my retreat to graduate classes -- fortunately i was friends with enough faculty by then that there was no trouble with that
04:27:56petertodd:ah that sucks
04:28:09andytoshi:so my feeling is that uni in general is not a great decision if you want to learn things, better to meet the right people and work with them
04:28:11petertodd:yeah, I've never had any experience with the non-art university environment
04:28:15andytoshi:e.g. #bitcoin-wizards
04:28:49petertodd:yup, which is actually pretty much how my art school went - although the flip side of that is they've got a huge failue rate
04:29:25petertodd:but what's interesting, is the post-graduation outcomes, like employment, are surprisingly good, even compared to stuff you think is a good bet like engineering and medicine
04:29:32comma8:comma8 has left #bitcoin-wizards
04:30:17andytoshi:yeah, i've heard that -- and the art students i've met tend to be more open-minded and intelligent-seeming than a lot of math/science folks
04:30:33andytoshi:why the failure rate tho? do people give up or is it really difficult?
04:30:33justanotheruser:petertodd: are you an art major?
04:30:34petertodd:yup, and people skills goes a long, long way in our economy
04:30:37petertodd:justanotheruser: yup
04:31:07justanotheruser:petertodd: what do you do that is artistic
04:31:39petertodd:andytoshi: people find it hard to deal with the lack of structure is a part of it I think - art school has this weird existential dread to it where you know you have to keep on coming up with new art to succeed, but there's no magic solution to doing that
04:32:45petertodd:andytoshi: and you've got a very unforgiving social environment that's incredibly elitist, as it should be (though that's not necessarily typical - my school had a reputation for that)
04:32:49gmaxwell:in 1970 college enrollment was ~50% of highschool grads in the US, it's ~70% now.
04:33:36andytoshi:petertodd: that does sound scary, though i can see why the same sorts of people end up in math departments
04:33:37midnightmagic:i woukd be curious to know whether those include the new vocational colleges that have started calling themselves colleges..
04:33:55petertodd:gmaxwell: sounds like a bubble
04:34:05gmaxwell:midnightmagic: no.
04:34:45petertodd:andytoshi: well, to what extent are those departments like that as research becomes more of a focus?
04:35:20andytoshi:petertodd: it's directly correlated to research, the people doing plug-and-chug degrees weren't artsy at all
04:35:23petertodd:andytoshi: I mean, research can easily have that same kind of treadmill to it
04:35:36andytoshi:yeah, that's absolutely the way it seems to me
04:35:37gmaxwell:petertodd: well I believe that it was in the early 70s that the US government privitized sallie mae and made it so you couldn't discharge student loan debt in a bankrupcy.
04:35:37petertodd:andytoshi: ah, yeah, plug-and-chug has it's own kind of pain I think
04:35:59petertodd:gmaxwell: good point, and they're pretty good at recovering the money, eventually...
04:36:57andytoshi:gmaxwell, petertodd: the student debt situation is a bubble i think, but i've read the first few chapters of the bell curve (1994) which has some scary stats about school enrollment and IQ stratification which suggest that high enrollment rates are not all bubble..
04:37:09gmaxwell:petertodd: they only have to recovery a small portion of it if they inflate tuitions, made possible by tsunamis of money enabled by the lender favoring law...
04:37:18midnightmagic:yay flynn effect
04:38:24petertodd:midnightmagic: people who complain about "all those dumb poor people" mating with each other forget that if you're at the other end of the spectrum, having a smart partner is strongly selected for
04:38:32gmaxwell:I'm sure there are plenty of papers on largely debt based economies and the relative rates of bubbles in them.
04:39:12midnightmagic:petertodd: mm.. not so sure about that. engineers mating withe ngi eers appears to select for autism. additionally, genetic issues with ashkenazi
04:39:38petertodd:andytoshi: well, it could be both true that the high enrollment rates are perfectly justified, and it's a bubble, not to mention that the whole industry could change rather drasticly with these efficient online courses (that MIT EE class was great, and free...)
04:40:16andytoshi:midnightmagic: the bell curve talks about this, there is a real selection effect which appears to be increasing IQs amongst part of the population almost as fast as it is decreasing amongst other parts
04:40:17petertodd:midnightmagic: yeah, sounds like very strong evidence for selective mating to me...
04:40:34petertodd:midnightmagic: note that autism is a spectrum...
04:41:11andytoshi:s/almost as fast/faster, but amongst fewer people/
04:41:11midnightmagic:andytoshi: If the research I read is correct, they're destroying their own genetic viability longterm.
04:41:29andytoshi:midnightmagic: let's hope not, they're doing all the crypto research :P
04:41:57petertodd:midnightmagic: and speaking of, when I was a kid my mom had a tutoring/babysitting business that specialized in austistic kids - I ended up hanging around with a heck of a lot of them, and their parents, and it's remarkable how many were comp-sci/engineering
04:42:10andytoshi:midnightmagic: there has a general theme amongst human development of "intelligence overriding medical problems", so personally i am not too worried about such things
04:43:05midnightmagic:mm.. fairly confident that environment nutrition and opportunity are stronger than plain genetics in success. but i'm on my ipad so i can't build a cite frok my zotero library
04:43:39petertodd:andytoshi: that modern culture rejects racism so strongly also gives a chance for genes to be spread across large chunks of the population limiting the worst effects of all this stuff
04:44:36gmaxwell:midnightmagic: I've seen papers on that subject, environment/nutrition/opportunity are so correlated with the parents they're almost completely colinear, any paper that claims to control for that is basically just reporting on the outliers by definition.
04:44:45midnightmagic:(absent actual genetic problems anyway)
04:45:01gmaxwell:unless they plan on doing a controlled study, which has ethical problems.
04:45:36gmaxwell:(its not like we have enough twins data, especially enviromentally distinct twins data, to really say a ton about nature vs nuture)
04:46:08petertodd:midnightmagic: I'm pretty skeptical of anyone who tries to claim modern societies are all that bad at providing everyone with opportunities
04:46:18midnightmagic:gmaxwell: the last study i read from u of.. illi ois? compared like to like re: private and public schools and came up witht he remarkable conclusion that public schools on the whole educated better, while private schools benefitted significantly from the rich person advantages.
04:47:03midnightmagic:petertodd: I have a sociology department or two who would disagree witht hat :-)
04:47:26petertodd:midnightmagic: define "educated better"
04:47:31andytoshi:midnightmagic: right, and they're sitting comfortably in sociology departments instead of on the street, despite having no skills ;)
04:47:44petertodd:midnightmagic: and remember, I spent enough time at arts school to know sociology is often full of shit :P
04:48:04midnightmagic:petertodd: they measured that which was measurable: mathematics improvements between entry and exit grades for schools
04:48:35midnightmagic:.. lol now now. the research they do is better than forming opinions in a vacuum
04:48:36petertodd:midnightmagic: ah, so they measured improvements, who had the higher scores exiting?
04:49:11gmaxwell:petertodd: not all opportunities are equal to all. I mean sure, some child of some inner city gang bangers could have traveled 4 mi the the nearest library with internet access back in 2010, and joined #bitcoin and written some bad poetry for a thousand bitcoin and be a millionaire now. But none did.
04:49:20midnightmagic:petertodd: public schools had grrater improvements when co paring identical students with identical backgrounda.
04:49:40petertodd:midnightmagic: just as easily you can explain that as private school kids started off smart and couldn't be educated much farther, or more importantly, they had better things to do with their time than focus on math improvements
04:50:07midnightmagic:petertodd: nope. they selected those ones out
04:50:17justanotheruser:midnightmagic: are you saying that schools should be segregated by income?
04:50:35gmaxwell:justanotheruser: they are already segregated by income.
04:50:46midnightmagic:as much as it's possible to know such things, there's now basically zero reason to think private schools provide a better education
04:50:54justanotheruser:gmaxwell: they bus students from poor schools to rich schools in some states
04:51:09midnightmagic:justanotheruser: nope. i'm saying private schools are lying when they claim to provide superior education
04:52:13petertodd:gmaxwell: heh, well, OTOH I know a guy from nairobi who did something not unlike that... moral of the story is raw opportunities actually don't do much in the face of culture and parents, and those are likely strongly geneticly related in many ways anyway.
04:53:03gmaxwell:okay, sure, I was also binning culture and parents in with opportunities. It's not like its your fault what parrents you had.
04:53:33midnightmagic:yes. adoptions help a lot with those kinds of studies too.
04:53:59midnightmagic:pretty fascinating how much people seem to be screwed if born to poor parents.
04:54:06petertodd:gmaxwell: yup, my point being blaming "society" for that kind of thing is misguided - we already do a tremendous amount
04:54:21gmaxwell:::shrugs:: part of creating an optimally successful society is providing the infrastructure that helps people achieve their capability even if they're born into a dysfunctional family (and help family dysfunction not exist).
04:54:21petertodd:midnightmagic: gee, might have something fundemental going on...
04:55:31midnightmagic:petertodd: yeah, probably not straight genetics. some is, but parentage makes up for a lot of that. i.e. the success breeds overconfidence false loop
04:55:40petertodd:gmaxwell: yup, and frankly I *do* think we do a very good job of that and it's hard to figure out how to actually do a better job of it in most situations. I also think our effects, especially in schools, to further level the playing field are counter-productive - e.g. closing gifted programs in favor of yet more money at the lowest scoring percentile.
04:56:11midnightmagic:imo that kind of nonsense is b-s
04:56:25midnightmagic:closing gifted student programs?! wtf
04:57:19gmaxwell:well you are in canada. So perhaps things are better done there. :)
04:57:46midnightmagic:i'll let you know. i personally appear to be one of those weird outliers.
04:58:23gmaxwell:midnightmagic: "no child left behind" (a 2001 piece of education legislation and the resulting programs) in the US is often wryly refered to as "no child gets ahead"
04:58:35petertodd:midnightmagic: well, that's how the politics of it works. I know the people running the program where I lived then fought for years to keep it open, and always had to be very careful as to how it was portrayed - specifically they stressed heavily how the kids who were in the program statisticly did *worse* than the general population for a lot of different metrics, such as university admissions.
04:59:15petertodd:midnightmagic: basically anything to avoid looking elitist
04:59:25midnightmagic:s art kids need a challenge or their study habits are nonexistent. yeah that makes sense what you're saying.
04:59:25gmaxwell:Se also: http://en.wikipedia.org/wiki/No_Child_Left_Behind_Act#Effects_on_school_and_students
04:59:50gmaxwell:er see*
05:00:03petertodd:midnightmagic: heh, well with a challenge that was true too, but anyway :P
05:00:11andytoshi:gmaxwell: i can say from personal experience that public schools in BC are not run effectively, they are very much "no child gets ahead" and they were an absolute hell to get through
05:00:20gmaxwell:I know a number of _good_ high-school teachers who left teaching due to the effects of that legislation.
05:00:41petertodd:gmaxwell: can't blame them, that stuff is just depressing to deal with
05:00:44midnightmagic:andytoshi: you think so? i had the exact opposite experience in BC
05:01:26andytoshi:midnightmagic: i was in cloverdale, it is the cowboy town beside langley, they had no gifted programs
05:01:46midnightmagic:vancouver. interesting.
05:02:22andytoshi:midnightmagic: i finished every hs math class by the end of grade 9, then no more math. 'science' was watching bill nye videos and doing handouts, i was typically done the work for the day in about 15 minutes, then 6 hours or so of staring at walls
05:02:24midnightmagic:i was in the interior, they specifically pushes the smart kids into beneficial grade programs for university entrance.
05:02:40andytoshi:midnightmagic: eventually i found some good teachers who helped me game the system, and i got out 18 months early
05:02:54petertodd:andytoshi: ha, ironic how my highschool was a "inner city" one with a population of almost entirely recent immigrants, very pool, with significant gang violence and... I had a much better experience
05:03:14andytoshi:2 years early* i stuck around to finish my phys. ed. requirements :P
05:03:35andytoshi:so i don't count that semester as hs
05:03:43petertodd:andytoshi: and then my brother was in a hs in one of the richest parts of the city, upper-upper-middle-class, and... actually lots of gang violence *in* the school, and shit academics.
05:03:53andytoshi:petertodd: fascinating
05:04:03andytoshi:there is a lesson here about anecdotal evidence i'm sure :)
05:04:14midnightmagic:my hs teachers did the optional calculus prep stuff. probably for my specific benefit actually, the rest of the kids were rolling their eyes.
05:04:17andytoshi:maybe we should apologise to midnightmagic for calling his sociologists stupid
05:04:23petertodd:andytoshi: hehe, toronto is not a good source of typical demographic data :)
05:04:30midnightmagic:lol a.k.a. my wife.
05:04:45midnightmagic:no apology necessary, it's a well studied ohenomena.
05:04:53midnightmagic:er.. *non
05:05:42petertodd:andytoshi: over 50% of the toronto population wasn't even born in canada
05:06:06midnightmagic:well, without immigration our pop would be shrinking. :-)
05:06:14midnightmagic:would suck if canada died.
05:06:22andytoshi:petertodd: this is true of vancouver as well, though probably not in cloverdale where i was
05:06:36gmaxwell:Oh I GEDed out of school the moment it was permitted, in florida by statute the GED is absolutely equivalent to a highschool diploma— you even get the same paper the normal graduates get. Was kind of of no brainer. I took the test cold two days after my birthday (earliest time offered) scored a 99th percentile. It was trivial stuff. ::shrugs:: I understand that it wasn't too uncommon to do this in the 70s but the schools fought ...
05:06:43gmaxwell:... back against it with a bunch of FUD because it was draining them of their most academically capable students.
05:06:55andytoshi:oh, cloverdale is right above white rock, from silk road hitman fame :)
05:07:03andytoshi:so i'll stop saying 'near vancouver' here
05:07:20petertodd:andytoshi: what's the kind of immigrants that vancouver gets anyway? asia? middle-east?
05:07:27midnightmagic:andytoshi: i'm confident nobody thinks you're that guy lol
05:07:32midnightmagic:ha ha ha awesome
05:07:52midnightmagic:petertodd: asian, then east indian
05:07:54gmaxwell:I was impressed by the density of asian people in vancouver.
05:07:54andytoshi:petertodd: east asia, mostly china and phillipines, then india
05:08:05petertodd:gmaxwell: sheesh, that kinda sucks that you were in a position where that made sense
05:08:12midnightmagic:richmond doesn't even have english signage in some places.
05:08:57petertodd:andytoshi: oh, interesting, toronto seems to get much more from the middle east
05:09:04midnightmagic:gmaxwell: how old were you re: GED?
05:09:11midnightmagic:(wife is curious)
05:09:18petertodd:andytoshi: OCAD had a *tonne* of Iranians for instance
05:09:23andytoshi:gmaxwell: that's awesome, i wish i had that option
05:09:32andytoshi:maybe i did, it didn't occur to me
05:10:06midnightmagic:i skipped a grade, grad'd at 17. skipping a grade was really horrible. not recommended.
05:10:32midnightmagic:petertodd: what's OCAD?
05:10:34andytoshi:petertodd: interesting, i've only met one iranian
05:10:41petertodd:midnightmagic: I think one of the things the gifted program did a good job at was giving kids reasons not to skip grades...
05:10:47midnightmagic:I love Iranians they're awesome
05:10:54petertodd:midnightmagic: http://www.ocadu.ca/ <- art school I went too
05:10:58andytoshi:midnightmagic: lol, i formally skipped two grades, but my attendence was ~0 so it didn't matter, just let me get out earlier, so i'd recommend it
05:11:00midnightmagic:oh cool
05:11:18petertodd:andytoshi: huh, must be a regional thing that they settle in Toronto
05:11:31andytoshi:midnightmagic: agreed re iranians, the one guy i know is so much fun
05:11:55gmaxwell:Its not something that was widely publicized, I think I only knew it was possible as a result of talking to some prof at the local community college who'd done it himself in the 70s... I caused a number of other people to do it.
05:12:03petertodd:andytoshi: also people from Iraq, Palestine, Afghanistan etc.
05:12:35midnightmagic:then again I personally have never met a single US'ian I didn't love so.. dunno if I'm just a people lover or plain lucky
05:13:22andytoshi:petertodd: cool, also know only one iraqi, two afghanis, no palestinians.. vancouver is all east asia and india
05:13:42petertodd:midnightmagic: it's interesting just how much iran has changed for so many of the iraneans I know - practially a different country now compared to the 70's or so
05:13:46midnightmagic:yunan province chinese are awesome
05:13:58petertodd:midnightmagic: most of the ones I knew had grown up here - it was their parents who fled
05:14:13midnightmagic:* midnightmagic tries to think of a people that irritate him and fails.
05:14:22petertodd:midnightmagic: aussies?
05:15:05midnightmagic:petertodd: Hrm, yeah maybe. There's some weird misogyny stuff going on there. But NZ make up for it
05:15:25petertodd:good, cause my mom's an aussie, and my brother lives there :P
05:16:17midnightmagic:my cousin is marrying an aussie, he's like the ultimate man's man, great guy
05:16:54midnightmagic:(in the awesome way, not the chauviniat way)
05:16:55petertodd:sounds about right
05:18:41petertodd:actually the one group I didn't like at ocad was about half of the Jews from Israel - see, one half left Israel because they couldn't stand the violence, and the other half left Israel because they couldn't stand the violence... and you'd, roughly speaking, have one half of that group be "peachniks", and the other half be downright frightening if you ever got them talking about the security of Israel. Very bizzare in the context of an art ...
05:18:47petertodd:... school to say the least.
05:19:31petertodd:Really good example of how utterly polarizing that issue can be with people unfortunately. :(
05:30:17gmaxwell:At the IETF many of the Israel folks are super duper heavy pro-surveillance-state (enough that its conspicuous). I've observed this create some pretty awesome dissonance in hallway conversation with americans of jewish dissent. "Goverment tracking and logging everyones activity, surely there is no historical precident for the abuse of this kind of infrastructure!"
05:34:50petertodd:gmaxwell: ha, sounds about right. Really bothered me the one time I heard one of the more militant of them talk about the "Palestine problem" as something that needed a final solution.
05:35:24gmaxwell:Final Solution. Get the case right.
05:35:40petertodd:gmaxwell: good example of how perceived safety works too... the people I knew from Palestine, heck, even Gaza, never seemed to have that kind of hostility.
05:36:46petertodd:gmaxwell: I'll assume they were quoting Ariel Sharon, who gets quotes as saying that in lowercase. :/
05:37:17gmaxwell:I can't even pretend to understand the geopolitics there, but it is interesting to see how different social/cultural backgrounds color positions and perspectives.
05:38:50gmaxwell:I've also seen some people from places with severe organized crime and corruption problems see antisurveillance technology as problematic. In particular because the badguys there have unequal access to it, and because surveillance is _sometimes!_ successfully used against them.
05:39:01petertodd:Yeah. Really unusual that too given there were just as many Israels I ran into it who were truly passionate about the peace process and ending violence; kept running into one of my teachers at protests related to it.
05:39:35gmaxwell:I wonder how different the US perspective on the NSA might be if it were also used to root out a bit of serious corruption in government here and there.
05:40:08petertodd:I think that's a very good point: the middle-east people I knew from OCAD were the first to pick up on the NSA stuff other than tech people I knew.
05:40:52petertodd:While I've yet to hear any Russians bothered by it.
05:43:03petertodd:Of course, Toronto also had the G20, which I think *really* turned public opinion against the police locally with how badly it was handled. First time in my life that all the major papers quite direclty accused the police of lying.
05:43:24petertodd:I think that's rubbed off to survailance stuff in general, at least based on the way people seem to talk about the NSA.
05:44:33andytoshi:petertodd: where i live, there is a general distrust of the "american police state", especially since many vancouverites drive to and from seattle routinely
05:44:53petertodd:andytoshi: interesting! due to border guards?
05:44:57andytoshi:petertodd: yes
05:45:04andytoshi:the american border guards are idiots and agressive, and we all know people who've been barred from the country for trying to bring dope over
05:45:27andytoshi:about 25% of the time you are 'randomly selected' to go stand in line for several hours while they take your car apart
05:45:50petertodd:andytoshi: heh, might have something to do with my co-workers dislike too: we've had hundreds of thousands of dollars worth of really sensitive equipment destroyed by border guards pulling it apart :(
05:46:41petertodd:andytoshi: took the second occasion before they realized they'd jsut have to ship stuff by hand
05:46:46andytoshi:when i fly to the US, customs entering the US is fascinating to watch because the non-canadians have to do the police-state record-all-ten-fingerprints thing
05:47:07andytoshi:meanwhile canadians get a special treatment because they would never put up with that, and they are still hostile to the guards and vice-versa
05:47:15petertodd:andytoshi: it's canadians too sometimes...
05:47:50andytoshi:..and the poor europeans are basically being strip-searched, watching canadians glare at guards as the stand 2 inches over the line they were told to stand behind
05:48:05andytoshi:petertodd: canadian guards? driving in i have had them be assholes before, though they have never taken my car apart
05:48:23andytoshi:flying in, the "customs" process involved them asking if i went to school in the US
05:48:28andytoshi:i said yep, the guy said ok, sure
05:48:29petertodd:heck, I had a friend who tried to go into the states in the middle of summer, with her dog in her car, and they forced her to leave said dog in the car while they interregated her. The whole time they just stonewalled her as to what was happening to her dog, saying they didn't give a damn. Of couse, in reality it was just a pressure tactic and they'd let it out and gotten it some water, but...
05:48:57petertodd:andytoshi: oh, I mean they give the fingerprint treatment to canadians sometimes
05:49:10andytoshi:oh, i got that when i first got my F1 status
05:49:23andytoshi:very annoying, i'll have to replace those fingertips when i get out of school <.<
05:49:44petertodd:take up quarts glass blowing, and be clumsy
05:51:39petertodd:I was impressed with the european border control when I went to the dark wallet hackathon, which was held in an abandoned building with known cyber-terrorist Amir Taaki: didn't ask me a single question
05:51:56andytoshi:haha, excellent
05:53:04andytoshi:is amir a "known cyber-terrorist"?
05:53:51andytoshi:haha, i see, i've never read his wiki page before..
05:53:54petertodd:I sure hope so! I've got an image to maintain
05:54:34andytoshi:https://en.wikipedia.org/wiki/Amir_Taaki#Activism would certainly classify him as a terrorist in america
05:55:13petertodd:agreed, and Esperanto?! evil
05:55:18phantomcircuit:only on tuesdays
05:55:27andytoshi:that wiki page also claims he is on forbes' top 30 entepreneurs of 2014
05:55:34andytoshi:..which was published tomorrow o.O http://www.independent.co.uk/news/business/analysis-and-features/meet-the-worlds-next-billionaires--from-mashables-pete-cashmore-to-bitcoin-renegade-amir-taaki-9042710.html
05:55:50petertodd:andytoshi: um... yeah... I belive that guy when he says he's penniless
05:56:07andytoshi:oh, no, that's today's date up top, the article is a week old :P
05:57:06phantomcircuit:petertodd, im pretty sure he has at least like
05:57:11phantomcircuit:100 euros
05:57:19andytoshi:yeah, the article credits him for darkwallet, but that seems pretty hard to monetize
05:57:33petertodd:phantomcircuit: and one pair of unwashed sweatpants
05:57:41andytoshi:i assume jon matonis was involved in that list ..
05:57:47petertodd:andytoshi: lol
05:57:58phantomcircuit:petertodd, im pretty sure he has only one pair of everything
05:58:02phantomcircuit:maybe he has two shirts
05:58:32petertodd:phantomcircuit: probably both scavenged
05:59:00phantomcircuit:eh probably not quite
05:59:07phantomcircuit:maybe his mom bought them
05:59:15phantomcircuit:(that's always a good way to get new clothes)
05:59:42petertodd:phantomcircuit: works best when you're parents live in northern canada... and they invite you home for chistmas
05:59:45phantomcircuit:which is why i get a nice laugh at people accusing him of doing things for bad reasons
06:00:03phantomcircuit:it's just not how he operates
06:00:33petertodd:yup, he's very genuine
06:01:07petertodd:and you know, quite willing to take criticism, and flexible
06:19:05gmaxwell:phantomcircuit: so... seen cointerra's screenshot.
06:19:07OneFixt_:OneFixt_ is now known as OneFixt
06:19:08gmaxwell:I am boggled.
06:19:51petertodd:that's fast
06:20:19gmaxwell:because it shows it as having submitted 44k shares to eligius... but that address is not in the payout queue, nor has it been paid on the network... and its not in the list of recent miners on eligius.
06:22:11gmaxwell:the address is truncated so I can't go straight to the stats, so it's possible that it mined but not enough to be elegible for payout, but not recently enough to be in the 3 hour active list.
06:22:32gmaxwell:petertodd: it's fast, but it's supposted to be 2TH, so not that fast!
06:23:48petertodd:gmaxwell: what ASIC tech level is it?
06:24:34petertodd:ah 28nm
07:03:35phantomcircuit:gmaxwell, yeah i saw the video before they posted it
07:03:40phantomcircuit:(aren't i so cool)
07:24:44amiller:got thirty cryptocurrencies aint never been released
07:30:45phantomcircuit:gmaxwell, also it's possible they were using an invalid address, iirc eligius treats that as a donation
07:30:47phantomcircuit:Luke-Jr, ?
07:31:09Luke-Jr:I'm not seeing anything so far.
07:31:18Luke-Jr:but this query will probably take a while
07:31:22gmaxwell:Luke-Jr: well its probably not running now or it would be in the top list.
07:31:38phantomcircuit:iirc he has a share log
07:31:48Luke-Jr:looks like the share log goes back a week
07:33:14gmaxwell:... weird. well there is a date in the screenshot, also a last block
07:34:10gmaxwell:Luke-Jr: http://cointerra.com/engineering-updates-terraminer-iv-hashing-live/ pic at the bottom
07:49:44gmaxwell:phantomcircuit: it looks like with a slightly different case design they could have fit that in 2u without a problem.
07:51:10gmaxwell:e.g. potentially making it longer and turning the radiators flat. and having airflow that went >_____/
07:59:55gmaxwell:midnightmagic: if its any consolation CT is no track to deliver another never-break-even miner. Though perhaps they'll rock the world with their power usage and eventually make it back.
08:32:03gmaxwell:https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688 < looks like the othercoin thing is being sold now.
08:32:43gmaxwell:I don't have the pre-reqs or the time. But I do think that such a thing could be a valuable addition to the bitcoin ecosystem.
08:33:17gmaxwell:It's basically the digital version of the cassius coins... but allows the user to safely fill it, and electronic transmission.
08:56:58stonecoldpat:looks nice, my concern is that initially if BTC is $1k - then it will cost $350
09:01:30gmaxwell:stonecoldpat: yea, it's not viable at that price but presumably that will be fixed once it actually exists at scale.
09:03:58stonecoldpat:yeah i hope so, also looking at the video, you start the 'handshake' between devices using SMS, i'm wondering why he chose SMS and it has been a little worried (I dont know why it does yet)
09:05:52_ingsoc:Any idea why the issues 404 after page 100 on Github?
09:06:14_ingsoc:Closed issues.
09:06:30_ingsoc:Works: https://github.com/bitcoin/bitcoin/issues?page=100&state=closed
09:06:38_ingsoc:404: https://github.com/bitcoin/bitcoin/issues?page=101&state=closed
09:07:12_ingsoc:I figured it's important if anyone wants to look at the history.
09:09:14nsh:there are numbers higher than 100?!?
09:09:27_ingsoc:Yeah. :)
09:09:40nsh:i'll need to revise a lot of models :/
09:09:53_ingsoc:It's concerning because it really needs to be accessible.
09:10:10nsh:* nsh nods
09:10:17nsh:does it happen on other repositories?
09:10:28_ingsoc:I'm unsure. Let me check.
09:12:12_ingsoc:Yeah, happens on any project when it's 101.
09:12:29_ingsoc:Is there a record of this somewhere, or are all the issues only stored on Github?
09:14:51_ingsoc:If not, it's like erasing history, one page at a time. :D
09:15:16nsh:i'd suspect it's still accessible through git itself
09:15:36nsh:actually, dunno
09:16:00TD[gone]:TD[gone] is now known as TD
09:16:04_ingsoc:Not sure how to access issues using git itself.
09:16:43_ingsoc:Everyone should stop working on Bitcoin right now until we figure out how to stop erasing history.
09:19:11wumpus:you could access them one by one through the github API, and make a mirror
09:19:32wumpus:not with git itself as the issues are not part of the repository, only the code changes
09:19:43wumpus:(and commit descriptions in git itself)
09:19:50nsh:ah, right
09:20:11wumpus:so if github goes down we'd lose the discussions that happened on github
09:20:45_ingsoc:That's concerning.
09:20:56wumpus:(which in most cases is no big loss, but I suppose for history's sake you could archive them)
09:21:04_ingsoc:I want to.
09:21:16wumpus:see http://developer.github.com/v3/
09:23:16_ingsoc:Is there a simple way to get a dump?
09:23:58wumpus:I'm sure someone else already wrote a script for that
12:00:27genjix:genjix has left #bitcoin-wizards
12:14:31adam3us:12hr async conversation, caught up, a couple of comments
12:17:22adam3us:covenants/quinine scripts. I think relating to a payments ability to require transferable restrictions on the next transaction. i think this could be policy dangerous due to the virality. consider a script that requires follow-on script to have an AML id signature, a few regulations on exchanges, and policy. i understand it allows useful things like SPV coloring in chain, etc but I think satoshi script is policy safer
12:18:20adam3us:gmaxwell: "So, is there a way with ECDSA, given three messages pick a pubkey,r,s such that pubkey,r,s is a valid signature of any one of the three messages?" only 2 not 3 i think.
12:19:32adam3us:petertodd: "I think the most fundemental thing I've discovered is the concepts of how mining can be separated into timestamping and proof-of-publication" hmm might've been me that seeded that concept. or yet-another-rediscovery gmaxwell/petertodd/adam3us (i tend to get there last as i only started catch up 10mo ago)
12:47:38adam3us:petertodd: and i guess timestamp/namespace/bitcoin-ful/bitcoin-spv relation struck me in part because i thought about distributed namespace things (in the OT-like federated but reactive security + public auditability) pre-bitcoin. and you maybe because you looked at timestamping.
13:23:35jtimon:adam3us: gmaxwell's thread is full of terrible covenants
13:24:11adam3us:jtimon: on bitcoin talk? a cautionary tale of why the virality of covenants can be a risky proposition?
13:24:27jtimon:but is any covenant economically worse than destroying coins (which we allow)?
13:24:57jtimon:I think is "coincovenants: a f** terrible idea" or something similar
13:28:27jtimon:actually, I propose the AML-KYC covenant there
13:29:01jtimon:and I think it can replace our optional "authorizer tokens" in freimarkets
13:29:23jtimon:not sure about the "issuance tokens" yet, I don't think so
13:32:09adam3us:jtimon: i see that gmaxwell and you share my concern that this is a terrible idea :) this is good. ethereum will have this problem because its script is TC, as well as stateful and lots of non-amenability to theorem provers, security problems inside the language/scripts, and sandbox interpreter escape.
13:33:05jtimon:but the first really-interesting use case I saw yesterday (again in the context of freimarkets) is a covenant that allows you to always buy back interest bearing assets you issued
13:33:06adam3us:jtimon: a covenant is far worse than destroying bitcoins. it is viral and so can be used as a lever to change the social contract an meaning of coins against the users wishes.
13:33:45jtimon:say you issue adamBTC at 1% interest but want to buy them back for BTC at 1:1 when you want, not when the lender allows you to
13:34:57jtimon:I'm not worried, by attaching a "bad" covenant you've made your coins unfungible: they're not bitcoins anymore but another asset
13:35:29jtimon:destroying is not strictily "viral" but it's also irreversible
13:35:54jtimon:the effect on the quantity of "pure btc" is the same
14:22:30adam3us:jtimon: destroying coins is relatively harmless systemically. it reduces 21mil limit, but the divisibility means it just creates some supply contraction. we cant prevent it really, all we could do is force people to do it in a non-utxo compactable way
14:23:40adam3us:jtimon: the problem with virality is its like coinvalidation, it could virally sweep through the system via centralized policy points and change almost all of the coins semantics. for a system which aims for user-centric policy choices, that is a big fail.
14:25:29adam3us:jtimon: if a user wanted to make a convenant, thats their choice, the worry is more around centralized points like exchanges, regulated businesses, etc imposing a viral covenant on their users that flows through the system where the user has a choice to lose fungibility or submit to some outside imposed policy against their preference and self-interset
14:29:12jtimon:well, let's use my visacoin example (KYC covenant)
14:29:51jtimon:if I give btc to an exchange and they give me viscoins back, I calll that fraud and never come back
14:30:55jtimon:the main problem would probably be education and smart clients that show a different separated balance for visacoins
14:32:00jtimon:if we solve that, it doesn't matter if 80% of the btc were turned into visacoins: bitcoins are still p2p
14:32:35jtimon:in the case of freicoin is again less to worry about
14:33:03jtimon:both visacoins and freicoins will be destroyed by demurrage, but miners get fresh clean freicoins
14:33:39adam3us:jtimon: given the centralized pressures that exist in the world for control i think adding covenants would likely end in the loss of decentralization and effective user policy choice. ie the destruction of bitcoin as a decentralized currency.
14:35:27jtimon:maybe I'm too optimistic or I expect people to be too smart
14:35:28adam3us:jtimon: see our visacoin example, it gives a new outcome other than banning exchanges: ban non AML convenanted coins. that means u can not transfer a coin to an address that is also not AMLed. easy there-forward for governments to mandate that policy. ergo do not build the mechanism for your own demise
14:35:43jtimon:or maybe you're too pesimistic and expect people to be too stupid
14:35:52adam3us:jtimon: seemingly if bitcoin taught us anything its that people are too stupid :)
14:35:57jtimon:and don't distinguish between visacoins and bitcoins
14:37:01jtimon:adam3us: maaku had the same concern when we were discussing freimarkets authorizers
14:37:53jtimon:my believe is that people will tend to prefer non-authorized assets when they can
14:38:01adam3us:jtimon: see there is a hypothetical bootstrap stage where bitcoin density reaches a point where it can continue without exchanges (for some p2p uses). covenants only makes that worse, because each time you interact with someone who is stupid or doesnt care or need the money in a aml form to dosomethin, it removes free coins, let it run for a year and there will be none left.
14:38:32adam3us:jtimon: i agree, but the virality and incremental leaking effect means you have no remaining effective say in the matter.
14:38:33pigeons:yes, its more than just the technical issue of unaware mixing of covenanted coins and unencumbered coins. As the large, "convienent" options force covenanted coins, some of their partners, customers, and suppliers do too, etc
14:38:44jtimon:and at the same time, there's local communities who want to impose strict rules for their local currencies, and authorizers were the most generic way of allowing them to do so
14:40:15jtimon:if btc are destroyed logarithmically, there will always be some of them left
14:41:02adam3us:jtimon: yes but the remaining free coins are not going up in value (much) so if there are 100btc left for those that care its too few, and bitcoin is dead.
14:41:51jtimon:please, don't say value, say price
14:42:08jtimon:you're making a lot of assumptions
14:42:31jtimon:why would the value of btc be correlated to the value of visacoin?
14:42:53adam3us:jtimon: (ok price) overall this is one of the reasons why tinkering with expanding script language power has far reaching implications, even for the very continued meaningful existence of bitcoin with decentralized policy features, and must be approached with extreme caution.
14:42:55jtimon:if there's 1% btc and 99% visa, btc are much more scarce
14:43:11pigeons:its similar to coinvalidate. you would think no one would want to use a whitelist, but once "everyone else" does
14:43:57pigeons:there become less options to use bitcoin and the only options are to use covenantcoin/visacoin/etc
14:43:59jtimon:what would I use whitelisted bitcoins? that's not a p2p currency
14:44:08adam3us:pigeons: right. its as likely that the price of free coins would plummet because the people who think about technical freedom are in an economic minority
14:45:01jtimon:technical freedom is what bitcoin is about
14:45:05adam3us:jtimon: scarce as in about to become dodo i thin, due to incremental virality
14:45:37jtimon:if people think that bitcoin will go higher in price after they turn into visacoins they are blind
14:46:09adam3us:jtimon: i think it is more that the economic majority neither thinks, nor cares, they just want to buy a burger, etc.
14:46:41adam3us:jtimon: so why would they care when they spend the last freecoin for a burger, so long as the visa covenant shop accepts it at parity
14:46:56pigeons:well price isnt the concern, its usability and perhaps fungibility, if network effects help increase visacoin usage as the way to go
14:47:02jtimon:please, stop using the "people are dumb" fallacy
14:47:52jtimon:because the burguer costs 1 visacoin (1000 usd aprox) and 1 bitcoin costs 100,000 usd, for example
14:48:18adam3us:jtimon: ok, say the bitcoin wizard guy gets very hungry, and he wants to eat the burger and he has no visa coins in his wallet. he think h well its only 10mBTC. repeat viraly by the velocity of money and even people who are smart an care, can end up with no free coins left after a bit
14:48:33pigeons:so i like tools that have lots of options too, but also i've seen the "people are dumb" argument supported too well in bitcoin.
14:48:43pigeons:not reall dumb, just acting naturally for conditions
14:49:38jtimon:people are dumb, but if you need that fact to make a point there's something wrong with your reasoning
14:49:38pigeons:so for these matters i like if the features are supported better, but after there are more options to support the underlying p2p bitcoin and keep it viable in spite of other choices
14:49:54adam3us:jtimon: there you assume the exchange for freecoin/amlcoin diverges. aml exchanges and shops will accept freecoin at parity i woul think (and convert them into amlcoins)
14:49:56jtimon:I'm just saying that's a fallacy, not that it is false
14:50:24pigeons:when bitcoin is more "entrenched" these outcomes are less of a concern
14:50:39jtimon:why would shops ask you for 1 btc for the burguer if they can sell 0.01 btc for 1 visacoin?
14:51:53adam3us:jtimon: i think covenants just hand a viral weapon of control to policy risk points. bitcoin has policy risk points: exchanges, regulated businesses and the market success of payment processor policy (say bitpay adopted aml coin, jgarzik resigns in protest, but it has market adoption)
14:52:07jtimon:I could even be fine with assuming most cosnumers and some merchants are dumb
14:52:40jtimon:but certainly not assuming that most shops and producers will be dumb: because they go bankrupt when they're dumb
14:53:12jtimon:what could happen...
14:53:24pigeons:policy risk points are not about business saavy, they are about external force imposed by regulators
14:53:33adam3us:jtimon: ok agree, no more dugging-krugeresque smugness. lets focus on the virality issue
14:54:17jtimon:no matter the law, if your business sucks you go bankrupt
14:54:36jtimon:no matter how happy the nsa is with say, coinbase
14:54:53adam3us:pigeons: as we've seen with NSA the'll use / abuse what they can get. we thought we were secure because of CAs. in reality government can demand keys, and cooperation from CAs, do MITM and so we are not secure. i called this risk in 1992 or something. took 22 years but here we are.
14:55:03jtimon:f they keep on doing stupid things like using databases without consistency they will go bankrupt
14:55:44pigeons:there is much moral hazard about that i'm not so sure that's true
14:55:46jtimon:but CAs are centralized
14:56:26adam3us:jtimon: not fully, there are 100s of them in dozens of countries, operated by a variety of types of organizations.
14:56:57pigeons:yes CADs are centralized, but bitcoin also has "policy risk points" as adam3us says. exchanges, mining pools, etc that have aspects of centralization
14:58:04adam3us:anyway bitcoin/altcoin focus i think covenant language extensions are dangerous and we should not introduce them. or we should do language extension with language level provable virality/centralization resisting limits
14:58:21jtimon:I don't know, apparently I wasn't being able to make my point that, bitcoins != amlcoins
14:59:05jtimon:back to your "bitpay ports to amlcoin" example
14:59:09adam3us:jtimon: i think i get what you are saying. that by imposing amlcoins, the "attacker" has created an alt-coin. you are supposing its value will float to the extent that people will not willingly exchange them or wil lthink hard about it
14:59:41jtimon:there will still be people that have eyes to see they're are different currencies
14:59:52adam3us:jtimon: however teh value of the freecoin is heavily hampered by not having access to exchanges. that may defacto make its price quite close to the amlcoin floor
15:00:00jtimon:so the prices will (at first slightly) differ
15:00:46jtimon:people paying with bitcoins don't want to have their btc valued as if they were amlcoins
15:01:02jtimon:and suddenly the impossible happens: bitpay2 appears
15:01:16jtimon:wait wait
15:01:22pigeons:and there are now more things you can buy with amlcoins than with bitcoins
15:01:50adam3us:jtimon: your argument is analogous to the "attacker creates" alt in commited tx, yes i do get the argument. but i am not sure the economics work for it in this case. because the choice is severely limited, and the fungibility reduced which in tur affects the value. the outcome depends on the balance between preference for freecoin (price up) and loss of fungibility/virality (price down towards amlcoin) my guestimate is freecoins lose an
15:01:55jtimon:you're now saying that all exchanges in the world will abandon bitcoin in favor of nsacoin at the same hour?
15:02:02pigeons:and yes you lose the advantage of bitcoins, but here is where you have faith that people will see that and reject the amlcoins, but this i would bet against
15:03:18adam3us:jtimon: well its a given that the main risk to bitcoin is regulation. exchanges alredy impose AML due to regulation. if we give them a way to make aml viral, i predict governments will seize and make that mandatory
15:03:31jtimon:ok, we found were we disagree
15:04:28jtimon:you think people are too dumb to distinguish between bbitcoin and amlcoin and the people who undesrtand it won't be able to explain it to the world
15:04:53pigeons:not too dumb, just less concerned about the ideals of the issue and more concerned with getting a transaction done
15:05:15jtimon:so I could as well make a falsefreicoin covenant with a demurrage that goes to me instead of miners
15:05:44jtimon:sell them into existence for bitcoin at 1:1 ala mastercoin
15:06:04jtimon:but if bitpay moves from bitcoin to falsefreicoin nobody will notice the difference
15:06:07adam3us:jtimon: it might work :) look at all the scamcoins
15:06:35jtimon:scams work for a while
15:06:37pigeons:and external factors will use these tools to force the social and economic environment so that using amlcoin is either simpler and easier, or the only option for the things the user/business/customer wants to do
15:06:54jtimon:let's see how the scamcoin thing looks in a year
15:07:17adam3us:jtimon: so you agree that bitcoin with no access to exchange services is almost certain to have a lower price?
15:07:55adam3us:jtimon: indeed i hope the scam coins all die :)
15:08:12jtimon:would have a much lower price, yet, I just don't believe anything in the world can close all bitcoin exchanges at once
15:08:25pigeons:no access to large public, in the open, exchange services? because exchange services can take many forms
15:08:27jtimon:why would btcchina care about nsacoin?
15:08:41pigeons:why does it have to be at once?
15:08:58adam3us:jtimon: and similarly i agree with your concept that a freecoin is worth more than an amlcoin in a way slightly perhaps analogous to virgin coins being apparently already worth a premium over used coins
15:09:15pigeons:it inches toward more useful to merchants and users as bitcoin inches aways from it
15:09:42adam3us:jtimon, pigeons: well access to btc-china for non-chinese resident is not given. watch the 10% spread bitstamp to mtgox.
15:09:51jtimon:pigeons if it's one by one, btc will start with more exchanges than nsacoin and your arguments are reversed: nsacoin are worth nothing because you can only trade them in 1 exchange
15:09:56stonecoldpat:adam3us: do you mean that a freshly minted coin from miners, has a premium over previously used coins?
15:10:15adam3us:stonecoldpat: apparently yes. there was someone selling virgin coins for a premium
15:10:22stonecoldpat:haha fantastic
15:10:40pigeons:well my argument isnt about price, im not concerned with the price, im concenred that amcoin adoption and usage forces out bitcoin adoption and usage
15:11:43adam3us:pigeons: yes but jtimon asserts that the freecoin->amlcoin leakage would be stemmed if freecoins become worth a lot more than amlcoin so the price comes into it. i expect the reverse in net tho there are economic forces pushing in both price directions
15:11:46jtimon:stonecoldpat: I think only if they can buy them anonymously since this way "nobody" knows the source
15:13:51stonecoldpat:jtimon: yeah i guess so - its quite interesting ti has a premium, i guess zero coin should be renamed virgin coin - although the coins link to prev transactions is defo an interesting problem
15:14:02adam3us:jtimon: i would like it if this were the outcome (two alt form, and most people dont use amlcoins) however the regulators have high control over the interfaces to the banking network so it seems the loss of fungibility would create a stronger price down force than the freecoin prefering audience would be able to counter with their econoomic preference
15:14:45stonecoldpat:although removing a coins link* to prev transactions is defo interesting
15:15:25adam3us:stonecoldpat: i suppose another indication is apparently people pay fees to mix coins to reduce the link
15:15:58pigeons:i think even without building toolkits to give regulators/etc an easier time, it will still be an uphill challenge to keep this sort of thing from happening through less technical means not integrated into the protocol
15:16:47stonecoldpat:adam3us: yeah ive seen that mentioned in a few papers (think someone thought of a protocol to do it too without third party?), if i had bitcoins to mix i perosnally wouldnt trust them though
15:17:08jtimon:stonecoldpat: coinjoin solves it by anonymous p2p mixing
15:17:25jtimon:coinswap is even more effective
15:17:39adam3us:pigeons: yes. bitcoins decentralization comes from users controlling code. what happens when microsoft makes an auto-updatable microsoft bitcoin wallet, or apple. lots of captive users subject to the proxy decisions of central risk point with a history of government backdoors/over-compliance
15:18:15adam3us:stonecoldpat: yes coinjoin does that (trustless mix, the mix cant take your coins)
15:19:42pigeons:not that innovation should be abandoned because it can be abused, but the potential consequences should be taken very seriously
15:19:51adam3us:pigeons, jtimon: i'd sooner focus energy on trying to architect to defend against that kind of centralization risk (eg committed tx) than getting too far with potentially decentraliztion-risky expansion of script language language power
15:20:42adam3us:pigeons: which is to say probably covenant risks were considered by satoshi during his selection of the script-language. i expect.
15:21:26adam3us:road to hell is paved with good intentions, pragmatic programmers, fun science experiments etc.
15:21:32pigeons:hey, we can learn whatever lessons we can from freimarkets authorizers and such hopefully
15:21:48jtimon:adam3us: maybe satoshi didn't thought that much about the language choice
15:22:19jtimon:of course p2p currencies rely on free software, despite Nestcoin users ignoring that
15:22:38adam3us:pigeons, jtimon: well just to say consider virality risk as a security defect, and make sure new script feature dont introduce it.
15:22:52jtimon:what is the commited transactions risk?
15:23:17adam3us:jtimon: commited-tx is a mechanism to reduce the policy control from centralization in miners.
15:23:55adam3us:jtimon: by making them mine on opaque blobs so they have no information to form policy decisions on (they cant tell who is paying who how much at the time of mining)
15:25:09jtimon:by the way, some of your argumentation against covenants sournd to me like that: "bitcoin will fail because people will prefer easy-to-use proprietary clients and then they'll get screwed"
15:25:35jtimon:oh, I remember
15:25:38adam3us:jtimon: free software. yes but if someone commercial makes a nice shiny wallet, maybe people will use it. watch skype success while there were free FOSS voip at the same time
15:25:42jtimon:I though it was another risk
15:26:20jtimon:again, unlike you I'm not very concerened about the censor miners "problem"
15:26:59jtimon:but that's not a problem with voip, only with skype
15:27:38jtimon:it's like saying "linux is flawed because many people prefer windows or macos"
15:27:54adam3us:jtimon: hmm yeah but i've been here before, was worried about CA risk, and it turns out that i was basically right, even tho everyone at the time was like ... nah they wouldnt do that, it would be detectable ,etc and now we see the NSA spent billions doing just that.
15:28:25pigeons:i'll have to read that discussion. i've always been of the satoshi/luke-jr school that miners decide what transactions to include. but satoshi's views where from when all nodes were mining and there could be a wider marketplace for transactions
15:28:49adam3us:jtimon: its not a bitcoin flaw, but it could become a problem perhaps. clients are individually less powerful.
15:28:50jtimon:that's another fallacy adam3us, just because you were right that time it doesn't mean you're right this time, argument of authority
15:29:28adam3us:jtimon: ha ha, yes you are right. i just mean as an example that seeming paranoid by todays horizon of considerations doesnt mean you are wrong
15:30:00jtimon:nothing wrong being paranoid, I agree
15:30:27jtimon:just happens that the points where I get paranoid and where you get paranoid are not the same
15:30:29pigeons:jtimon: i agree with your characterization of the argument, "a danger to bitcoin is users taking least resistance paths" but i disagree that means "linux is flawed because of windows" i think its more " be aware of this tendency and engineer more p2p enabling choices to be least resistance"
15:31:05adam3us:pigeons: yes committed tx aims to change that. minrs have no clue what they accepted. users chose. pairs of consenting users should be able to pay each other with no censure, or decide their own policy.
15:32:03jtimon:I agree that having an in-chain anonymous transfer mechanism could be would for several reasons
15:32:27jtimon:I think it could operate alongside a "public" one
15:33:06jtimon:but I tend to like more petertodd's inputs-only transactions (although it's less developed)
15:33:33adam3us:jtimon: there is an argument that if miners became too centralized, they may try to block non-public ones (or transactions with non-public xfer in their history)
15:34:19jtimon:maybe because I tend to get lost in your crypto spell scrolls...I mean...formulas
15:34:36jtimon:yeah, we discussed it other day at lenght
15:35:00jtimon:my argument was that censor miners would rapidly go out of business
15:35:02adam3us:jtimon: the counter argument is that if clients consider evidence of suppression of non-public xfer as an invalid mining event, then hostile miners form an alt-coin with no users, and so they make no profit
15:35:30adam3us:jtimon: i agree. its like the amlcoin argument u made in some ways.
15:35:36jtimon:of course, I was assuming the distribution has ended, that risk is higher now I guess
15:36:27adam3us:jtimon: not if its done right because users would ignore those miner, so the hostile-miner is on a chain that becomes orphaned or like an alt-chain that is irrelevant
15:36:46jtimon:and I guess is also good that freicoin only has 3 years of issuance ;)
15:36:50pigeons:well i know a few miners who see the control they exert as protecting the network from things like spam transactions
15:36:57adam3us:jtimon: so even their reward would be lost
15:37:40pigeons:and things like the address-reuse deprioritization wouldnt be possible i suppose
15:37:42jtimon:how and why would users ignore censor miners and how they find out what blocks are censored?
15:38:05adam3us:pigeons: the fact that we have pools at all people seem to think was an unfortunate unforseen technology limitation.
15:39:03jtimon:well, my argument is the same that with the ghash.io topic p2pool/eligious pools are not a problem
15:39:05adam3us:jtimon: well thats the objective, to arrange that this would happen. for it to happen unfortunately i think only committed-tx can be considered valid. or all clients have a button in them or a switch over mechanism that public tx can be disable in event of widescle problems
15:39:51adam3us:jtimon: its a technical insurance policy or threat.
15:40:07jtimon:I think inputs-only transactions would have a similar anonymity effect and they seem more scalable to me
15:40:14pigeons:its a shame it seems like its not technical limitations keeping p2pool adoption from increasing as much as places like ghash
15:40:30jtimon:and also more "compatible" with regular txs
15:40:41adam3us:jtimon: how does that work? do u mean where the output is p2sh so the miner cant tell who it is being paid to?
15:41:06pigeons:and its not technical limitations why stratum is much more widepread than gbt
15:41:22pigeons:but yeah the limitations existed at the time pools emerged and grew
15:41:53adam3us:pigeons: ghash also has lots of hw in their datacenter. but the herd mentality that gets people to give % of their mining reward to miners when it is not necessary is strange yes.
15:43:41adam3us:jtimon: if inputs-only means output addr is obscured via p2sh i think its significantly weaker mechanism. most of the policy relates to history not static receipt address censor. its easy to make new addresses (or sender derived address like stealth)
15:43:48jtimon:adam3us: this is ptertodd's very open design https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
15:44:10jtimon:but let me summarize the way I see it integrated with regular transactions
15:45:44jtimon:transactions only include inputs, not outputs, and miners only include them if none of the inputs they contain have been seen (you need expiries in the TXI set for scalability)
15:46:13jtimon:the inputs may actually be garbage, refer to outputs that don't even exist
15:46:54jtimon:and all the history of the outputs is transmitted directly between users, it doesn't touch the chain
15:46:58jtimon:makes sense?
15:47:51jtimon:well, I haven't really though much about interoperate with regular transactions (going from private back to public)
15:48:13jtimon:the main problem here seems to be: how fees are paid?
15:48:30jtimon:and the only answer seems to be pow fees
15:48:39jtimon:petertodd doesn't go beyond that
15:48:53jtimon:I think you could have a regular blockchain
15:49:03jtimon:and optional pow fees
15:49:27jtimon:which miners can somehow "add" to their per-block PoW
15:50:32jtimon:maybe you want ot combine it with the "orphan blocks count for the total pow of a given chain" thing on that academic paper
15:50:45adam3us:jtimon: btw the first half of that writeup was stuff i summarized to petertodd (the entanglement, timestamp/namespace/minimum validation required) he could've mentioned it... i didnt read the rest of it before to see the txin proposal. it seems like a subset of comitted tx
15:51:13jtimon:yeah, seems very similar
15:53:14adam3us:jtimon: he could've alternately written "hey here's some stuff adam told me he explored, and i have another idea why dont we tweak committed tx to expose the txin" :) i think that is a more accurate summary of what he wrote.
15:54:55adam3us:jtimon: the thing is as i said above probably the bulk of the policy risk is based on the history. the thing about passing history around off-chain was in the committed-tx writeup
15:55:27jtimon:if he had done that I would have explained the txin proposal to you much faster ;)
15:56:05adam3us:jtimon: and to include clear txt tx-in exposes history. or alternatively if the txin is unlinkable because its never published (its ambiguous at the end) then what he wrote IS committed-tx
15:56:57adam3us:jtimon: (yeah sorry i was reading the post so i didnt see your explanation above until you wrote quite a bit you were writing while i was reading)
15:58:05adam3us:jtimon: i think gmaxwell said in the committed-tx thread it might nearly but not quite be implementable with script.
15:58:33jtimon:that post of him, reminded me a discussion Ryan and I had about a txid-only chain for one of our ripplecoins
15:59:01jtimon:we wanted to put the powin transactions
15:59:56jtimon:if you made the pow on top of another transaction, the pow was "summed up" (we didn't thought in detail about that PoW addition operation)
16:00:39jtimon:so people will commit their transaction on top of the longest chain they see
16:01:10jtimon:and then we needed a git-like merge
16:01:21adam3us:jtimon: yes i was wondering about something like that. i had a PoW variant with addition, however it is very approximate addition and has variance reduction so creates mining fairness issues.
16:01:32jtimon:but we realize that didn't prevented doublespendings ;(
16:02:09jtimon:adam3us: ok, but it's good to know that it's not completely impossible
16:03:00adam3us:jtimon: well ghost protocol could reduce sensitivity to how long it takes to reach consensus (ie not so concerned about orphan rate anymore).
16:03:08jtimon:I think it started here? https://bitcointalk.org/?topic=4382.0
16:05:00jtimon:disclaimer: we were mainly interested in ripple, so we just really wanted a minimal p2p timestamping mechanism
16:05:30adam3us:jtimon: i was thinking of something related that ideally you would like to allow users to direct mine for small reward without pools and ended up with something ghost-like. i was thinking its too complicated and the incentives looked like they could work but wre also more complicated rules, and maybe more bandwidth a bit. so i thought this is too inellgant. seemingly the ghost authors thought it ok.
16:05:37jtimon:if this tx id gets into the chain before expiry, all the sub-txs in it are valid, otherwise none is valid
16:06:08adam3us:jtimon: i see in the rfugger thread u linked that you and he had a similar idea about building on non-conflicting orphans. why not indeed, link them all in by reference.
16:06:51jtimon:sorry don't know ghost
16:07:29jtimon:my latest idea as said was that miners added the user's tx-pow to their block pow
16:07:40adam3us:jtimon: there is an academic paper. they claim if you dont ignore orphans but hash into the coinbase non-conflicting orphans and change a few things you can have faster block interval without convegence problems
16:08:34jtimon:oh, that's ghost? yeah, that's what I meant by "" maybe you want ot combine it with the "orphan blocks count for the total pow of a given chain" thing on that academic paper "" earlier
16:09:06adam3us:jtimon: see it seems to me desirable that a user can claim anytime during the 2week retarget period any work of even small value. then we have less centralization risk. now a way to do that is separate reward from voting.
16:10:00jtimon:the users reward is getting their transaction into the block, why would they get anything else?
16:10:03adam3us:jtimon: so why not mine on a public key that you use to vote.. then the voting power of the public key is related to the amount of pow on it. and you can use it with a sort of PoS like vote
16:10:57adam3us:jtimon: i mean not specifically about your per tx pow, but that i wanted to be able to solo mine say 0.01 btc and claim it relyably without needing pools
16:11:24jtimon:what's the purpose?
16:11:39adam3us:jtimon: dislike of mining pool cenrtalization risk :)
16:11:58jtimon:the purpose of mining is validation not distribution
16:12:07adam3us:jtimon: so i tried to explore how could i solo mine. one answer is to be able to mine for smaller amounts.
16:12:52jtimon:but if you're mining old stuff, why should the network reward you?
16:12:58adam3us:jtimon: agreed. but maybe it can be a two stage process. stage 1 mine for small coinbase-like reward, stage 2 use PoS on the coinbase reward to vote for fee reward
16:13:27jtimon:I tend to distrust PoS
16:13:37adam3us:jtimon: u would be mining only your public key. its a kind of micro-level PoS within the 2 week retarget interval only or something
16:14:24jtimon:in freicoin the retargetting is 9 blocks and if bitcoin ever hardforks I would suggest to update to our filter too
16:14:25adam3us:jtimon: agreed PoS is not economically attractive. centralization of vote via money instead. not pretty. and many PoS have actual protocol defect to allow mining on multiple candidate block sin parallel so devolve to PoW
16:15:06jtimon:"mining only your public key" how do you mine "on a public key"?
16:15:10adam3us:jtimon: my idea is not at a working stage, this was just as close as i got .
16:15:26jtimon:oh, I see
16:16:09justanotheruser:Do you think PoS could ever work in a currency?
16:16:09adam3us:jtimon: the idea is mining is like to get the right to vote on what the next block is. so i though well why cant i mine on a signature key, and then use the signature key to cast a weighted voted. maybe i can get the same feature but with more flexibility in minimum mining contribution and minimum reward. and so less dependence on pools.
16:17:01adam3us:jtimon: but it tends to have problems. could i sell the vote. could i save up voting power for one transaction to double spend it etc.
16:17:33jtimon:ok, now I get the point
16:17:51jtimon:but I disagree on "the idea is mining is like to get the right to vote on what the next block is"
16:17:56adam3us:jtimon: if thsoe problems could be convincingly fixed, it might be quite interesting
16:18:08jtimon:the idea of mining is sequencing events irreversively
16:18:26adam3us:jtimon: correct, and to vote on their validity (for SPV client reliance)
16:19:00adam3us:jtimon: but interestingly the actual sequence doesnt matter, just that eveyrone agree on a sequence. if they could do it via coin toss that would be just as good
16:19:26wallet42:stealth addresses are base58_check encoded compressed pubkeys?
16:19:34adam3us:jtimon: (except for some issues with 0-confirm security model where network propagation such as it is provide some modest security)
16:19:37wallet42:whats the versionbyte?
16:20:31jtimon:justanotheruser: I think ppc is less secure for having pos, but it would be much more insecure if it didn't had pow at all
16:21:03adam3us:jtimon: (this was part of the entangled design discussion i had with petertodd that he wrote about it a bit in that same post. at the lowest level you could obtain a distributed consensus sequence from a distributed timestamping service)
16:21:38jtimon:justanotheruser: apart from the "I buy the system to destroy it" attack, as adm3us pointed out: "many PoS have actual protocol defect to allow mining on multiple candidate block sin parallel so devolve to PoW"
16:22:38jtimon:adam3us, of course, the challenge is the infinitely scalable p2p timestamping system
16:22:55adam3us:justanotheruser: gmaxwell gave some arguments that PoS fails because users can rationally vote on both sides of a fork, or on many forks to get higher voting power so it devolves to PoW. so i think it doesnt quite work in practice with the consensus mechanism as anyone can construct multiple candidates
16:24:27adam3us:jtimon: yes. well my offline exploration was to see if you could pull the bitcoin design apart, work out the minimum required dependency and features and put it back together in another way with any useful improvement. that experience led me to declare bitcion design is "entangled" because many security features rely back on the same PoW chain.
16:25:06adam3us:jtimon: and also to declare bitcoin only just works, or the design is fairly optimal. because each design change i considered of dozens always made things worse or more complicated or less efficient.
16:25:47jtimon:yeah, I agree, I have made similar journey while exploring possibilities for ripplecoin (where the hostcoin was actually more of a problem than a requirement)
16:25:58adam3us:jtimon: the ghost idea was one of these, but i considered it wrose because its more complicated perhaps i was too hasty on that one they claim its a useful design alternative. apparently ethereum is considering it.
16:27:03jtimon:adam3us: it looks interesting to me, but of course that doesn't solve all the scalability problems, is just a little bit of help
16:27:51adam3us:jtimon: at this point i would've taken any improvement :) my exploration of the design space was a failure. pools do seem a problem worth removing.
16:29:05stonecoldpat:are miners pools not just a natural process that cant really be removed? It's a bit like industrialisation...
16:29:11adam3us:jtimon: but like i say adding an indirection between mining and voting seemed to create perverse behavior opportunities with like saving up voting power for one moment of abuse (hashcash had this problem) or selling votes
16:30:25adam3us:stonecoldpat: well one thing is industrial scale mining, thats perhaps somewhat inevitable. the other thing is people giving their vote to a pool operator while it is the user actually with the mining power. that should be avoided if we could find a way IMO
16:31:08stonecoldpat:is the vote to choose the correct branch? or how to distribute the coins?
16:31:55stonecoldpat:i remember having a thought about this before christmas (how to distribute coins) - i seen it as a pretty bad problem
16:31:57adam3us:stonecoldpat: correct branch and form part of a kind of distributed signature attesting all the transactions are valid
16:33:13stonecoldpat:adam3us: i dont know if a distributed signature is really necessary, a block with an incorrect transaction won't be accepted by the rest of the community (unless this pool has over 50%) - so it is in the interest of the pool lead to verify the transactions are correct
16:33:52stonecoldpat:adam3us: and choosing the correct branch is hard - since they are both correct. it may lead to greater vulnerabilities (by tricking the voters) - im sure some politician tactics could be deployed
16:33:55adam3us:stonecoldpat: yes but the SPV (smartphone/limited bandwidth) clients accept whatevr is claimed by sampling a few nodes
16:35:34adam3us:stonecoldpat: so eg a smartphone may download only the hashchain and ask for merkle proof that a tx is in a block, and then just assume its valid. if someone can get enough power to create 6 blocks they could print money in the eyes of SPV clients... so i just mean the distributed signature in the sense that it is hard for someone with << 50% of hash power to win 6-blocks in a row
16:36:28adam3us:stonecoldpat: yes if all candidate blocks are valid tossing a coin to choose a block at random would be just fine.
16:44:15Luke-Jr:I wonder if stealth addresses can be combined with P2SH^2 somehow
16:46:20jtimon:stoencoldpat: the network will never accept an invalid transaction no matter the % of hashing power, the only thing 51 attackers could do is change the order (for double-spending purposes?) or freeze the chain
16:47:19jtimon:stoencoldpat: if you have ideas for coin distribution, maybe you're interested in this: http://foundation.freicoin.org/#/about
16:48:14jtimon:adam3us: about your "pools problem" what about this other approach: *somehow* prevent non-p2pool pools from mining
16:48:45jtimon:adam3us: solo miners could only mine on their own p2pool alone
16:49:38Luke-Jr:jtimon: p2pool isn't special
16:49:43adam3us:jtimon: yes that is an interesting direction (prevent pool security) amiller had some idea relating to this. i dont think it quite worked however
16:49:52Luke-Jr:there is no reason to prefer it over other decentralised schemes
16:50:40jtimon:Luke-Jr I thought it was (and by p2pool I include eligious, just exclude "centralized pools")
16:50:42adam3us:jtimon: i have a friend who elects to solo mine as a kind of lottery. it'll take him years to get $25,000 payout. the limitation is that. if the reward could be made less lumpy maybe.
16:51:00jtimon:maybe that term is more appropriate centralized vs p2p pools
16:51:01Luke-Jr:jtimon: p2pool is a specific pool, both decentralised and also p2p
16:51:11Luke-Jr:jtimon: BitPenny was the original decentralised pool ;)
16:51:21jtimon:I see
16:51:33Luke-Jr:unfortunately, they died out
16:51:59jtimon:well, I think most frc pools are based on p2pool software, that may have contributed to my confussion
16:52:20jtimon:in frc there's only centralized pools and p2pools
16:52:56Luke-Jr:makes sense, GBT isn't feasable for FRC as-is
16:53:03jtimon:my point for adam3us was "instead of thinking about micro-mining, think of a way were only p2p pools are allowed"
16:53:21forrestv:as usual, Luke-Jr ignores other benefits of p2pool
16:53:24Luke-Jr:ok, but my point is that p2p is a bad thing; what you want is decentralisation
16:53:29forrestv:'s complete decentralization
16:53:52Luke-Jr:forrestv: there are none, to the network
16:55:29jtimon:* jtimon doesn't understand the difference between decentralized and p2p in this context
16:57:19Luke-Jr:jtimon: decentralised = miners create the blocks; p2p = there's no server to coordinate things
16:58:03jtimon:I see, yeah decentralized is enough since all miners validate everything, no?
16:58:19forrestv:Luke-Jr, you really need to use a name other than "decentralized," considering that eligius definitely has a central server..
16:58:22Luke-Jr:well, all nodes validate everything, miner or not
16:58:46Luke-Jr:forrestv: the mining isn't centralised though
16:58:53jtimon:I mean, in a centralized pool, a miner only hashes, doesn't see anything else
17:00:07jtimon:the validation node of a centralized pool can do more harm than the coordination server of a decentralized pool
17:00:23adam3us:jtimon: agreed
17:01:11adam3us:jtimon: a way of putting is it that miners are giving their vote to the pool. they should exercise their own vote, by doing their own validation
17:01:40jtimon:I don't know how this could work, probably changing the PoW, just wanted to inspire you adam3us
17:01:53Luke-Jr:jtimon: it cannot work.
17:02:03Luke-Jr:jtimon: if you take away centralised mining, hosted mining will flourish
17:02:09jtimon:I don't really like the word vote, then people say stupid things like "miners vote the rules of the system"
17:02:23Luke-Jr:"voice" perhaps
17:03:09adam3us:Luke-Jr: hosted mining is even worse, so that is a bad game theory outcome.
17:03:14jtimon:which degenerates in even more stupid things like "scrypt is more democratic than SHA256"
17:03:18Luke-Jr:adam3us: that's my point
17:03:41Luke-Jr:adam3us: stopping hosted mining is impossible, and that's what we'll get if we take away centralised mining
17:04:00adam3us:Luke-Jr, jtimon: it seems to me what you want is a mining algorithm with diseconomy of scale. not sure if that is significantly possible however
17:04:00jtimon:Luke-Jr, why?
17:04:01sipa:Luke-Jr: decentralized != trust-free
17:04:07sipa:Luke-Jr: eligius is trust-free, but centralized
17:04:21brisque:"hosted mining" is a sham anyway. there's no reason anybody would rent out mining equipment unless they're expecting their customers to take a loss.
17:04:56jtimon:sipa: yeah, I guess that's the word we were looking for: p2pool and eligious are both trustless pools
17:05:14Luke-Jr:sipa: that might be better terminology, but it's not the common terminology already in use
17:05:35adam3us:Luke-Jr: does eligius reject/not support non-GBT shares?
17:05:48Luke-Jr:adam3us: Eligius supports all protocols at the moment
17:05:56sipa:Luke-Jr: i don't think anyone but you considered eligius decentralized (i know it satisfied some definition of decentralized that's common, though, but not all)
17:06:11adam3us:Luke-Jr: so its trustless to the extent users use GBT then
17:06:31brisque:Luke-Jr: what sort of percentage of users use GBT over stratum?
17:06:41Luke-Jr:brisque: probably near zero :/
17:06:43sipa:trust-free doesn't mean you cannot trust anyone - it just means you don't need to
17:06:55Luke-Jr:the solution is to make decentralised mining just as easy/painless as centralised mining
17:07:20Luke-Jr:sipa: trust-free implies more than decentralisation IMO
17:07:30adam3us:Luke-Jr, sipa: so it seems to me there is some pain. the bw consumption.
17:07:33brisque:Luke-Jr: imagine i'm a miner, is there an incentive for me to use GBT on eligius over Stratum?
17:07:45Luke-Jr:brisque: only for the good of Bitcoin
17:07:46jtimon:Luke-Jr open transaction is trustless but centralized
17:08:05brisque:Luke-Jr: mm, there's the reason why lots of people don't use it.
17:08:26sipa:Luke-Jr: they overlap, but neither implies the other
17:08:46sipa:jtimon: trust-free to an extent - you still need to trust the issuer
17:08:48Luke-Jr:sipa: p2p != decentralisation
17:09:39jtimon:sipa : for non-p2p currencies you always need to trust the issuer anyway
17:10:15jtimon:if you issue usdCoins using colored coins is no different
17:11:39adam3us:jtimon: i think there are two aspects to trust for issued units. 1. the issuer to redeem, maintain 1:1 backing, 2. the network to secure ownership transfer. so it can still make sense to use decentalized ownership tracking (blockchain) for an issued asset.
17:12:30adam3us:jtimon: (you probably would personally redeem by selling to the unit for another crypto curreny or on an exchange, not via redemption with the issuer)
17:12:36jtimon:adam3us: my point is that, despite being centralized, you don't need to trust the OT server
17:13:39adam3us:jtimon: agree. i just mean with open transactions you need to trust it for some things but not others i think in their terminology an issuer is a different entity from a tx server.
17:14:14jtimon:yes, the same issuer can operate in different OT servers at the same time
17:15:36jtimon:the main problem with OT is you can't trade assets that are in different servers atomically, you have to move them all to the same server first
17:15:37stonecoldpat:adam3us: it would certainly add extra-security (if thats a phrase), but the way im thinking about it ... SPV clients arent really part of the hashing power (as they are not mining). As you said - they are just observers. So you would still need to trick over 50% of miners for the attack to work. my comment is probs a bit old now (got distracted at work)
17:15:40adam3us:anyway on the decentralization from pools. its good that eligius supports GBT and more users should use it. Luke-Jr is also right that hosted mining is likely even worse. but an even better outcome would be if there was a way to not need pools. ie to solo mine with reasonably frequent and predictable payout.
17:16:02jcrubino:does there need to be any protocol level changes for stealth addresses?
17:16:37Luke-Jr:adam3us: I don't think that's very practical on a wide scale.
17:16:46adam3us:stonecoldpat: heaven forbid to let work distact from btc :) yes i recall the context. this is true. but there could be a large payout you could mint millions and millions of $ of tx that didnt even exist and an SPV client would temporarily accept it
17:16:53Luke-Jr:adam3us: for the low variance many miners want, you *need* to keep a running balance somewhere
17:17:04jtimon:jcrubino: I don't think so, just the payment protocol
17:17:16adam3us:jcrubino: i do not think so. just client work.
17:18:00jcrubino:and does anyone in here have bitcoin-dev mailing list archived from the beginning?
17:18:09adam3us:Luke-Jr: yes i am talking spherical cows territory like changing the minimum reward. having 100s of mini-rewards per block, such things
17:18:12Luke-Jr:jcrubino: I think SF has an official archive
17:18:28jcrubino:Luke-Jr: can I download it all at once?
17:18:35Luke-Jr:no idea
17:21:27jcrubino:I want to try to do a topic mapping of the messages
17:21:56TD:TD is now known as TD[away]
17:22:30adam3us:jcrubino: maybe wget -r from the right base url might do the trick
17:24:45jcrubino:adam3us: It looks like the actual messages are id with every other message on SF
18:27:49michagogo|cloud:;;seen andytoshi
18:27:50gribble:andytoshi was last seen in #bitcoin-wizards 12 hours, 30 minutes, and 7 seconds ago: i assume jon matonis was involved in that list ..
18:28:16michagogo|cloud:;;later tell andytoshi Did you make any more progress on the cj client? Let me know if/when it's ready for more testing.
18:28:16gribble:The operation succeeded.
18:30:23wallet421:wallet421 is now known as wallet42
18:32:33wallet42:so stealth addresses are base58_check encoded compressed pubkeys? whats the version byte?
19:25:48justanotheruser:Is it possible to make an easy to confirm hashing function that involves all the previous confirmed tx?
19:26:04justanotheruser:*easy to validate
19:33:57gmaxwell:justanotheruser1: you mean what we're already using in Bitcoin?
19:34:16justanotheruser1:gmaxwell: no I mean your idea that would require miners to have the blockchain
19:35:40gmaxwell:justanotheruser1: I assume you mean easy to validate you mean fully validatable by someone who doesn't have that data?
19:37:26justanotheruser1:gmaxwell: no. I mean easy to validate in general. I thought of two methods, one where the hash you generate would require you to look up a tx based on that hash and include that in a new hash, but I think miners would just end up trying to find hashes of the tx in their cache to circumvent that. The other method I thought of involved having each tx be at the leaf of a merkle tree and the nonce be an adjacent leaf, but that would be hard
19:38:05gmaxwell:justanotheruser1: I thought I described such an approach in the post about that?
19:38:24justanotheruser1:gmaxwell: I haven't seen your post, just the wiki page. Could you link me it?
19:39:06gmaxwell:you can use the block header to force you to do N lookups and make a hash tree. And then you use the hash of the solved block to select which M of those N lookups to publish.
19:39:50gmaxwell:This way you can publish a relatively small number of values, but grinding the preselection isn't too effective because it's picking N.
19:41:03gmaxwell:e.g. 32 random lookups is not going to do well with a small cache. And then you find a block and you're forced to prove one of them.
19:41:46justanotheruser1:gmaxwell: So N is generated based on the block header?
19:43:49gmaxwell:e.g. H(prev header) tells you to pick N transactions at random. you include a hashtree over them in your block. H(your header) tells you which of the N to include with your solution. (this can be pooled, to prevent pooling for it, you'd need to put it in the inner loop which makes the pow utxo throughput hard)
19:44:33gmaxwell:I'd also suggested a simplified version where you just do queries on the inputs consumed in the prior block. The rationale being was that we really just wanted you to prove you had the required data to do the validation.
19:45:10justanotheruser1:Why not make H(Prev head) also tell you which N to include? Couldn't miners modify the header to make it so they only have to look at the 1mb of tx they have?
19:45:27justanotheruser1:(in a hypothetical situation where miners only store 1mb of tx to save space)
19:47:34gmaxwell:previous header. as in the prior block.
19:49:33justanotheruser1:gmaxwell: yes, but you are using "your header" to find the block. Couldn't a malicious mining pool make it so their header tells them that they have to include only tx in the set of tx the miners own?
19:49:48justanotheruser1:s/to find the block/to find the tx for the block
19:50:53gmaxwell:only by doing N fold the work of finding a block.
19:52:46justanotheruser1:gmaxwell: well the work of finding a block is memory hard, but finding an easy header isn't.
19:53:04justanotheruser1:unless there's something I'm missing
19:53:18gmaxwell:I have no freeking clue what you're talking about there.
19:54:06gmaxwell:The only point of the proposals of preventing people from mining without the blocks was to stop botnets that just mined using the headers and processed no txns.
19:54:17gmaxwell:The explicit goal of that was not to make the POW memory hard.
19:57:59justanotheruser1:gmaxwell: I thought the purpose was to keep centralized pools that don't require blockchain ownership infeasible
20:00:11maaku:adam3us: there would need to be some infrastructure for recognizing and handling covenants at the user interface level.
20:00:18maaku:users will probably have to whitelist which covenants are accepted under which circumstances... there are some nontrivial problems here.
20:00:18gmaxwell:No. If you want to do that then you need a utxo query throughput pow where the hardness comes entirely from random queries.
20:00:28maaku:but they are solveable. certainly the default should be that added covenants are non-fungible. this is part of why a strongly-typed, simple, theorum-proovable language should be preferred. that way a wallet could ignore / cordon off incoming coins which can't be proved to be covenant-free
20:00:41maaku:and that should certainly be the default behavior
20:00:51maaku:the history of bitcoin is that making sane, conservative, paternalistic choices in the the operation of the reference wallet(s) sufficiently influences the community to keep all but the most determined people from shooting themselves in the foot
20:01:04maaku:but on the whole there are some definite advantages, such as the p2p lending case which was an outstanding unsolved problem
20:01:26maaku:and it has the advantage of the covenant rules being unchangeable / unbreakable. our existing KYC system for example gave the authorizer the ability to vet transactions involving their assets using whatever metric they want at the moment whereas covenants require them to commit to rules upfront.
20:01:33maaku:that's a definate improvement from the user's perspective.
20:02:01maaku:jtimon: you can save significant block chain space, as well as avoid many difficulties with demurrage / interest if you have explicit assets at the protocol level, in which case it also makes pragmatic sense to have token-based issuers
20:02:08maaku:you could do away with token-based authorizers, although adding them would only be a couple of lines of code at this point. they have somewhat different properties
20:02:36maaku:adam3us gmaxwell: please correct me if i'm wrong, but I think greg's opinion is that permanent covenants attached to a non-demurrage host currency is a Bad Idea. I concur. But make the covenants temporary, the coins themselves perishable, or applied to user issued assets (not colored coins but separately issued assets a la freimarkets), and it is a different story IMHO.
20:02:48maaku:justanotheruser1: yes, PoS is an extremely valuable tool. Just not for consensus. People see "proof of X" and assume they substitute for each other. In fact they are entirely different tools with entirely different uses.
20:02:59justanotheruser1:maaku: what?
20:03:21justanotheruser1:Where was I talking about PoS
20:04:01maaku:[08:16:06] Do you think PoS could ever work in a currency?
20:08:43andytoshi:michagogo|cloud: i think it's working, now i ship a certfile (which i got from mozilla) along with libcurl DLLs that i built myself
20:08:54jtimon:yes, maaku, we wouldn't remove the tagged assets with defined interest/demurrage
20:09:39jtimon:I'm thinking we might be able to replace validation scripts, thought I would like to check that case by case
20:11:05maaku:what for offers and stuff? I don't know, maybe
20:11:11maaku:it'd be a little convoluted
20:11:53maaku:the delegation opcode is pretty elegant
20:12:00jtimon:well, we use them in most of our examples
20:12:32maaku:you could move the relevant coins into an output with a covenant attached governing their next use in the option or whatever
20:12:36maaku:obviously that would work
20:12:47jtimon:I was thinking about using the same opcodes somewhere else, but I haven't thought about it deeply enough
20:12:51maaku:but I don't think it's a very natural, succinct, or satisfying situation
20:14:15maaku:i think there are many use cases where the conditions are most naturally applied to the transaction itself
20:14:42maaku:e.g. you are saying "I commit these coins to this particular transaction, but only so long as these additional constraints are met"
20:14:46adam3us:maaku: covenants do allow some things that are currently painful think for example things involving hashlock could be made trivial. but i think the more dangerous things are viral covenants that can apply to all further respends indefinitely
20:15:09jtimon:yeah, as said I haven't tried yet, I was just thinking about what could be replaced and what not
20:15:48jtimon:"viral covenants that can apply to all further respends indefinitely" I thought that was the definition of a covenant
20:15:55adam3us:gmaxwell: btw i asked djb and cfrg some questions about ed25519, will see if we get some clarity.
20:16:31maaku:jtimon: we can probably shuffle stuff around, if we start over assuming a more powerful scripting language
20:16:39andytoshi:adam3us: thx much
20:16:46maaku:but i wouldn't get rid of tx-level validation scripts
20:17:08maaku:adam3us: isn't there an rfc process going on? you might want to forward comments to those relevant mailing lists as well
20:17:52gmaxwell:for something like a colored coin, it would be a viral covenant— but one that would let you remove it if you ask nicely. It wouldn't allow you to _add_ it except under the right conditions.
20:18:19adam3us:jtimon: i am not sure. i thought of something related, then found it described in freimarket, and finally read gmaxwell covenant thread. maybe i am describing quinine vs covenant, in any case terminology aside a small group of transactions that restrict the next transation is useful, but recursive ongoing or language constructs that allow that by implication are I think existentially dangerous
20:18:54maaku:adam3us: covenants also allow you to do things which you can't currently do, at all (like restricted buy back)
20:19:15gmaxwell:and yeam my covenants thread was intended to point out the existential danger, and also show how easy any sufficiently powerful script can achieve that danger.
20:19:17maaku:that's a very serious pro against a very hypothetical con
20:19:23jtimon:adam3us: not english but I thought: quine = reproduction of code, covenant = viral perpetual quine
20:19:24adam3us:gmaxwell, maaku: yes some kind of language restricted limitation on the power of covenants would be a min-bar for safety i think
20:19:49gmaxwell:adam3us: it seems really hard to achieve that.
20:19:55adam3us:gmaxwell: precisely. i think ethereum is creating unlimited danger as there are no restrictions and it is intentionally as general as possible
20:20:11gmaxwell:(achieve that while also permitting the good use)
20:20:33adam3us:gmaxwell: right, hence dont do that please :) aka i think satoshi as a guess figured out this risk hence the non-extrospection and so non-virality
20:20:41maaku:i think (for reasons obvious in gmaxwell's thread) that the default position should be that if a script cannot be *proven* to come with no strings attached, then it should destroy fungibility and not be treated as bitcoins by the clients
20:20:52maaku:relegated to the equivalent of a spam wallet
20:21:18gmaxwell:adam3us: one thing they may have done right by accident in ethereum is that they seem to have confined the fancy behavior to agents,... which can own coins. It's just a conceptual difference but perhaps a useful one.
20:21:42maaku:we can then experiment and slowly add functionality to allow users to enable certain covenants, pattern matched or detected by theorum proving
20:21:55adam3us:gmaxwell: see i too, once i finally caught up a bit with the aggregate bitcoin brainstormings, though hmm extrospection/limits on outputs, ooh you could do lots of things with that. and then realize similarly to your convenants thread that this would be a singularly dangerous thing to do, and hence script probably looks the way it does for a reson
20:22:49jtimon:adam3us what do you think about maaku's suggestion of killing fungibility in the clients?
20:22:57gmaxwell:well if you admit theorem proving then you can test for non-virality. But not if the script is turing complete, I suspect.
20:23:56jtimon:gmaxwell: I think the validators maaku has in mind would answer a) It is not a covenant b) I don't know
20:24:09adam3us:jtimon: but that is just a client restriction, not a language, nor protocol restriction. its better than nothing as defaults carry weight i guess. but only to that extent. seems like playing with fire and surely there must be other ways to make conveniently composable sub transactions
20:25:13gmaxwell:lol, post on liberation-tech:
20:25:15gmaxwell:As one anecdote, when I TAed the MIT Network and Computer security
20:25:15gmaxwell:course, we assigned "Why Johnny Can't Encrypt" as the first reading.
20:25:15gmaxwell:We asked the students to send us a PGP encrypted & signed message and
20:25:15gmaxwell:tell us how long it took.
20:25:17gmaxwell:If I recall correctly, it took an average of 30 minutes for
20:25:18adam3us:maaku: ie isnt there something one could do to make hashlock convenient, or part of an explicit transaction group, or something that doesnt involve increasing the language power
20:25:19jtimon:adam3us isn't your "all exchanges will port to kycCoin" concern eliminated?
20:25:20gmaxwell:non-existing users to figure out how to use PGP. Think about that.
20:25:22gmaxwell:These were graduate & upperclass undergraduate computer science
20:25:25gmaxwell:students enrolled in a network security course. Everyone had accounts
20:25:27gmaxwell:on the same university system and were mostly using standalone email
20:25:32gmaxwell:Best of all, someone decided it would be funny to generate a fake key
20:25:35gmaxwell:for me and post it to pgp.mit.edu. Several students fell for the
20:25:37gmaxwell:trick, didn't verify the key, and encrypted their homework with the
20:25:40gmaxwell:wrong key.
20:25:49maaku:gmaxwell: sure you can, an inconclusive result is assumed to be worst-case
20:26:24jtimon:adam3us: the point of all this is precisely to increase the language power
20:26:30adam3us:jtimon: amlcoin via virality risk reduced not eliminated
20:26:41gmaxwell:maaku: ugh, okay I suppose. But you're going to be inclusive an awful lot of the time.
20:26:56adam3us:jtimon: well the point should be to allow contracts to be conveniently expressible language power = danger also.
20:27:21maaku:over all of program space? sure. but that just means you restrict actual scripts used in the wild to those which are provable
20:29:15jtimon:gmaxwell do you share adam3us concerns on all btc becoming amlcoins without the dumb users noticing?
20:29:47adam3us:jtimon: so long as the contracts catalog that you consider as your benchmark are implementable in a turing completeness sense, with the current script language, maybe its better to focus on a translator from psuedo-legalese to script. and add minimal script extensions to cover any gaps rather than going for eval like generality and trying to contain the damage
20:29:54gmaxwell:jtimon: Yes. It's not about "dumb" it's about having forced choice.
20:29:57jtimon:maybe maaku and I are too optimistic but to me it seems an exhageration
20:30:17adam3us:* adam3us is loathe to repeat that long thread
20:30:28jtimon:"having forced choice"? I don't understand
20:30:31gmaxwell:sure you could _choose_ to refuse to do business with this or that, or refuse to accept this or that coin. You could also choose to live in a cardboard box under the freeway.
20:30:43gmaxwell:Not all choices are meaningful, even in the presence of perfect information.
20:30:53jtimon:who forces you to accept amlcoins? who forces you to turn your btc into amlcoins?
20:30:53maaku:jtimon: well, we're also thinking about this in the context of having 5% of the monetary base refreshed annually
20:31:11adam3us:adam3us: but in summary as the regulators have much control over the gateways to banking infra, a viral amlcoin enforced at exchanges would already be enough i think
20:31:50jtimon:maaku and they think it from the perspective that deflation doesn't matter, so 1% of the current btc will be ok, and 0.1%, 0.001%...
20:32:04adam3us:jtimon: anyone who only accepts amlcoins that you have a poor choice with (no service or amlcoin, amlcoin as change because of the payment integrator they are using etc)
20:33:23jtimon:the way you talk about it, is like if btc would be dommed if bitpay and gox stopped accepting bitcoin and moved to ltc...
20:33:33andytoshi:adam3us: it occurs to me re your 'redcode' scenario that this is exactly what happened in the real global financial system in 2008
20:34:06andytoshi:ie the legalese that contracts for derivatives are written in is turing complete, and extrospection capabalities are determined by a regulatory regime that did not do cogent incentive analysis
20:34:13adam3us:andytoshi: haha yes. the system was virus prone. the fintech/bankster boys dreamed up viral make-money fast schemes that are doomed to crash with OPM
20:34:20andytoshi:which led to things like, eg the cds market hitting a 4 quadrillion cap :P
20:34:40jtimon:" amlcoin enforced at exchanges" you mean prohibiting bitcoin exchanges?
20:35:00adam3us:andytoshi: fascinating analogy. and we think we can protect that by restricting the contract language? (probably not)
20:35:22gmaxwell:jtimon: it's much harder politically to shut down bitcoin exchanges when to do so you're suppressing bitcoin. Much easier where "on no bitcoin exchanges are fully permitted! they just have to comply with the law…"
20:36:13andytoshi:adam3us: so this is very cool, there is potential here for us to describe the horrible subtlety of financial regulation, in the context of cryptosystem currencies (which i have mentioned before, lets us do a lot of spherical-human economic analysis thanks to trustlessness)
20:36:15adam3us:jtimon: much was said upthread but yes exchanges already comply with aml, if bitcoin supports viral aml, regulaor will say "ok so use it or shutdown" and users will say ok i want to buy $100k btc i can spend a month on bitcoin-otc (coffee shops for cash) or put u with amlcoin etc
20:36:19jtimon:adam3us: I just don't believe all countries will prohibit bitcoin exchanges
20:36:31andytoshi:and have a very simple-to-describe but very precise "here is where the thinking went wrong" explanation of that whole situation
20:37:37jtimon:" users will say ok i want to buy $100k btc " wasn't your assumption that the users weren't able to get btc out of the exchange anymore, just amlcoins?
20:37:59adam3us:jtimon: i think if the world was as sure as you are about financial regulation and bitcoin the price would be $100k/coin already :D i thnk oneof the main things holding bitcoin back is just that - uncertaintly about regulation! its not that there havent been multiple non-basket case jurisdictions that have behaved erratically with bt regulation
20:38:32andytoshi:adam3us: re "restricting language", maybe that is exactly what we want to do, combined with maaku's "provably nonviral" ideas
20:38:37adam3us:jtimon: right. thats what would happen to any exchange that was forced by regulation to use amlcoin covenants
20:38:56andytoshi:because we've seen in real life that pasting "don't act in bad faith" policies onto a turing complete system lets people do weird destructive things
20:39:01adam3us:andytoshi: i dunno sounds like halting problem^2 in hardness
20:39:25gmaxwell:adam3us: no, because as maaku pointed out, you can fail-safe.
20:39:39gmaxwell:If the static analysis can't prove your transaction sufficiently non-viral, its just not valid.
20:39:56andytoshi:adam3us: the result would be basically a whitelist of policies, and if people can prove that new things are safe maybe they could post a SNARK showing that or something, so the hard analysis is on them
20:39:57adam3us:andytoshi: BUT what we can do and i pushed this thought to a few offline people, is have auditable insurance coverage through the insurer, the reinsurer, the assets, the companies balance sheet, revenue, dividendes etc.
20:42:04adam3us:gmaxwell: maybe. now security depends on a few more components including a theorem prover's comprehension vs virus writers
20:42:44adam3us:andytoshi: nice to have a fast to verify compact proof yes.
20:43:25andytoshi:adam3us: we could maybe put these proofs in the blockchain along with a unique identifier, then require all txes to reference the proof that they are safe
20:43:32nsh:we're on to viral transactions now? great...
20:43:54andytoshi:obviously this is a half-baked idea, as you say theorem proving is not developed enough to do such high-consequence real-world stuff
20:44:10adam3us:andytoshi: maybe. or we could amuse ourselves with what we can do with non-extrospection languages
20:44:34andytoshi:yeah, i'm really impressed and surprised with what you guys have found to be possible
20:44:40nsh:i'd like to see a fully darwinian transactosphere...
20:45:04adam3us:nsh: suggest looking at ethereum. will be interesting to spectate :)
20:45:22nsh:* nsh nods
20:47:56nsh:had a very unbaked and thoroughly handwavey idea about a DSA-authorized capabilities-based distributed computational system over a blockchain with costed access to scripts and (computational) inputs somehow marked to market by utility or complexity
20:48:54nsh:not sure exactly what all those words means though so it'll probably remain pretty deep in my imagination :)
20:49:16adam3us:* adam3us wonders if its considered part of redcode game to write ethereum stealing viruses?
20:49:57andytoshi:that's interesting, if you can infect a majority of hashpower you can "hack the matrix" so to speak :P
20:50:31nsh:(it's always part of the metagame to cheat in ways that haven't be considered and thus explicitly prohibited)
20:50:32andytoshi:i guess i mean, if you can infect almost all the validating nodes
20:51:08gmaxwell:I think I mentioned before, some of these altcoins basically appear to have no nodes... even 'widely' used ones: people just mine directly to exchange accounts.
20:51:29gmaxwell:so you've got a couple of pools, a couple of exchanges, an odd geek or two, and thats it.
20:52:17adam3us:nsh, andytoshi: i was thinking there could be two levels of viral ethereum progrms. a) within the interpreted execution space, eg viral covenants etc; b) escape the interpreter via sandbox escape. i wonder though, they probably wouldnt find it funny even if you did
20:52:17gmaxwell:and these are things where there is no huge cost to running a node... the chains are small because there are few txn.
20:53:14adam3us:gmaxwell: ha not only no tx, no wallet, but not even any full nodes.
20:54:47gmaxwell:well there are some levels of transactions, but no real reason for someone to run a node. So thats the kind of outcome I'd expect for ethereum, particularly because running a node would be expensive.
20:54:51adam3us:gmaxwell: i was thinking beyond coingen.io why not virtualize the whole thing. pay for virtual VPS, virtual ASIC hardware,... maybe you can make that provably fair like central but fair dice; i mean what the difference its only a tulip/pryamid coin anyway. people can speculate on synthetic nothing without wasting eletricity then
20:55:09gmaxwell:adam3us: you could call it "mastercoin"
20:55:41adam3us:gmaxwell: minioncoin. many someone should fork mastercoin and put it on top of dogecoin
20:56:02gmaxwell:Every dog has his master.
20:56:25gmaxwell:Many leashes. Such dogwalk.
20:56:51gmaxwell:the "exodus" needs to be DogCarRide
20:57:47adam3us:gmaxwell: please can 2014 be the year of the death of tulip coins?
21:00:36kinlo:heh, to see gmaxwell talk dogetalk made me laugh :)
21:03:35michagogo|cloud:andytoshi: Erm, you've given me an error I've never seen before
21:04:21michagogo|cloud:andytoshi: Is the file I got broken?
21:04:21michagogo|cloud:3836c0fef1bffbb4ed7c35564dbb23ad51295a74df7bc53b234b13e198bf4264 */cygdrive/c/Users/Micha/Downloads/cj-windows.zip
21:04:24gmaxwell:kinlo: that meme was a favorite in my household two months ago. dogecoin is kinda overplaying it at this point.
21:04:34maaku:"maybe. now security depends on a few more components including a theorem prover's comprehension vs virus writers" <-- there's no way you'd want the therom prover to be part of consensus
21:04:45maaku:i was suggesting it as part of the IsStandard check and wallet code
21:05:17adam3us:maaku: they are discussing safe curve RFC on CFRG which i am on, which include ed25519, is there a separate place that a EdDSA RFC is being discussed? or is that what you meant
21:05:26kinlo:gmaxwell: I kinda like the happiness and fun the people have in #dogecoin with using the meme. It will die out ofcourse, but they do have a strong community
21:05:30gmaxwell:maaku: if its not mandatory then the amlcoin risk exists. "not our problem your wallet isn't showing our payment, durn off this switch, it's broken"
21:06:03andytoshi:michagogo|cloud: strange, i'll refresh the download, one sec
21:06:55maaku:adam3us: I think that's the discussion I heard about
21:07:44andytoshi:michagogo|cloud: that is a bad hash, thx for letting me know, fixed now
21:07:48maaku:gmaxwell: with sufficient user level protections I don't rate amlcoin as a serious existential risk
21:08:22gribble:Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
21:08:55michagogo|cloud:andytoshi: woot
21:09:07michagogo|cloud:(so far, so good... no errors this time, it knows there's no open session)
21:09:52andytoshi:michagogo|cloud: excellent :) sorry, i forgot to stand up the testnet instance of the server, will do that now
21:10:19adam3us:* adam3us is old enough to remember people making analogous claims to reason about systematic MITM, CA malfeasance in the CA security model.
21:11:09michagogo|cloud:andytoshi: What's the format of cjclient.conf?
21:11:19michagogo|cloud:atm I see joinerserver = https://wpsoftware.net/coinjoin/cj-client.php in there
21:11:21michagogo|cloud:and that's it
21:11:24adam3us:maaku: (i was complaining at the time.. 1993ish that a dissident trusting CA infrastructure is crazy)
21:11:59maaku:adam3us: so? that was as sensible a thing to say then as now
21:12:26maaku:that doesn't mean you're right on this issue
21:12:30adam3us:maaku: people had all kinds of reasonable arguments how they'd never do that. it could be detectable. it was unreasonable etc. i am seeing analogies in your assumption that viral ecosystem features would not be abused
21:12:46michagogo|cloud:andytoshi: (I mean, what are the other options)
21:12:49maaku:apples and oranges
21:12:53andytoshi:michagogo|cloud: rpcconnect, rpcuser, rpcpassword and rpcport all work as in bitcoind
21:13:08maaku:if the NSA demands the root cert from the CA, it *is* undetectable
21:13:16michagogo|cloud:So to use testnet I'd set rpcport = 18333?
21:13:26andytoshi:michagogo|cloud: yeah, that should work
21:13:29michagogo|cloud:And what's the URL?
21:13:38maaku:covenants, on the other hand, by their very nature are prominently part of the script
21:13:45adam3us:maaku: alternatively then what makes you confident it would not be abused? good behavior of the incumbent power bases? the possible motivated parties include the combined weight of the banking lobby and governments.
21:14:01maaku:to do... what exactly?
21:14:21michagogo|cloud:andytoshi: bleh...
21:14:26michagogo|cloud:Syncing with joiner, session ID unknown
21:14:26michagogo|cloud:Join server: SSL: no alternative certificate subject name matches target host name 'testing.wpsoftware.net'
21:14:42maaku:force me to convert a coin into something which is unspendable because it fails IsStandard, is not relayed, and not accepted by anybody?
21:14:44adam3us:maaku: anything that is expedient if history teaches us anything. mandate viral amlcoins per example
21:14:49andytoshi:michagogo|cloud: sorry, testing.wpsoftware does not have an SSL cert, just use HTTP
21:15:05michagogo|cloud:Ah, k
21:15:35adam3us:maaku: no thats my point. things which are not supportable by the infrastructure of all users are harder to foist on the users.
21:16:45adam3us:maaku: its not a given, and its a possible risk point, that all bitcoin wallets will remain open source, depending n the parties that get into the wallet & wallet integration/bundling business
21:16:45andytoshi:michagogo|cloud: ok, how about we do a 1.1 testnet join?
21:16:46michagogo|cloud:andytoshi: "Joiner status: session not found."
21:17:02andytoshi:michagogo|cloud: oh :P click "Session->Forget Session"
21:17:07andytoshi:oh, wait..
21:17:14maaku:adam3us: at least where there is rule of law, taking away someone's capability to use their property is amount to theft
21:19:16adam3us:maaku: i agree, and thats a libertarian argument, but even neutral biz people will propose doing something pragmatic that appeases the regulator so they personally can make money fast. its not that they are evil, just that they dont care. if people with this mentality have software deployment power the can cause a lot of damage. eg apple?
21:21:52adam3us:maaku: back on interest and contracts. is there another way to achieve that? when i was thinking about extrospection i found it curious that much was achievable via hashlock and dependent transactions
21:21:57spenvo:sorry about that
21:22:43adam3us:maaku: jtimon gave an example of something he claimed was impossible without covenants?
21:22:44maaku:adam3us: but my point is how could their proposal ever fly? people would reject it because their coins would suddenly become unspendable, there'd be lawsuits, etc.
21:22:57maaku:all before it gets far enough along to be entrenched
21:23:24maaku:adam3us: yes, restricted buy-back (of IOUs, to use his example)
21:23:28adam3us:maaku: i dont know. but the adversary is adaptive and intelligent also. coinvalidation would itself be viral
21:24:10maaku:you issue an asset with 1% demurrage with an attached covenant allowing you to buy it back at any time for principle + interest (implemented by sending regular coins to the script stripped of the covenant)
21:24:45michagogo|cloud:andytoshi: I ticked my inputs and clicked view transaction
21:24:49michagogo|cloud:Now it's frozen
21:25:43adam3us:maaku: so what about a micro-channel. either party can pull-out and claim whats paid to date. interest paid periodically.
21:25:58andytoshi:michagogo|cloud: aw, shit
21:26:12michagogo|cloud:andytoshi: Oh, wait
21:26:14maaku:adam3us: tx replacement? vulnerable to double-spend
21:26:31michagogo|cloud:Just opened up a tailf on bitcoin's debug.log
21:26:48michagogo|cloud:Looks like it's busy drawing addresses
21:27:07andytoshi:how many output did you ask for?
21:27:08maaku:not to mention you wouldn't be able to move around ownership (resell debt)
21:27:15andytoshi:it shouldn't do an infinite loop if that's what you're seeing
21:27:29adam3us:maaku: or is there a less powerful language feature that could enable the class of use cases?
21:27:42maaku:adam3us: that would be entirely missing the point
21:28:03maaku:we *want* these crazy covenant use cases
21:29:12maaku:it's just doing so with the decentralized host currency that is problematic
21:29:16michagogo|cloud:andytoshi: My output is in the 5 digits
21:29:28adam3us:maaku: most of the examples on the covenant bct thread looked grey-goo like in their end game.
21:29:41michagogo|cloud:andytoshi: I think it's drawing ~21k keys...
21:29:48maaku:well that was the point of the covenant thread
21:30:04andytoshi:michagogo|cloud: hahahaha, ok, i should definitely do a sanity check there
21:30:25andytoshi:(and you probably want to kill it)
21:30:29adam3us:maaku: what i suggested to vitalik whe he asked me something about something ethereum was using is that scripts be certified. then at least users can see who is proposing they do this as a sanity check.
21:30:33michagogo|cloud:It's about half-way done
21:31:02maaku:adam3us: that's something for the payment protocol
21:31:31adam3us:maaku: (he's using some PoW thing i mentioned to him in ethereum it seems)
21:32:23justanotheruser1:maaku: I see. Do you think anything but PoW could work?
21:32:32adam3us:maaku: i mean of the script itself, like maybe you dont want to accept financial covenants unless they are certified as safe and fair by a competent
21:32:48andytoshi:michagogo|cloud: ok, if you're willing to let it go that'll be a good test to see if you can break something
21:32:59maaku:justanotheruser1: what for consenus? no. proof-of-work is absolutely perfect
21:33:24maaku:the defficiencies people often quote are actually what makes it work
21:33:38Luke-Jr:far from perfect imo
21:33:43justanotheruser1:maaku: No it isn't. Someone 20% of the processing power could reverse 6 confirmations within a day
21:33:53adam3us:maaku: missed this bit "just doing so with the decentralized host currency that is problematic" thats interesting. so u think it could be safe for issued assets (peer issued or central issuer issued)
21:34:25maaku:Luke-Jr: idk, the only viable improvement I've seen is gmaxwell's timelock-encryption, although that has more problems than it solves
21:34:30maaku:at the moment
21:34:38michagogo|cloud:2014-01-15 21:34:29 keypool reserve 17592
21:34:53Luke-Jr:maaku: I didn't say I knew something better, just that PoW isn't perfect :P
21:34:54adam3us:maaku: well i guess eg an issuer like a gold depositary or a mortgage issuer might put some pretty bad terms in the fine print that u are not qualified to evaluate
21:35:06maaku:justanotheruser1: and there's no getting around that. not without compromising what PoW gives you
21:35:25maaku:don't mistake a rule of thumb (6 confirms) with the actual security model of proof of work
21:35:38justanotheruser1:maaku: I never said there is a way to get around that. I just am pointing out that it is an imperfection.
21:35:56maaku:adam3us: sure, who cares if you put a crazy grey-goo covenant on your personally issued asset?
21:36:07maaku:in freimarkets at least, where user assets aren't host currency
21:36:16adam3us:maaku: the person who bought it cares maybe
21:36:50justanotheruser1:whats freimarkets
21:37:06maaku:adam3us: yes, but all your fears about regulation etc. could just as easily be applied to the person who issued it in real life
21:37:06adam3us:maaku: especially if it was expensive or the issuer is a bank say
21:37:40gmaxwell:that goes back to the point I made earlier about distinguishing the currency vs other things and not allowing the grey-goo on the currency.
21:37:49gmaxwell:(nice metaphor)
21:37:54adam3us:maaku: this is true. well i mean there is regulation in the market weak though it is, and hackable by banksters as it is, to protect consumers from malicious financial instruments
21:38:32maaku:adam3us: the benefit here is that there is a mechanism for stating the conditions of these financial instruments, in a way which can't be retroactively changed
21:38:42maaku:that is actually pro-consumer
21:39:22maaku:(idk. maybe we end up using old-style bitcoin scripts for host currency outputs, to avoid the grey-goo, or disable opcodes)
21:39:31adam3us:maaku: yeah that i like and is a central promise of smart-contracts as applied to block-chain validation
21:40:26adam3us:maaku: but at a high-level would you no want to constrain the covenant to the instrument, not have it infect and convert other assets into the same form somehow. not sure how to do that.
21:40:44michagogo|cloud:andytoshi: Ah, so you just call createrawtransaction?
21:40:54maaku:justanotheruser1: ok i'm a pragmatist who defines "perfect" as the best which can be actually achieved :)
21:41:31justanotheruser1:maaku: okay.
21:41:31maaku:justanotheruser1: https://bitcointalk.org/index.php?topic=278671.0
21:41:55michagogo|cloud:andytoshi: Hmm, I clicked the "Submit Transaction to Joiner" button
21:41:59michagogo|cloud:Nothing seems to have happened
21:42:17michagogo|cloud:http://testing.wpsoftware.net/coinjoin/ doesn't show there being a session
21:43:25justanotheruser1:maaku: is there a reason this has to be part of bitcoin and not just merged mined with it?
21:43:59maaku:adam3us: I think if you disabled the LOAD_TRANSACTION opcode in host currency, all of these fears would disappear
21:44:20maaku:justanotheruser1: what are you talking about?
21:44:49justanotheruser1:maaku: What do you mean by "an extension of bitcoin"?
21:46:08maaku:justanotheruser1: freimarkets is an extension of the bitcoin protocol. it adds new features by changing the transaction format, introducing new scripting opcodes, and changing the validation rules
21:46:12maaku:this are hard-fork changes
21:46:29justanotheruser1:maaku: does it have merged mining?
21:47:01maaku:justanotheruser1: that's a tangential question. this could in principle be applied to bitcoin in a future hard fork
21:47:23maaku:but given that the chance of this happening in bitcoin itself is approximately nil, we're going to deploy it in freicoin and freicoin will be merged mined against bitcoin
21:48:00maaku:so yes, it will be merged mined, but that's a point separate from the proposal itself
21:49:23michagogo|cloud:andytoshi: aha, the cj-client tries to spend to the mainnet fee/donation address
21:49:32michagogo|cloud:So it fails because that address isn't valid
21:51:18justanotheruser1:maaku: whats the difference between this and protoshares an mastercoin?
21:51:18justanotheruser1:and coloredcoins
21:51:46maaku:justanotheruser: read the thread
21:51:57justanotheruser:I am
21:52:19michagogo|cloud:andytoshi: Heh, I tried manually creating that transaction
21:52:30maaku:also this one : https://bitcointalk.org/index.php?topic=280292.0
21:52:51michagogo|cloud:On attempt to submit to the coinjoiner's web interface, 413 Request Entity Too Large
21:52:51maaku:(more appropriate to post there if you have technical questiosn than the crowdfund thread)
21:57:07adam3us:maaku: anyway enough from me about hypothetical systemic risks, I am actually quite interested in the potential of smart-contracts, and like the extensions you put in freimarket from a programming perspective.
21:57:52maaku:adam3us: what do you think about simply disabling the load-transaction opcode in the host currency? i feel silly for not thinking of this before the long-winded argument
21:58:01adam3us:also maybe i am not enuf of a forth-fan but bitcoin scripts seem kind of hard to read & program with. maybe it was envisaged that there would be some higher level language translated into it
21:58:21maaku:yeah forth is kinda on the level of intermediate code
21:59:43adam3us:maaku: i dont know what load-tx does?
21:59:47gmaxwell:adam3us: really? I think forth is basically ideal.
22:00:09gmaxwell:adam3us: The problem with higher level languages is that they're easy to hide subtle behaviors in.
22:00:21adam3us:gmaxwell: taste i guess. i did some dc programming, kind of reminds me. yes unambiguity is a good thing
22:00:41maaku:adam3us: load-transaction is how all these covenants are accomplished - it pushes the transaction onto the stack so it can be examined by the script
22:00:42adam3us:maaku: i guess the extrospection hook?
22:00:50gmaxwell:"oh look, this does exactly the opposite of what you expected because the hostile author took advantage of some order of operations subtly"
22:01:23gmaxwell:The forth is high enough level to express what it means, mostly, but low enough level to also express what it does.
22:01:49adam3us:gmaxwell: only complaint is like readability. especially with the long OP_BLAH names.
22:01:55gmaxwell:takes more study to understand than something higher level but has a harder time lying to you.
22:02:04gmaxwell:oh well yea, surely better tools could be done for working with it.
22:02:51gmaxwell:including things like pesudo opcodes that compress common and easily explained idioms.
22:04:10adam3us:maaku: does that kill interest bearing loans denominated in freicoin but not in maakucoin (self-issued iou)? there is some feature downside implied.
22:06:44maaku:adam3us: yes you would have to use user-issued IOUs, although that was the original scenario
22:07:11maaku:in fact I'm not sure how you'd do the loan trading freicoins for freicoins
22:07:26maaku:the point was that you loan the freicoins into existence
22:08:17maaku:you could still do some nasty things based on UTXO state (maybe you disable that as well)
22:08:31adam3us:maaku: doesnt that risk uncontrolled supply side inflation?
22:08:56maaku:that's ... rather the point isn't it?
22:09:02maaku:debt-based IOU currency
22:09:36maaku:maybe there's a misunderstanding here? i'm not sure what it is
22:09:40adam3us:maaku: fair enough there, but in relation to there existing two types: mined freicoins with demurrage and iou ones
22:12:06maaku:well sortof. IOU freicoins are actually freicoins, just a promise from whoever issued them to eventually, someday redeem them
22:12:31maaku:they're only usable as currency in so much as other people are willing to accept that IOU promise
22:12:55maaku:ripple is built on this premise
22:13:31gmaxwell:How is ripple doing btw?
22:13:32adam3us:maaku: but then you have the ripple graph of trust so they can circulate, quite far from the issuer and his immediate friends indirectly
22:14:01maaku:oh i meant pre-OpenCoin ripple. no idea what they're up to :)
22:14:43maaku:adam3us: yes, and with sub-transactions you can build atomic movements of these IOUs through the trust graph
22:14:43adam3us:maaku: i think it'd be fair to call this real-ripple.
22:15:06gmaxwell:meh. I still think real-ripple ought not need a global consensus system.
22:15:30maaku:but where there are gaps in the graph, exchanging IOU-for-freicoin instead of IOU-for-IOU lets you get hard currency
22:16:02maaku:gmaxwell: agreed, except when you want to interact with non-ripple assets like bitcoin/freicoin
22:17:00maaku:jtimon and I are planning on having these user assets be off-chain, but using the same scripting system so you can coordinate movements with the chain when public assets are involved
22:17:01gmaxwell:maaku: well, when you want to interact with them in a way which isn't trusting of an issuer.
22:20:00midnightmagic:real-ripple didn't.
22:21:52maaku:midnightmagic: unfortunately the distributed protocol was never implemented :\
22:22:08midnightmagic:yah. sad-midnight-face
22:31:53andytoshi:michagogo|cloud: sorry, was afk
22:31:58andytoshi:michagogo|cloud: one moment, cj
22:32:25andytoshi:michagogo|cloud: one moment, cj-client doesn't choose the donation address, the server does, but i forgot to set that for the testnet version
22:57:38andytoshi:michagogo|cloud: gonna head out now, will work on this later tonight, i have having decode problems that didn't happen with mainnet, sorry
23:10:34jgarzik:adam3us, unlinkedable static address... USA! USA! USA!
23:10:41jgarzik:* jgarzik waits for the conspiracies to start
23:11:30adam3us:jgarzik: not getting conspiracy part?
23:12:08jgarzik:adam3us, a poor attempt at a joke. e.g. paid by USA to develop tech whose acronym is USA
23:12:26adam3us:jgarzik: oooh.. didnt notice the acronym :)
23:12:33jgarzik:plus an acknowledgement that the bitcoin community will imagine a conspiracy for all events.
23:12:48jgarzik:It's like the multiverse of conspiracies
23:12:56jgarzik:quantum conspiracy theory
23:13:43adam3us:jgarzik: just wish i could find an efficient spv compatible version (or a replacement for bloom that worked with them).. would be sooo nice to forget about address reuse and battling user confusion and wallet author laziness
23:14:33sipa:that seems contradictory
23:14:43sipa:you want something that achieves privacy from the public
23:14:51sipa:but still want them to do efficient filtering for you
23:15:06jgarzik:adam3us, TBH it's not just laziness. Even if my bitcoinj-based Bitcoin Wallet was [hopefully] updated to reuse addresses tomorrow, you still have a problem of address reuse being practically mandated by circumstance, in the other direction:
23:15:06adam3us:sipa: when presented with a key though
23:15:12jgarzik:miner payouts, salary payouts, etc.
23:15:25jgarzik:no good way exists to give a payment stream a set of addresses
23:15:33sipa:adam3us: they could reveal that key
23:15:36TD:wallet author lazyness
23:16:04TD:adam3us: you can follow HD wallets in bitcoinj development work here: https://code.google.com/r/hearn-bitcoinj/source/list?name=keychain
23:16:12TD:as you can see lots of code has been going in for the past 6-7 weeks
23:16:30adam3us:jgarzik: yes indeed. well there is a mix of like wallets that only support one address supposedly? and then there are real problems. signature lines, biz cards, etc they are truly simpler to use and understand and in some use-cases hard to avoid!
23:16:44Luke-Jr:jgarzik: HD wallet spec has stuff for that
23:16:51TD:adam3us: design doc is here, to give you a flavour of how complicated the work is: https://code.google.com/r/hearn-bitcoinj/source/browse/designdocs/Deterministic%20wallets.txt?name=keychain
23:17:37jgarzik:Luke-Jr, yes, any derivation scheme fits the use case
23:17:39adam3us:jgarzik: "no good way exists to give a payment stream a set of addresses" well like Luke-Jr said shared subwallet chain-code should work for stream
23:17:43jgarzik:as long as it is standardized
23:17:51jgarzik:and private
23:18:13jgarzik:the whole world doesn't need to track my salary
23:18:20Luke-Jr:but it's so fun! <.<
23:19:14jgarzik:I would love to find a solution for mass payouts killing privacy. the solution seems to be "send a bunch of little TXs", which is network-unfriendly.
23:19:48TD:* TD shrugs
23:19:52TD:the point of bitcoin is to move money, well
23:19:57TD:that's why we need to scale the tech
23:20:01kinlo_:kinlo_ is now known as kinlo
23:20:06TD:so we're not afraid of making little transactions if that's what it takes to give good privacy
23:20:29TD:adam3us: anyway if you're feeling non-lazy you're welcome to help chip in with the implementation .....
23:20:33adam3us:TD: scary looking spec there. btw relatedly petertodd was saying that bloom is not that private with default parameters
23:20:48TD:yeah current bitcoinj has a default very low false positive rate and a few bugs
23:21:04TD:ways the remote node can trick you into revealing whether you own a particular key, stuff like that
23:21:21TD:we experimented with a higher FP rate in this dev cycle but it wasn't usable on 3G connections. so we need to add a notion of bandwidth modes to the API
23:21:38TD:then if we're on wifi we can ramp it up, etc
23:21:47TD:either that, or some kind of auto measurement/adaptation, but that's harder
23:21:48sipa:well, as long as bitcoinj wallets reuse addresses by default, there's little point in trying to protect privacy using bloom filters )
23:22:00TD:yeah - that's why i'm working on HD wallets at the moment and not bloom filtering :)
23:22:11adam3us:TD: still i wonder if its more private still than the prefix idea prefix leaks to all and interacts badly with existing statisical network analysis
23:22:12sipa:yeah, i know, not commenting there
23:22:23am42:guys i want to buy safe bTC wia Western Union
23:22:30am42:or MoneyGram
23:22:32TD:but as you can see from the design doc ..... well, bitcoinj wallet class got a lot of features over the years, so making sure none of them break and the upgrade is smooth, takes a lot of work
23:22:32adam3us:sipa: ha ha
23:22:41am42:how to do that safe?
23:23:21sipa:am42: not here, try #bitcoin
23:23:35wallet42:td: will bloom filters work with stealth addresses?
23:23:50adam3us:jgarzik: "I would love to find a solution for mass payouts killing privacy." this seems like a coin control issue.
23:23:52TD:i don't know. i haven't really worked through the details of ... lets call them "routing addresses
23:23:55adam3us:wallet42: i think not
23:24:42TD:but yeah there's an obvious conceptual issue there - bloom filters are intended to hide what the node should be looking for. but with stealth/routing addresses, the client doesn't know what it's looking for either, in a way
23:24:43adam3us:TD: i was suggesting unlinkable static (vs the current static aka reused).
23:24:56TD:with the payment protocol it might be different because then you don't have to find payments only via the chain
23:25:09TD:adam3us: yeah but i think "static" is jargony
23:25:19adam3us:TD: exactly. the client would have to give the node a private key to scan with. and that scanning is like heavy
23:26:02TD:if the payer submits the tx directly to the payee via bluetooth/http/other payment protocol methods that issue goes away of course
23:26:06TD:but then you have to be online
23:26:10adam3us:TD: and then i think there's no ambiguity left for bloom to work with. unless you upload a few other peoples private key also
23:26:11TD:or have a dropbox of some kind
23:26:40adam3us:TD: yes. i guess we cant or dont want to accept that as an assumption and also one or other part could get lost.
23:27:20adam3us:TD: routing address is not bad.
23:28:50adam3us:jgarzik: didnt petertodd write something called dust be gone that swept up all the tiny tracking spam payments into a corner so your wallet doesnt auto grab them? or coin control to not use them until you run out of bigger coins.
23:32:52TD:i think it paid dust outputs to miner fees
23:43:30EasyAt:I don't understand the use of these tracking outputs. Is it because if the TX is to me I will relay it, whereas if it isn't mine I'll drop it because it's dust?
23:44:08adam3us:EasyAt: apparently they send tiny payments to lots of people, then watch them be respent.
23:44:52EasyAt:Can't I just track outputs from a target address without tagging it
23:44:53adam3us:EasyAt: your wallet just grabs random inputs from whats in the wallet, "coin control" is not clever yet apparently. its like someone giving you marked pennies.
23:45:18adam3us:EasyAt: well not if someone is not reusing addresses so much.
23:45:47EasyAt:Yea, but once they target my address they can just watch all outputs and the chain of TXs following?
23:46:18maaku:EasyAt: these addresses are one-use only
23:46:19adam3us:EasyAt: i guess you could say its a way to force someone to reuse an address against their wish... send them unsolicited dust to their address.
23:46:29maaku:oh n/m
23:47:03sipa:i really prefer a model where you have to ask for every transaction you have to send first
23:47:20sipa:but it seems the bitcoin economy hasn't evolved that way
23:47:57adam3us:EasyAt: your wallet contains like 100 addresses and the wallet tries to not reuse them. so they know this particular address is yours for some reason. maybe the point is the dust payment is to the same address, and may get used in a different payment (even tho its the same address its a different txout)
23:48:00EasyAt:adam3us: Is it in the hopes that you will spend the dust with another output from a different address, thus leaking some info?
23:49:18adam3us:EasyAt: its not automatic that all payments from the same address would go in the same payment. its not balanced based so each txout is spent separately. if they see one of those dust payments respent with an address of yours they didnt know was yours, they do now
23:49:41adam3us:EasyAt: but i dont know who would care enough to waste btc dust to find out really. maybe some academics doing analysis or something?
23:50:18EasyAt:adam3us: Indeed, I follow you
23:50:25EasyAt:tainting people
23:50:35EasyAt:Or address grouping, I suppose
23:51:17EasyAt:sipa: In your model I would need permission from the receiver?
23:52:05adam3us:EasyAt: yes probably the latter. yes his model is that and would work, in an older version there was sent via IP which could've been more perission based as there was an interactive link anyway
23:53:02EasyAt:Interesting, thank your for the input
23:54:35adam3us:in an ideal world we'd have better privacy so people could send you small payments and it wouldnt matter.
23:55:35sipa:EasyAt: i would like that yes
23:55:49sipa:EasyAt: that you could not send coins without permission from the receiver
23:56:13EasyAt:How would cold wallets receive funds in that case
23:56:35sipa:nothing prevents it from being presigned
23:57:41EasyAt:Hm, then wouldn't I need prior knowledge of the TX? How about a cold wallet used for donations?