| 00:00:47 | jtimon: | mhmm I don't know how something that is not powed can be very strong |
| 00:01:06 | petertodd: | jtimon: how is it not PoW'd? |
| 00:01:46 | jtimon: | oh, I see, each chain mines on top of the previous timestamp, not the previous block of the subchain, no? |
| 00:02:00 | jtimon: | what if one chain goes faster? |
| 00:02:09 | petertodd: | heh, well, interesting question! |
| 00:02:46 | petertodd: | 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:24 | petertodd: | but that's far from the most interesting part of this stuff |
| 00:03:54 | jtimon: | the most interesting part is having ligher miners, no? |
| 00:04:20 | petertodd: | 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:12 | petertodd: | 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:09 | petertodd: | 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:23 | petertodd: | (normally you can't due to the timestamp property) |
| 00:09:02 | petertodd: | at least then if subchian data gets accidentally lost, somehow, the state of the system can recover. |
| 00:10:00 | petertodd: | 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:16 | petertodd: | and once you make a robust scheme with two subchains... it trivially extends to a full on tree |
| 00:10:20 | jtimon: | mhmm, I don't know...it seems very complex, maybe we just need to think about another way of sharding |
| 00:10:37 | petertodd: | it is very complex, but my suspicion is that sharding inherently is complex |
| 00:10:48 | petertodd: | just handwaving and assuming global consensus is *way* easier |
| 00:10:59 | petertodd: | pity it doesn't scale though |
| 00:13:19 | jtimon: | 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:40 | petertodd: | heh, well doing it with trust is easy :) |
| 00:13:40 | sipa: | jtimon: nah, that's just called ripple |
| 00:14:10 | jtimon: | sipa: no, I don't mean ripple, I mean something scalable |
| 00:14:28 | petertodd: | 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:42 | petertodd: | jtimon: ripple is scalable technologically, socially OTOH... |
| 00:14:45 | jtimon: | well, I haven't seen any centralized markets infinitely scalable |
| 00:15:06 | petertodd: | jtimon: ripple the idea isn't centralized |
| 00:15:18 | sipa: | i've mentioned it before, but i'd like to stop confusing the word 'centralized' with 'trust-free' |
| 00:15:47 | jtimon: | can the ripple.com network process 1 billion tx/s ? definitely no |
| 00:16:03 | sipa: | sorry, 'decentralized' with 'trust-free' |
| 00:16:07 | jtimon: | petertodd: 2PC ripple is compltely scalable |
| 00:16:28 | petertodd: | jtimon: exactly, ripple.com is an abomination and we shall not mention it again |
| 00:16:44 | sipa: | i shall resist. |
| 00:17:07 | sipa: | 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:31 | sipa: | it would be totally centralized (as in central point of failure), but to an extent trust-free |
| 00:17:50 | jtimon: | well, I think my centralized system is completely scalable, but maaku and I have to actually test that |
| 00:18:01 | maaku: | jtimon: another Joy-derived language that might be useful http://www.cat-language.com |
| 00:18:05 | petertodd: | sipa: which is roughly what my fidelity-bonded foo ideas were about, especially the fidelity-bonded ledgers version |
| 00:18:26 | sipa: | 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:32 | jtimon: | maaku I read that one has strong typing instead of dynamic |
| 00:18:54 | maaku: | yes, which would be a good thing i think |
| 00:19:14 | petertodd: | 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:36 | petertodd: | sipa: I think you can even pull that off as a soft-fork |
| 00:20:08 | sipa: | anyway, i'm not making any particular suggestion here |
| 00:20:26 | sipa: | just trying to point out that 'decentralized' is ambiguously used in bitcoin context |
| 00:20:27 | jtimon: | well, I try not to use ZKP or snark/scip when designing, haven't learned black magic yet... |
| 00:20:45 | petertodd: | jtimon: if it can't be done with hashes, it's not really bitcoin |
| 00:21:39 | jtimon: | sipa: I get your point, sometimes just trust-less is enough |
| 00:22:53 | jtimon: | maaku: why do you think strong typing would be better? the little I read about joy sounded very good |
| 00:23:52 | maaku: | jtimon: enforced strong typing is less likely to result in consensus bugss |
| 00:23:54 | jtimon: | like if I could even like the language and all |
| 00:24:04 | petertodd: | maaku: are you thinking of including those languages as libraries or what? |
| 00:24:06 | jtimon: | I see |
| 00:24:24 | jtimon: | replacing the current scripting I think |
| 00:24:36 | maaku: | petertodd: currently hypothetical replacements for script |
| 00:24:54 | sipa: | any reason why you'd use a stack-based language, and not something ast-based? |
| 00:25:14 | sipa: | (i've been following about 1% of the discussions here the past weeks, i've certainly missed a lot) |
| 00:25:30 | jrmithdobbs: | rust txn scripts please! |
| 00:25:31 | jrmithdobbs: | ;p |
| 00:25:38 | petertodd: | 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:16 | petertodd: | maaku: strong typing means you have types, and types themselves are a bunch of code with potential consensus failures |
| 00:26:39 | maaku: | 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:59 | maaku: | 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:14 | sipa: | you can do the same for an AST like language |
| 00:27:20 | sipa: | well, in one direction at least |
| 00:27:48 | sipa: | and i'm sure it's much closer to the domain we're representing |
| 00:28:12 | jtimon: | maaku wasn't there more reasons to chose a concatennative lang ? http://en.wikipedia.org/wiki/Concatenative_programming_language |
| 00:28:23 | petertodd: | sipa: I think the big question is do you need the self-modifying code that forth makes possible? |
| 00:28:32 | petertodd: | sipa: for quines it's certainely useful |
| 00:28:49 | sipa: | quines? what do you need that for |
| 00:29:02 | maaku: | sipa: covenants |
| 00:29:15 | sipa: | another thing i need to read... :'( |
| 00:29:16 | petertodd: | sipa: IE things like SPV-verifiable colored coins |
| 00:29:52 | petertodd: | 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:10 | jtimon: | basically, forcing the outputs of the next transaction to have certain code in their scripts |
| 00:30:29 | jtimon: | well, maybe only some of the outputs |
| 00:30:48 | maaku: | and Forth-like languages are really good for this sort of thing, although not required |
| 00:30:51 | sipa: | right |
| 00:31:09 | maaku: | since you basically just have to test the prefix of the output script |
| 00:31:12 | petertodd: | also, merklized abstract syntax tree schemes *are* very forth compatible, even the self-modifying quine versions |
| 00:31:24 | jtimon: | actually petertodd the colored coins example was confusing to me because of regular colored coins and freimarkets |
| 00:31:36 | petertodd: | forth is just symbol tables, and symbol's can just as equally be merkle hashes |
| 00:32:47 | maaku: | petertodd: re simplicity, that's why i'm looking at Joy/Cat. it's basically two dozen or so combinators + builtins |
| 00:32:53 | maaku: | and a syntax that is even simpler than LISP |
| 00:33:23 | petertodd: | 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:47 | jrmithdobbs: | 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:51 | petertodd: | maaku: syntax has nothing to do with what goes in the chain necessarily... :) |
| 00:34:07 | petertodd: | jrmithdobbs: because satoshi didn't want a complex symbol table! |
| 00:34:16 | panicearly: | panicearly has left #bitcoin-wizards |
| 00:34:16 | petertodd: | jrmithdobbs: script is even *simpler* than forth |
| 00:34:20 | jrmithdobbs: | petertodd: i know |
| 00:34:42 | jrmithdobbs: | petertodd: but forth is such a great fit for this use case ;p |
| 00:34:44 | maaku: | 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:21 | petertodd: | jrmithdobbs: agreed |
| 00:35:53 | maaku: | 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:09 | gmaxwell: | 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:19 | gmaxwell: | maaku: I don't think a counter is sufficient for resolving "worries" |
| 00:36:37 | petertodd: | maaku: I'm sure he did, and thought of additional issues |
| 00:36:52 | maaku: | gmaxwell: i think the DoS preventions I mentioned in the scrollback solves the remaining worries |
| 00:36:56 | maaku: | is there something I'm missing? |
| 00:36:56 | petertodd: | maaku: though then again, counting sigops in un-exectuted scriptPubKeys was a damn stupid idea |
| 00:37:24 | jrmithdobbs: | petertodd: ya i was going to say, i think you're inferring too much credit there |
| 00:37:32 | jrmithdobbs: | s/in/con/ |
| 00:37:53 | petertodd: | jrmithdobbs: indeed |
| 00:38:10 | sipa: | 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:23 | petertodd: | maaku: the DoS preventions work even better when you do per-tx PoW schemes |
| 00:38:26 | gmaxwell: | 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:10 | jtimon: | petertodd how don't you hardcode the per-tx pow? |
| 00:39:11 | petertodd: | gmaxwell: the latter problem isn't specific to execution counters, heck, even the former isn't totally |
| 00:39:20 | jrmithdobbs: | gmaxwell: or emulating some other form of state/etc through some other trickery that would hurt everyone's head |
| 00:39:23 | petertodd: | jtimon: why would it be hardcoded? |
| 00:39:30 | jrmithdobbs: | gmaxwell: those are the really scarey ones imho |
| 00:39:34 | maaku: | gmaxwell: yes, well that's why I'd prefer a simple language with a minimal number of primitives and implementation complexity ... |
| 00:39:38 | gmaxwell: | petertodd: no but IP counting is actually much harder when you've implemented a tracing JIT. |
| 00:40:01 | maaku: | i think you could implement Joy/Cat with the same or less lines of code as current bitcoin script |
| 00:40:07 | gmaxwell: | (A significant fraction of all code execution bugs in firefox have been in the JITs) |
| 00:40:14 | jtimon: | 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:32 | petertodd: | gmaxwell: well, that's an argument against sophisticated scripting in general too... |
| 00:40:33 | jtimon: | /pater/peter |
| 00:40:47 | gmaxwell: | 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:06 | petertodd: | jtimon: well, *absolutely* simpliest is to say a block has a single tx in it :) |
| 00:41:18 | gmaxwell: | 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:31 | jtimon: | I thought it was per-tx pow apart from block pow, the thing I'm more confortable with are "optional pow fees" |
| 00:43:13 | petertodd: | 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:57 | jrmithdobbs: | gmaxwell: is replacing the script being seriously considered or just a toy conversation? |
| 00:43:58 | petertodd: | 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:26 | sipa: | jrmithdobbs: even gavin has mentioned it (though i'm sure he's thinking about much less exotic changes) |
| 00:44:45 | maaku: | jrmithdobbs: jtimon and I are seriously considering it in the context of trying it out on an altchain (freicoin) |
| 00:45:08 | petertodd: | maaku: and it's on my list of things that I need to research for MSC |
| 00:45:09 | gmaxwell: | jrmithdobbs: most of this is speculative conversation. The thing I'd want to replace it with isn't yet realistic to deploy. |
| 00:45:19 | maaku: | although given all the other more important stuff on our plate, it's still a very hypothetical conversation |
| 00:45:28 | jrmithdobbs: | gmaxwell: which is? |
| 00:46:10 | jtimon: | 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:13 | petertodd: | maaku: well, for me it's a top priority |
| 00:46:21 | sipa: | 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:33 | gmaxwell: | 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:46 | petertodd: | sipa: mostly agree there, what's interesting is what types of data would that script have access too? |
| 00:47:02 | sipa: | i don't think byte arrays as data type is such a bad idea |
| 00:48:27 | jtimon: | gmaxwell sipa will an AST really be simpler for script coders? |
| 00:48:47 | gmaxwell: | (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:48 | jrmithdobbs: | jtimon: huh? of course it would |
| 00:48:48 | maaku: | gmaxwell: the SNARK would still have a language it understands though, right? (e.g. tinyram) |
| 00:49:21 | gmaxwell: | maaku: no. What I'd do is just implement a generic snark validation, and providing the snark verification key in the transaction. |
| 00:49:22 | petertodd: | sipa: that's not what I mean actually, I mean does the script have access to things like txins, txouts, blockchain headers? |
| 00:49:30 | sipa: | petertodd: for bitcoin, no |
| 00:49:32 | jtimon: | jrmithdobbs I mean simpler than Joy, not simpler than the current one |
| 00:49:52 | sipa: | petertodd: well, generalizing the hashtypes may be useful |
| 00:50:25 | maaku: | 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:31 | sipa: | but that's not really an interesting discussion - i'm being intentionally conservative here |
| 00:50:48 | gmaxwell: | maaku: it's pretty hard to write a compact script to do things with that access however. |
| 00:50:49 | petertodd: | sipa: yeah, where I'm really more focused on something you'd need for MSC, day job and all :P |
| 00:51:08 | gmaxwell: | It would be nice if people would write some hypothetical scripts. |
| 00:51:25 | maaku: | gmaxwell: hard to write a compact script? howso? |
| 00:51:27 | petertodd: | gmaxwell: that's also on my priorities list |
| 00:51:29 | gmaxwell: | 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:35 | maaku: | do you mean the interpretor, or the script(s)? |
| 00:52:24 | gmaxwell: | 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:09 | gmaxwell: | it's pretty easy to end up with a painfully complicated script just to do something conceptually simple. |
| 00:53:27 | petertodd: | maaku: you ever written any assembler code? |
| 00:53:39 | maaku: | ok, you mean in bitcoin script, yes |
| 00:53:43 | sipa: | 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:51 | maaku: | petertodd: look at the scripts we have in the back of the freimarkets paper ... yuck |
| 00:53:55 | sipa: | and you have end up with a single output |
| 00:54:27 | jtimon: | sipa, yeah, this http://en.wikipedia.org/wiki/Abstract_syntax_tree |
| 00:54:39 | maaku: | that's why I'd like a more powerful scipting language - even with opcodes re-enabled it's still a mess |
| 00:54:59 | gmaxwell: | 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:04 | sipa: | 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:41 | jtimon: | I meant that something like joy seems more powerful, thus simpler for the scripting language users |
| 00:55:53 | sipa: | scripting language users? |
| 00:56:07 | sipa: | i don't care about that - go use a compiler if necessary |
| 00:56:08 | jtimon: | the hackers writing bitcoin scripts |
| 00:56:09 | gmaxwell: | 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:20 | jtimon: | sipa: good point |
| 00:56:29 | jrmithdobbs: | 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:44 | gmaxwell: | 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:55 | sipa: | jtimon: i care about easyness by which an implementation (script interpreter) can be judged to be correct |
| 00:57:28 | maaku: | sipa: is there a specific AST that is a good match to bitcoin? |
| 00:57:49 | sipa: | give me a day and i'll write you one |
| 00:58:24 | gmaxwell: | 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:33 | maaku: | i just mean i'm wondering if you had something in mine, like lisp/scheme or the spineless, tagless machiens of Haskell |
| 00:58:43 | gmaxwell: | and it wasn't so simple that you could just look at it and tell for sure it was safe. |
| 00:59:41 | maaku: | jtimon: btw theorem prover mentioned by gmaxwell is why you'd want static typing |
| 00:59:51 | gmaxwell: | (for _sure_ not just 'sure'... as it would potentially have hundreds of BTC assigned to it in a day) |
| 01:00:25 | petertodd: | gmaxwell: so these theorem provers, what kinds of languages don't they exist for? |
| 01:00:31 | gmaxwell: | 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:44 | jtimon: | oh, gmaxwell, I forgot that open problem |
| 01:01:48 | gmaxwell: | 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:57 | sipa: | 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:03 | sipa: | 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:14 | gmaxwell: | 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:14 | sipa: | maaku: const[x] (just returns x) |
| 01:03:47 | petertodd: | 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:11 | jrmithdobbs: | petertodd: they exist in compilers like he wants, even, for that matter |
| 01:04:23 | jrmithdobbs: | petertodd: (haskell does some forms of this during compilation) |
| 01:04:28 | sipa: | 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:45 | gmaxwell: | 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:47 | sipa: | maaku: and then some basic arithmetic/crypto/string/... whatever operators |
| 01:05:12 | maaku: | sipa: i see. thank you this helps |
| 01:05:22 | gmaxwell: | petertodd: because things like pointer deferences make life insanely hard for the provers. (though, they're not completely impotent) |
| 01:05:23 | petertodd: | 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:34 | sipa: | maaku: you can map this indeed to a lazily evaluated functional language |
| 01:05:49 | sipa: | 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:50 | jrmithdobbs: | 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:13 | gmaxwell: | 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:35 | maaku: | sipa: i've been favoring strict over lazy due to implementation compleity and risk of consensus errors |
| 01:06:42 | maaku: | does the laziness gain you anything? |
| 01:06:46 | sipa: | speed |
| 01:06:52 | jrmithdobbs: | sipa: tbqh, a limited haskell98 with no IO monad would be perfect and without IO the runtime gets tiny |
| 01:06:59 | gmaxwell: | maaku: if we merkelize the untaken branches it also can get you improved privacy and reduced program size. |
| 01:07:12 | jrmithdobbs: | sipa: something like fay |
| 01:07:52 | maaku: | 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:53 | jrmithdobbs: | sipa: which is haskell98->js compiler sans typeclasses (so no monads period) |
| 01:08:14 | gmaxwell: | 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:52 | sipa: | 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:29 | gmaxwell: | 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:37 | sipa: | yup |
| 01:09:48 | jrmithdobbs: | ya that's the key part satoshi missed i think |
| 01:09:51 | gmaxwell: | This mental model obviously applies directly to the snark stuff, but it even works in conventional execution. |
| 01:10:29 | jtimon: | gmaxwell not with p2sh, does it? |
| 01:10:50 | sipa: | so, to elaborate a bit further |
| 01:10:54 | gmaxwell: | jtimon: we're talking about a generalization of P2SH that works recursively, effectively. |
| 01:11:03 | sipa: | you associate a hash with every ast node |
| 01:11:24 | maaku: | gmaxwell: what was that point about merkelizing in response to? |
| 01:11:35 | gmaxwell: | 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:44 | gmaxwell: | 17:06 < maaku> does the laziness gain you anything? |
| 01:11:49 | sipa: | gmaxwell: yup, that's easy to do |
| 01:12:10 | jtimon: | gmaxwell so you're saying that without the snark you need the merklization for what you want, got it |
| 01:12:20 | jrmithdobbs: | that question seems so backwards to me |
| 01:12:22 | sipa: | instead of associating a hash with every node, you only associate one with every "tree piece" |
| 01:12:24 | maaku: | oh i meant lazy vs strict parameter evaluation (e.g. Haskell) |
| 01:12:29 | jrmithdobbs: | after doing nothing but writing haskell for the last 2 months |
| 01:12:30 | jrmithdobbs: | lol |
| 01:12:40 | sipa: | tree pieces are delimited by choose operators |
| 01:12:42 | maaku: | yes you definately need lazy/short-cut conditionals |
| 01:12:51 | petertodd: | gmaxwell, sipa: remember that one potential way of doing this is rather explicitly with OP_EVAL and OP_HASH160 (essentially) |
| 01:13:09 | gmaxwell: | sipa: I think you could go further and have two kinds of choose operator, one that hashes and one that doesn't. |
| 01:13:39 | sipa: | gmaxwell: well there can be a regular ifthenelse operator |
| 01:13:44 | sipa: | that has no choose magic |
| 01:13:50 | gmaxwell: | right. fair enough. |
| 01:14:00 | sipa: | i'm saying the same thing i think |
| 01:14:27 | sipa: | except choose is special in that it explicitly takes a hash as argument, and not an expression |
| 01:14:43 | gmaxwell: | Right. |
| 01:15:21 | petertodd: | 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:32 | sipa: | but so is const or access, they don't take subexpression eithet |
| 01:15:54 | sipa: | petertodd: these are not imperative programs, there is no return operator |
| 01:16:02 | sipa: | they're just expressions |
| 01:16:18 | petertodd: | sipa: right |
| 01:16:44 | gmaxwell: | petertodd: even if there were you could always wrap hte hidden data with another choice. |
| 01:16:57 | petertodd: | gmaxwell: true |
| 01:17:16 | sipa: | yeah, choice is there to hide pieces of the script |
| 01:17:22 | sipa: | either because they are large |
| 01:17:27 | sipa: | or because they are private |
| 01:17:53 | petertodd: | sipa: hmm... so when is choice not something you can do with an if block? |
| 01:19:05 | gmaxwell: | (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:09 | sipa: | i don't think it's really an if in any caze |
| 01:19:18 | sipa: | let me come up with an example |
| 01:19:35 | sipa: | to do a 1-of-2 multisig |
| 01:20:07 | sipa: | let's say scriptA is something that fetches a sig from the stack and verifies it with pubkeyA |
| 01:20:08 | maaku: | hrm. I just realized that by executing code from the stack Joy/Cat makes it difficult to Merklize... |
| 01:20:21 | sipa: | scriptB is the same, but for pubkeyB |
| 01:20:45 | petertodd: | sipa: right |
| 01:21:22 | petertodd: | maaku: you can still merklize the initial code up to where the stack is executed |
| 01:21:23 | jtimon: | maaku: that seems right, I guess AST-script it is |
| 01:21:31 | sipa: | now you construct a script of the form choice(scriptA,scriptB), and put its merkle root in the output |
| 01:21:40 | sipa: | however, to spend it |
| 01:22:00 | sipa: | you either use choiceL(scriptA,hash[scriptB]) |
| 01:22:18 | sipa: | or choiceR(hash[scriptA],scriptB) |
| 01:22:33 | petertodd: | sipa: see, I'm not sure how that's any different from IF ELSE ENDIF |
| 01:22:43 | petertodd: | sipa: which is how I always envisioned MAST to work |
| 01:22:54 | sipa: | it's an if then else, but the if/else is hardcoded |
| 01:23:00 | sipa: | it cannot be an expression |
| 01:23:54 | sipa: | its runtime semantics is just the identity |
| 01:24:06 | sipa: | it only affects how the hash of the script is computed |
| 01:24:51 | sipa: | note that choiceL(scriptA,hash[scriptB]) evaluates to just scriptA |
| 01:25:08 | petertodd: | 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:56 | sipa: | right, but i don't like to think of it in term of executable operations |
| 01:26:23 | sipa: | it's just a tree with certain parts covered, by giving a hash instead |
| 01:26:39 | petertodd: | well, we're using similar words for the same thing :) |
| 01:26:44 | sipa: | sure |
| 01:27:06 | sipa: | but i think your original question really was |
| 01:27:21 | petertodd: | 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:36 | petertodd: | yet you can still arrange such that code that's never executed is never provided |
| 01:27:42 | sipa: | that's over my head :) |
| 01:28:14 | sipa: | anyway |
| 01:28:32 | sipa: | one question is if there are other merkle-choosing-like operations possible |
| 01:28:52 | sipa: | which do not mimick if-then-else |
| 01:29:53 | sipa: | i think if you have some for(i in [0..n], f(i)) operator |
| 01:29:58 | petertodd: | sipa: tl;dr: forth can do the magic that lisp can do, not with macros, but with self-modifying code |
| 01:30:01 | sipa: | with n a constant integer |
| 01:30:08 | petertodd: | right |
| 01:30:15 | sipa: | then you can have a merkle version of it as well |
| 01:30:32 | sipa: | that takes the hash of the non-evaluated loops |
| 01:30:36 | petertodd: | and for that matter, you can do tail-recursion for loops too... |
| 01:30:49 | petertodd: | and that can still be merklized |
| 01:31:40 | sipa: | without needing to reveal how many loops you wanted to be possible |
| 01:31:55 | gmaxwell: | 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:05 | sipa: | haha |
| 01:32:08 | maaku: | petertodd: how are you going to merklize forth? |
| 01:32:57 | maaku: | ah, are you thinking of replacing a quoted block with its merkle hash? |
| 01:33:35 | petertodd: | maaku: remember, we're merklizing the potential code that can be run |
| 01:34:13 | petertodd: | 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:26 | gmaxwell: | sipa: so, linear iterative compression. |
| 01:35:38 | gmaxwell: | say you have some straight line code that can stop at some point. |
| 01:35:49 | maaku: | 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:05 | maaku: | in other words, push the code on the stack before execution |
| 01:36:11 | petertodd: | maaku: correct |
| 01:36:50 | maaku: | 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:57 | gmaxwell: | 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:05 | maaku: | ok that would work |
| 01:37:13 | petertodd: | 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:21 | gmaxwell: | I think that structure is not equal to choices. |
| 01:37:24 | sipa: | gmaxwell: that's exactly what i meant |
| 01:37:29 | sipa: | with the for loop |
| 01:37:37 | gmaxwell: | okay, good then I came about to the same thought. |
| 01:37:58 | gmaxwell: | is there something that generalizes those two? are there more? |
| 01:38:09 | sipa: | very good question! |
| 01:38:27 | sipa: | but it's really about some parametrizable control flow |
| 01:38:59 | sipa: | oh um |
| 01:39:09 | sipa: | this is an expression language |
| 01:39:17 | sipa: | a for loop doesn't really make sense |
| 01:39:23 | sipa: | but you can replace it by a fold |
| 01:39:55 | sipa: | fold(3,f,x) computing f(f(f(x))) |
| 01:40:04 | petertodd: | sipa: you know, you can replace a for loop with repeated opcodes, and zlib compression... |
| 01:40:24 | sipa: | where that recursive hashing becomes much more apparent |
| 01:40:25 | maaku: | jtimon: see above ^^ |
| 01:40:40 | jtimon: | yeah |
| 01:41:00 | sipa: | petertodd: that doesn't allow hiding the number of iterations from the root hash |
| 01:41:02 | jtimon: | "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:45 | jtimon: | maybe it's relevant although I'm starting to get tired and following your interesting conversation gets harder |
| 01:41:52 | petertodd: | sipa: ah, your example of a for loop is to loop based on a stack constant, not a symbol constant? |
| 01:42:14 | sipa: | petertodd: based on a constant given in the spending script |
| 01:42:24 | petertodd: | sipa: yeah, that's different |
| 01:42:30 | sipa: | petertodd: but NOT given in what goes in the root hash |
| 01:42:44 | gmaxwell: | fundimentally the _maximum_ depth of the loop could be hidden. (mean I can describe a language that allows this) |
| 01:42:45 | petertodd: | sipa: yup |
| 01:43:32 | sipa: | yes, you need to know a maximum iteration count |
| 01:44:30 | sipa: | but you don't have to reveal it |
| 01:45:46 | gmaxwell: | 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:49 | sipa: | .. you lost me |
| 01:47:35 | gmaxwell: | sipa: you know how a lamport signature works, right? |
| 01:48:49 | sipa: | more or less, yes |
| 01:48:55 | gmaxwell: | 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:16 | sipa: | hmm |
| 01:50:25 | sipa: | i need to see that on paper |
| 01:50:27 | sipa: | but now now |
| 01:50:47 | gmaxwell: | 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:21 | sipa: | right |
| 01:51:31 | sipa: | so you weigh a smaller signatures over deeper hashes |
| 01:51:59 | gmaxwell: | 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:13 | gmaxwell: | in any case, that covers both the kinds of branching we've talked about. |
| 01:54:03 | gmaxwell: | 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:21 | gmaxwell: | or at least these signature schemes should express themselves very naturally in the script. |
| 01:57:09 | gmaxwell: | 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:15 | sipa: | gmaxwell: actually, that fold operator can just be encoded using choice |
| 01:57:49 | sipa: | at every iteration you do a choice that just contains another instance of f |
| 01:57:51 | gmaxwell: | choiceL( choice(choice())) |
| 01:57:52 | gmaxwell: | yea.. |
| 01:58:38 | sipa: | of course, if you provide a normal language construct for fold |
| 01:58:47 | sipa: | as an optimization |
| 01:59:00 | sipa: | you could provide a merkleizing one too |
| 02:01:38 | gmaxwell: | 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:25 | gmaxwell: | I guess pubkey,r,s isn't going to be smaller for just three. Alas. |
| 02:02:38 | gmaxwell: | (so much for my ghetto homorphic hash idea. :P) |
| 02:19:56 | jcrubino: | is there a workbook for bitcoin wizards in training? |
| 02:22:29 | gmaxwell: | No. I suppose I should make a references list? |
| 02:22:40 | gmaxwell: | a lot of the things we discuss have no references though. |
| 02:22:58 | gmaxwell: | E.g. I can't cite anything for merkelized abstract syntax trees. |
| 02:25:44 | enodios: | enodios has left #bitcoin-wizards |
| 02:30:03 | sipa: | roconnor came up with those in an IRC pm with me :) |
| 02:44:13 | petertodd: | jcrubino: I keep threatening to write a book |
| 02:44:30 | jcrubino: | petertodd: I'll help |
| 02:44:44 | jcrubino: | Is it possible to download the dev mailing list from source forge? |
| 02:45:09 | petertodd: | jcrubino: I don't think so |
| 02:45:15 | petertodd: | how far back do you want? |
| 02:47:43 | jcrubino: | As far back as can be got |
| 02:47:48 | jcrubino: | I would like to do this: http://www.princeton.edu/~achaney/tmve/wiki100k/browse/topic-presence.html |
| 02:47:53 | jcrubino: | for the mailing lists |
| 02:48:48 | jcrubino: | tldr: topic modeling of the message contents |
| 02:49:28 | petertodd: | jcrubino: I've only got just under a years worth |
| 02:50:48 | jcrubino: | I could post to bitcointalk to ask for donations; but not sure how uniform they will be comming from different mail clients |
| 02:51:05 | petertodd: | jcrubino: well, test should be same I guess? |
| 02:51:13 | petertodd: | you can compare against different peoples copies by message id |
| 02:56:17 | jcrubino: | petertodd: how close to live release is mastercoin? |
| 02:56:37 | petertodd: | jcrubino: it has been released, for some value of "release" |
| 02:56:52 | petertodd: | jcrubino: there's live code out there that lets you move mastercoins around - is that useful however? good question |
| 02:56:57 | jcrubino: | true enough |
| 02:57:45 | jcrubino: | 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:24 | petertodd: | ...and what did you remember? |
| 02:58:29 | jcrubino: | A better question then is how far is bitcoin from 2.0? |
| 02:58:41 | sipa: | we're not even at 1.0... |
| 02:58:44 | jcrubino: | The good and the bad; he included it all |
| 03:01:47 | jcrubino: | sipa: will we have no idea what 2.0 will be untill we get there? |
| 03:02:04 | sipa: | i suppose |
| 03:02:05 | petertodd: | jcrubino: huh, interesting view of it... I'd say JR didn't include much at all, at least from what I remember |
| 03:02:20 | petertodd: | jcrubino: there will be multiple competing 2.0's is my prediction |
| 03:02:34 | sipa: | yeah |
| 03:05:53 | jcrubino: | 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:20 | sipa: | i doubt wizards are a subser of developers |
| 03:07:25 | sipa: | *subset |
| 03:07:39 | sipa: | here it's much more about things that are cool to think about, beyond-bitcoin |
| 03:07:47 | sipa: | some that may be far from ever being implemented |
| 03:08:44 | sipa: | i see myself much more as a developer than as a wizard (mostly because of lack of time to keep up...) |
| 03:09:37 | petertodd: | sipa: agreed, and in the exact opposite situation personally |
| 03:11:05 | andytoshi: | jcrubino: the first reference i was given here was about random oracles, and that led me through a very enlightening reference chase: |
| 03:11:06 | petertodd: | 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:10 | andytoshi: | http://blog.cryptographyengineering.com/2011/09/what-is-random-oracle-model-and-why.html |
| 03:11:13 | andytoshi: | http://blog.cryptographyengineering.com/2011/09/what-is-random-oracle-model-and-why.html |
| 03:11:16 | andytoshi: | http://cseweb.ucsd.edu/users/mihir/papers/ro.html |
| 03:11:37 | andytoshi: | also see the fiat-shamir paper and 'probabilistic encryption' by goldwasser and micali |
| 03:11:55 | andytoshi: | if you can grok all those, that's enough background to ask intelligent questions re the crypto discussion |
| 03:12:54 | andytoshi: | petertodd: you have a writeup about this which i think is a very concise introduction to that idea |
| 03:13:09 | andytoshi: | 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:28 | andytoshi: | s/concise/detailed |
| 03:13:43 | petertodd: | andytoshi: thanks |
| 03:13:55 | jcrubino: | thank you all, looks like some great reads |
| 03:14:12 | petertodd: | 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:24 | andytoshi: | 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:16 | andytoshi: | 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:26 | petertodd: | 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:34 | andytoshi: | 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:01 | andytoshi: | at that distance, i suppose it's just game theory, but decentralized distributed consensus systems give a very efficient model of this |
| 03:20:27 | andytoshi: | where a lot of the noise of human interaction is removed (by design) thanks to the trustless protocols |
| 03:22:24 | petertodd: | yup, and a very unforgiving model too, where you get to deal with relatively non-ideal participants |
| 03:22:38 | gmaxwell: | well when you spend a lot of time thinking in an adversarial model it changes how you think. |
| 03:23:22 | gmaxwell: | 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:30 | petertodd: | which is what the non-wizards find so hard to deal with - witness the discussions of GHas.IO for instance |
| 03:29:40 | gmaxwell: | 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:13 | gmaxwell: | I guess this happens with all things. Foo causes cancer! No it doesn't. Oh great! Everyone eat foo! Wait wait. |
| 03:30:55 | petertodd: | 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:43 | CodeShark: | 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:18 | petertodd: | 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:22 | gmaxwell: | CodeShark: well the whole question of 'residing' deserves a Mu. |
| 03:35:21 | gmaxwell: | 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:34 | andytoshi: | gmaxwell: oh, Mu is a very clean answer, thanks |
| 03:36:18 | petertodd: | gmaxwell: a good counter-question to that falicy is to ask people where does the song "Happy Birthday" reside exactly? |
| 03:36:21 | andytoshi: | gmaxwell: i spent an hour with a math grad the other day describing various cryptosystems and asking "where is the information stored"? |
| 03:36:24 | gmaxwell: | (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:02 | gmaxwell: | 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:50 | gmaxwell: | 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:05 | petertodd: | gmaxwell: also equally insane if you postulate an insecure signature algorithm that can be broken with 2^64 work |
| 03:41:36 | petertodd: | 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:19 | gmaxwell: | well, either that or it broke you completely and you're unable to reason without a pile of symbology in front of you. |
| 03:43:20 | petertodd: | heh |
| 03:45:42 | petertodd: | gmaxwell: probably a good thing I failed second year calc - the alternative was to be broken by it |
| 03:46:14 | andytoshi: | petertodd: second year calc is crap, it has no business being in a math degree |
| 03:47:06 | petertodd: | andytoshi: what did you do in second year calc? |
| 03:47:43 | andytoshi: | petertodd: half a dozen methods for computing second-year-calc integrals, and something about taylor series i think |
| 03:48:06 | andytoshi: | standard calc 2 fare, "here are some algorithms, run them by hand without ever checking hypotheses, hundreds of times" |
| 03:48:42 | petertodd: | 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:43 | andytoshi: | mathematical analysis was probably more difficult, but made far far more sense and was better motivated |
| 03:49:20 | gmaxwell: | I like that they don't even bother teaching people the chain rule in basic undergrad calculus anymore apparently. |
| 03:49:37 | andytoshi: | (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:49 | petertodd: | gmaxwell: wtf? |
| 03:50:09 | petertodd: | andytoshi: typical, impressing a girl... |
| 03:50:10 | andytoshi: | gmaxwell: they do at UTexas at least .. |
| 03:50:46 | gmaxwell: | andytoshi: whew. okay perhaps I was just talking to idiots then. |
| 03:51:38 | andytoshi: | petertodd: that's pretty-much it, a bit ironic that now i'm in grad school 2500km away from her |
| 03:52:02 | andytoshi: | 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:41 | petertodd: | 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:47 | petertodd: | ... calculus of variations. |
| 03:52:48 | andytoshi: | 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:57 | andytoshi: | petertodd: holy shit |
| 03:53:09 | gmaxwell: | 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:37 | petertodd: | 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:43 | petertodd: | ... power series |
| 03:54:15 | petertodd: | 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:17 | andytoshi: | 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:18 | petertodd: | instead just teach people a bunch of rules which actually are differentiation, but don't |
| 03:54:27 | petertodd: | andytoshi: heh, I don't feel so bad failing it then :) |
| 03:55:16 | petertodd: | 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:22 | andytoshi: | 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:52 | andytoshi: | 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:02 | petertodd: | andytoshi: ha, lovely, and I did that after like six years doing a fine arts degree |
| 03:56:18 | petertodd: | andytoshi: that's UofT fwiw |
| 03:56:53 | andytoshi: | petertodd: wow, good to know then |
| 03:56:59 | nessence: | * nessence wonders how many UT folks are @ cointerra |
| 03:57:11 | andytoshi: | 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:40 | petertodd: | 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:51 | jcrubino: | petertodd: your my hero now with your calc story |
| 03:59:21 | petertodd: | jcrubino: lol |
| 03:59:33 | andytoshi: | 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:49 | petertodd: | andytoshi: ha! nah, uoft just fails people instead :P |
| 04:00:03 | petertodd: | andytoshi: first year calc we quite literally had about 90% of the class drop out |
| 04:00:32 | andytoshi: | yeah, that's an extreme workload especially if the teachers are all crap |
| 04:00:44 | andytoshi: | it'd be almost reasonable with excellent professors and TAs |
| 04:01:35 | petertodd: | 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:27 | andytoshi: | 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:46 | andytoshi: | (UTexas is in the former, they accepted 30/400 applicants last semester o.O) |
| 04:03:30 | petertodd: | ha, uoft has 50k students |
| 04:03:47 | petertodd: | heck, they have more teachers then my previous school had students |
| 04:03:51 | andytoshi: | yes, it is very irritating when they make half the grad department TA calculus <.< |
| 04:03:59 | mr_burde_: | mr_burde_ is now known as mr_burdell |
| 04:04:29 | mr_burdell: | mr_burdell is now known as Guest84632 |
| 04:04:29 | petertodd: | 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:43 | andytoshi: | 16k math students, 8k in the calculus sequences in any given semester, which means around 80 calc TAs i guess |
| 04:05:07 | andytoshi: | ( UTexas has similar total numbers to UofT i think) |
| 04:05:15 | petertodd: | probably about right |
| 04:05:44 | andytoshi: | petertodd: ugh, that's terrible |
| 04:07:43 | petertodd: | andytoshi: heh, well I still managed to learn enough from it to have some hope of learning more math :) |
| 04:08:46 | Guest84632: | Guest84632 is now known as mr_burdell |
| 04:09:26 | andytoshi: | very true, i was suprised to hear you (and gmaxwell) have so little formal math education |
| 04:09:53 | andytoshi: | 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:05 | petertodd: | gmaxwell is way ahead of me with math you know |
| 04:10:21 | andytoshi: | 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:15 | gmaxwell: | I don't know anything, but seeing as how I don't know anything I am also not afraid of anything. |
| 04:11:15 | petertodd: | 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:36 | petertodd: | andytoshi: lol, quantum anything just sounds scary, and relatively useless :P |
| 04:12:55 | andytoshi: | 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:21 | andytoshi: | 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:38 | andytoshi: | scott aaronson has somewhat changed my mind on that point tho, to the extend that he calls what he does "physics" |
| 04:14:03 | gmaxwell: | everything understandable to more than a few people is understandable to almost everyone if approached from the right perspective. |
| 04:15:03 | petertodd: | gmaxwell: +1 |
| 04:15:24 | andytoshi: | 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:44 | andytoshi: | they have to let me talk for two hours about cryptography, though, so maybe i'm filtering people.. |
| 04:15:46 | petertodd: | andytoshi: lol, I keep on thinking "what the fuck symbol am I supposed to use for foo?" |
| 04:15:59 | petertodd: | andytoshi: every time I try to write anything vaguely resembling a paper |
| 04:16:14 | petertodd: | andytoshi: were they smoking pot at the same time? |
| 04:16:15 | andytoshi: | petertodd: haha, that's the worst part |
| 04:16:32 | andytoshi: | petertodd: in one case, yes, he was the guitarist of a band at the bar near the math dept |
| 04:16:51 | andytoshi: | 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:03 | andytoshi: | so i think he might've secretly known it all |
| 04:17:42 | petertodd: | andytoshi: it's so much easier in analog electronics... oh wait, I took MIT's second year course on that... :P |
| 04:18:04 | petertodd: | andytoshi: damn! |
| 04:19:30 | petertodd: | 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:15 | andytoshi: | interesting - in math departments, almost all the really good students are musicians, and some are even art school dropouts! |
| 04:20:31 | petertodd: | andytoshi: oh! I never met anyone with an art background at uoft |
| 04:21:06 | petertodd: | andytoshi: well, there was one cute girl who had been reluctantly pushed into biology by her parents in a physics class :P |
| 04:21:25 | andytoshi: | petertodd: nice :P |
| 04:21:52 | petertodd: | andytoshi: every day she dressed like she was going to some kind of anime con |
| 04:22:19 | gmaxwell: | to be fair, music may be far too practical for some mathematicians I've met… |
| 04:22:43 | petertodd: | 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:09 | andytoshi: | petertodd: ugh, we had those at SFU too, it was so competitive and so sad |
| 04:23:42 | andytoshi: | 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:45 | petertodd: | andytoshi: did you ever take any summer classes? this was in the summer... |
| 04:24:51 | andytoshi: | 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:12 | petertodd: | 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:38 | petertodd: | andytoshi: exactly |
| 04:26:52 | andytoshi: | petertodd: yeah, in general i found the students at university should not have been there |
| 04:27:30 | andytoshi: | 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:56 | petertodd: | ah that sucks |
| 04:28:09 | andytoshi: | 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:11 | petertodd: | yeah, I've never had any experience with the non-art university environment |
| 04:28:15 | andytoshi: | e.g. #bitcoin-wizards |
| 04:28:49 | petertodd: | 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:25 | petertodd: | 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:32 | comma8: | comma8 has left #bitcoin-wizards |
| 04:30:17 | andytoshi: | 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:33 | andytoshi: | why the failure rate tho? do people give up or is it really difficult? |
| 04:30:33 | justanotheruser: | petertodd: are you an art major? |
| 04:30:34 | petertodd: | yup, and people skills goes a long, long way in our economy |
| 04:30:37 | petertodd: | justanotheruser: yup |
| 04:31:07 | justanotheruser: | petertodd: what do you do that is artistic |
| 04:31:39 | petertodd: | 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:45 | petertodd: | 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:49 | gmaxwell: | in 1970 college enrollment was ~50% of highschool grads in the US, it's ~70% now. |
| 04:33:36 | andytoshi: | petertodd: that does sound scary, though i can see why the same sorts of people end up in math departments |
| 04:33:37 | midnightmagic: | i woukd be curious to know whether those include the new vocational colleges that have started calling themselves colleges.. |
| 04:33:55 | petertodd: | gmaxwell: sounds like a bubble |
| 04:34:05 | gmaxwell: | midnightmagic: no. |
| 04:34:45 | petertodd: | andytoshi: well, to what extent are those departments like that as research becomes more of a focus? |
| 04:35:20 | andytoshi: | petertodd: it's directly correlated to research, the people doing plug-and-chug degrees weren't artsy at all |
| 04:35:23 | petertodd: | andytoshi: I mean, research can easily have that same kind of treadmill to it |
| 04:35:36 | andytoshi: | yeah, that's absolutely the way it seems to me |
| 04:35:37 | gmaxwell: | 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:37 | petertodd: | andytoshi: ah, yeah, plug-and-chug has it's own kind of pain I think |
| 04:35:59 | petertodd: | gmaxwell: good point, and they're pretty good at recovering the money, eventually... |
| 04:36:57 | andytoshi: | 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:09 | gmaxwell: | 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:18 | midnightmagic: | yay flynn effect |
| 04:38:24 | petertodd: | 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:32 | gmaxwell: | I'm sure there are plenty of papers on largely debt based economies and the relative rates of bubbles in them. |
| 04:39:12 | midnightmagic: | petertodd: mm.. not so sure about that. engineers mating withe ngi eers appears to select for autism. additionally, genetic issues with ashkenazi |
| 04:39:38 | petertodd: | 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:16 | andytoshi: | 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:17 | petertodd: | midnightmagic: yeah, sounds like very strong evidence for selective mating to me... |
| 04:40:34 | petertodd: | midnightmagic: note that autism is a spectrum... |
| 04:41:11 | andytoshi: | s/almost as fast/faster, but amongst fewer people/ |
| 04:41:11 | midnightmagic: | andytoshi: If the research I read is correct, they're destroying their own genetic viability longterm. |
| 04:41:29 | andytoshi: | midnightmagic: let's hope not, they're doing all the crypto research :P |
| 04:41:57 | petertodd: | 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:10 | andytoshi: | 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:05 | midnightmagic: | 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:39 | petertodd: | 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:36 | gmaxwell: | 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:45 | midnightmagic: | (absent actual genetic problems anyway) |
| 04:45:01 | gmaxwell: | unless they plan on doing a controlled study, which has ethical problems. |
| 04:45:36 | gmaxwell: | (its not like we have enough twins data, especially enviromentally distinct twins data, to really say a ton about nature vs nuture) |
| 04:46:08 | petertodd: | midnightmagic: I'm pretty skeptical of anyone who tries to claim modern societies are all that bad at providing everyone with opportunities |
| 04:46:18 | midnightmagic: | 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:03 | midnightmagic: | petertodd: I have a sociology department or two who would disagree witht hat :-) |
| 04:47:26 | petertodd: | midnightmagic: define "educated better" |
| 04:47:31 | andytoshi: | midnightmagic: right, and they're sitting comfortably in sociology departments instead of on the street, despite having no skills ;) |
| 04:47:44 | petertodd: | midnightmagic: and remember, I spent enough time at arts school to know sociology is often full of shit :P |
| 04:48:04 | midnightmagic: | petertodd: they measured that which was measurable: mathematics improvements between entry and exit grades for schools |
| 04:48:35 | midnightmagic: | .. lol now now. the research they do is better than forming opinions in a vacuum |
| 04:48:36 | petertodd: | midnightmagic: ah, so they measured improvements, who had the higher scores exiting? |
| 04:49:11 | gmaxwell: | 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:20 | midnightmagic: | petertodd: public schools had grrater improvements when co paring identical students with identical backgrounda. |
| 04:49:40 | petertodd: | 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:07 | midnightmagic: | petertodd: nope. they selected those ones out |
| 04:50:17 | justanotheruser: | midnightmagic: are you saying that schools should be segregated by income? |
| 04:50:35 | gmaxwell: | justanotheruser: they are already segregated by income. |
| 04:50:46 | midnightmagic: | 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:54 | justanotheruser: | gmaxwell: they bus students from poor schools to rich schools in some states |
| 04:51:09 | midnightmagic: | justanotheruser: nope. i'm saying private schools are lying when they claim to provide superior education |
| 04:52:13 | petertodd: | 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:03 | gmaxwell: | 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:33 | midnightmagic: | yes. adoptions help a lot with those kinds of studies too. |
| 04:53:59 | midnightmagic: | pretty fascinating how much people seem to be screwed if born to poor parents. |
| 04:54:06 | petertodd: | gmaxwell: yup, my point being blaming "society" for that kind of thing is misguided - we already do a tremendous amount |
| 04:54:21 | gmaxwell: | ::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:21 | petertodd: | midnightmagic: gee, might have something fundemental going on... |
| 04:55:31 | midnightmagic: | 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:40 | petertodd: | 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:11 | midnightmagic: | imo that kind of nonsense is b-s |
| 04:56:25 | midnightmagic: | closing gifted student programs?! wtf |
| 04:57:19 | gmaxwell: | well you are in canada. So perhaps things are better done there. :) |
| 04:57:46 | midnightmagic: | i'll let you know. i personally appear to be one of those weird outliers. |
| 04:58:23 | gmaxwell: | 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:35 | petertodd: | 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:58:55 | midnightmagic: | lol |
| 04:59:15 | petertodd: | midnightmagic: basically anything to avoid looking elitist |
| 04:59:25 | midnightmagic: | s art kids need a challenge or their study habits are nonexistent. yeah that makes sense what you're saying. |
| 04:59:25 | gmaxwell: | Se also: http://en.wikipedia.org/wiki/No_Child_Left_Behind_Act#Effects_on_school_and_students |
| 04:59:50 | gmaxwell: | er see* |
| 05:00:03 | petertodd: | midnightmagic: heh, well with a challenge that was true too, but anyway :P |
| 05:00:11 | andytoshi: | 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:15 | midnightmagic: | hehe |
| 05:00:20 | gmaxwell: | I know a number of _good_ high-school teachers who left teaching due to the effects of that legislation. |
| 05:00:41 | petertodd: | gmaxwell: can't blame them, that stuff is just depressing to deal with |
| 05:00:44 | midnightmagic: | andytoshi: you think so? i had the exact opposite experience in BC |
| 05:01:26 | andytoshi: | midnightmagic: i was in cloverdale, it is the cowboy town beside langley, they had no gifted programs |
| 05:01:46 | midnightmagic: | vancouver. interesting. |
| 05:02:22 | andytoshi: | 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:24 | midnightmagic: | i was in the interior, they specifically pushes the smart kids into beneficial grade programs for university entrance. |
| 05:02:40 | andytoshi: | midnightmagic: eventually i found some good teachers who helped me game the system, and i got out 18 months early |
| 05:02:54 | petertodd: | 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:14 | andytoshi: | 2 years early* i stuck around to finish my phys. ed. requirements :P |
| 05:03:35 | andytoshi: | so i don't count that semester as hs |
| 05:03:43 | petertodd: | 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:53 | andytoshi: | petertodd: fascinating |
| 05:04:03 | andytoshi: | there is a lesson here about anecdotal evidence i'm sure :) |
| 05:04:14 | midnightmagic: | 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:17 | andytoshi: | maybe we should apologise to midnightmagic for calling his sociologists stupid |
| 05:04:23 | petertodd: | andytoshi: hehe, toronto is not a good source of typical demographic data :) |
| 05:04:30 | midnightmagic: | lol a.k.a. my wife. |
| 05:04:45 | midnightmagic: | no apology necessary, it's a well studied ohenomena. |
| 05:04:53 | midnightmagic: | er.. *non |
| 05:05:42 | petertodd: | andytoshi: over 50% of the toronto population wasn't even born in canada |
| 05:06:06 | midnightmagic: | well, without immigration our pop would be shrinking. :-) |
| 05:06:14 | midnightmagic: | would suck if canada died. |
| 05:06:22 | andytoshi: | petertodd: this is true of vancouver as well, though probably not in cloverdale where i was |
| 05:06:36 | gmaxwell: | 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:43 | gmaxwell: | ... back against it with a bunch of FUD because it was draining them of their most academically capable students. |
| 05:06:55 | andytoshi: | oh, cloverdale is right above white rock, from silk road hitman fame :) |
| 05:07:03 | andytoshi: | so i'll stop saying 'near vancouver' here |
| 05:07:20 | petertodd: | andytoshi: what's the kind of immigrants that vancouver gets anyway? asia? middle-east? |
| 05:07:27 | midnightmagic: | andytoshi: i'm confident nobody thinks you're that guy lol |
| 05:07:32 | midnightmagic: | ha ha ha awesome |
| 05:07:52 | midnightmagic: | petertodd: asian, then east indian |
| 05:07:54 | gmaxwell: | I was impressed by the density of asian people in vancouver. |
| 05:07:54 | andytoshi: | petertodd: east asia, mostly china and phillipines, then india |
| 05:08:05 | petertodd: | gmaxwell: sheesh, that kinda sucks that you were in a position where that made sense |
| 05:08:12 | midnightmagic: | richmond doesn't even have english signage in some places. |
| 05:08:57 | petertodd: | andytoshi: oh, interesting, toronto seems to get much more from the middle east |
| 05:09:04 | midnightmagic: | gmaxwell: how old were you re: GED? |
| 05:09:11 | midnightmagic: | (wife is curious) |
| 05:09:14 | gmaxwell: | 16. |
| 05:09:18 | petertodd: | andytoshi: OCAD had a *tonne* of Iranians for instance |
| 05:09:18 | midnightmagic: | nice. |
| 05:09:23 | andytoshi: | gmaxwell: that's awesome, i wish i had that option |
| 05:09:32 | andytoshi: | maybe i did, it didn't occur to me |
| 05:10:06 | midnightmagic: | i skipped a grade, grad'd at 17. skipping a grade was really horrible. not recommended. |
| 05:10:32 | midnightmagic: | petertodd: what's OCAD? |
| 05:10:34 | andytoshi: | petertodd: interesting, i've only met one iranian |
| 05:10:41 | petertodd: | 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:47 | midnightmagic: | I love Iranians they're awesome |
| 05:10:54 | petertodd: | midnightmagic: http://www.ocadu.ca/ <- art school I went too |
| 05:10:58 | andytoshi: | 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:00 | midnightmagic: | oh cool |
| 05:11:18 | petertodd: | andytoshi: huh, must be a regional thing that they settle in Toronto |
| 05:11:19 | midnightmagic: | yikes. |
| 05:11:31 | andytoshi: | midnightmagic: agreed re iranians, the one guy i know is so much fun |
| 05:11:55 | gmaxwell: | 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:03 | petertodd: | andytoshi: also people from Iraq, Palestine, Afghanistan etc. |
| 05:12:35 | midnightmagic: | 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:22 | andytoshi: | petertodd: cool, also know only one iraqi, two afghanis, no palestinians.. vancouver is all east asia and india |
| 05:13:42 | petertodd: | 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:46 | midnightmagic: | yunan province chinese are awesome |
| 05:13:57 | midnightmagic: | lol |
| 05:13:58 | petertodd: | midnightmagic: most of the ones I knew had grown up here - it was their parents who fled |
| 05:14:13 | midnightmagic: | * midnightmagic tries to think of a people that irritate him and fails. |
| 05:14:22 | petertodd: | midnightmagic: aussies? |
| 05:15:02 | andytoshi: | haha |
| 05:15:05 | midnightmagic: | petertodd: Hrm, yeah maybe. There's some weird misogyny stuff going on there. But NZ make up for it |
| 05:15:14 | petertodd: | ha |
| 05:15:25 | petertodd: | good, cause my mom's an aussie, and my brother lives there :P |
| 05:15:34 | midnightmagic: | :-) |
| 05:16:17 | midnightmagic: | my cousin is marrying an aussie, he's like the ultimate man's man, great guy |
| 05:16:51 | petertodd: | lol |
| 05:16:54 | midnightmagic: | (in the awesome way, not the chauviniat way) |
| 05:16:55 | petertodd: | sounds about right |
| 05:17:13 | midnightmagic: | :-) |
| 05:18:41 | petertodd: | 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:47 | petertodd: | ... school to say the least. |
| 05:19:31 | petertodd: | Really good example of how utterly polarizing that issue can be with people unfortunately. :( |
| 05:30:17 | gmaxwell: | 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:50 | petertodd: | 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:24 | gmaxwell: | Final Solution. Get the case right. |
| 05:35:40 | petertodd: | 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:46 | petertodd: | gmaxwell: I'll assume they were quoting Ariel Sharon, who gets quotes as saying that in lowercase. :/ |
| 05:37:17 | gmaxwell: | 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:50 | gmaxwell: | 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:01 | petertodd: | 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:35 | gmaxwell: | 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:08 | petertodd: | 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:52 | petertodd: | While I've yet to hear any Russians bothered by it. |
| 05:43:03 | petertodd: | 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:24 | petertodd: | 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:33 | andytoshi: | 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:53 | petertodd: | andytoshi: interesting! due to border guards? |
| 05:44:57 | andytoshi: | petertodd: yes |
| 05:45:04 | andytoshi: | 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:27 | andytoshi: | 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:50 | petertodd: | 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:41 | petertodd: | andytoshi: took the second occasion before they realized they'd jsut have to ship stuff by hand |
| 05:46:46 | andytoshi: | 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:07 | andytoshi: | 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:15 | petertodd: | andytoshi: it's canadians too sometimes... |
| 05:47:50 | andytoshi: | ..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:05 | andytoshi: | petertodd: canadian guards? driving in i have had them be assholes before, though they have never taken my car apart |
| 05:48:23 | andytoshi: | flying in, the "customs" process involved them asking if i went to school in the US |
| 05:48:28 | andytoshi: | i said yep, the guy said ok, sure |
| 05:48:29 | petertodd: | 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:43 | andytoshi: | jeez |
| 05:48:57 | petertodd: | andytoshi: oh, I mean they give the fingerprint treatment to canadians sometimes |
| 05:49:10 | andytoshi: | oh, i got that when i first got my F1 status |
| 05:49:23 | andytoshi: | very annoying, i'll have to replace those fingertips when i get out of school <.< |
| 05:49:27 | petertodd: | ha |
| 05:49:44 | petertodd: | take up quarts glass blowing, and be clumsy |
| 05:49:54 | andytoshi: | :P |
| 05:51:39 | petertodd: | 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:56 | andytoshi: | haha, excellent |
| 05:53:04 | andytoshi: | is amir a "known cyber-terrorist"? |
| 05:53:51 | andytoshi: | haha, i see, i've never read his wiki page before.. |
| 05:53:54 | petertodd: | I sure hope so! I've got an image to maintain |
| 05:54:34 | andytoshi: | https://en.wikipedia.org/wiki/Amir_Taaki#Activism would certainly classify him as a terrorist in america |
| 05:55:13 | petertodd: | agreed, and Esperanto?! evil |
| 05:55:18 | phantomcircuit: | only on tuesdays |
| 05:55:27 | andytoshi: | that wiki page also claims he is on forbes' top 30 entepreneurs of 2014 |
| 05:55:34 | andytoshi: | ..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:50 | petertodd: | andytoshi: um... yeah... I belive that guy when he says he's penniless |
| 05:56:07 | andytoshi: | oh, no, that's today's date up top, the article is a week old :P |
| 05:57:06 | phantomcircuit: | petertodd, im pretty sure he has at least like |
| 05:57:11 | phantomcircuit: | 100 euros |
| 05:57:19 | andytoshi: | yeah, the article credits him for darkwallet, but that seems pretty hard to monetize |
| 05:57:33 | petertodd: | phantomcircuit: and one pair of unwashed sweatpants |
| 05:57:41 | andytoshi: | i assume jon matonis was involved in that list .. |
| 05:57:47 | petertodd: | andytoshi: lol |
| 05:57:58 | phantomcircuit: | petertodd, im pretty sure he has only one pair of everything |
| 05:58:02 | phantomcircuit: | maybe he has two shirts |
| 05:58:32 | petertodd: | phantomcircuit: probably both scavenged |
| 05:59:00 | phantomcircuit: | eh probably not quite |
| 05:59:07 | phantomcircuit: | maybe his mom bought them |
| 05:59:15 | phantomcircuit: | (that's always a good way to get new clothes) |
| 05:59:42 | petertodd: | phantomcircuit: works best when you're parents live in northern canada... and they invite you home for chistmas |
| 05:59:45 | phantomcircuit: | which is why i get a nice laugh at people accusing him of doing things for bad reasons |
| 06:00:03 | phantomcircuit: | it's just not how he operates |
| 06:00:33 | petertodd: | yup, he's very genuine |
| 06:01:07 | petertodd: | and you know, quite willing to take criticism, and flexible |
| 06:19:05 | gmaxwell: | phantomcircuit: so... seen cointerra's screenshot. |
| 06:19:07 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 06:19:08 | gmaxwell: | I am boggled. |
| 06:19:13 | gmaxwell: | http://cointerra.com/wp-content/uploads/2014/01/DSC05521.jpg |
| 06:19:51 | petertodd: | that's fast |
| 06:20:19 | gmaxwell: | 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:20:53 | petertodd: | oh! |
| 06:22:11 | gmaxwell: | 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:32 | gmaxwell: | petertodd: it's fast, but it's supposted to be 2TH, so not that fast! |
| 06:22:41 | gmaxwell: | http://cointerra.com/engineering-updates-terraminer-iv-hashing-live/ |
| 06:23:48 | petertodd: | gmaxwell: what ASIC tech level is it? |
| 06:24:34 | petertodd: | ah 28nm |
| 07:03:35 | phantomcircuit: | gmaxwell, yeah i saw the video before they posted it |
| 07:03:40 | phantomcircuit: | (aren't i so cool) |
| 07:24:44 | amiller: | got thirty cryptocurrencies aint never been released |
| 07:30:45 | phantomcircuit: | gmaxwell, also it's possible they were using an invalid address, iirc eligius treats that as a donation |
| 07:30:47 | phantomcircuit: | Luke-Jr, ? |
| 07:31:09 | Luke-Jr: | I'm not seeing anything so far. |
| 07:31:18 | Luke-Jr: | but this query will probably take a while |
| 07:31:22 | gmaxwell: | Luke-Jr: well its probably not running now or it would be in the top list. |
| 07:31:38 | phantomcircuit: | iirc he has a share log |
| 07:31:48 | Luke-Jr: | looks like the share log goes back a week |
| 07:33:14 | gmaxwell: | ... weird. well there is a date in the screenshot, also a last block |
| 07:34:10 | gmaxwell: | Luke-Jr: http://cointerra.com/engineering-updates-terraminer-iv-hashing-live/ pic at the bottom |
| 07:49:44 | gmaxwell: | phantomcircuit: it looks like with a slightly different case design they could have fit that in 2u without a problem. |
| 07:51:10 | gmaxwell: | e.g. potentially making it longer and turning the radiators flat. and having airflow that went >_____/ |
| 07:57:04 | midnightmagic: | bah |
| 07:59:55 | gmaxwell: | 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:03 | gmaxwell: | https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688 < looks like the othercoin thing is being sold now. |
| 08:32:43 | gmaxwell: | 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:17 | gmaxwell: | It's basically the digital version of the cassius coins... but allows the user to safely fill it, and electronic transmission. |
| 08:33:27 | BlueMatt: | nice |
| 08:56:58 | stonecoldpat: | looks nice, my concern is that initially if BTC is $1k - then it will cost $350 |
| 09:01:30 | gmaxwell: | stonecoldpat: yea, it's not viable at that price but presumably that will be fixed once it actually exists at scale. |
| 09:03:58 | stonecoldpat: | 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:14 | nsh: | there are numbers higher than 100?!? |
| 09:09:27 | _ingsoc: | Yeah. :) |
| 09:09:40 | nsh: | 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:10 | nsh: | * nsh nods |
| 09:10:17 | nsh: | 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:16 | nsh: | i'd suspect it's still accessible through git itself |
| 09:15:36 | nsh: | actually, dunno |
| 09:16:00 | TD[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:11 | wumpus: | you could access them one by one through the github API, and make a mirror |
| 09:19:32 | wumpus: | not with git itself as the issues are not part of the repository, only the code changes |
| 09:19:43 | wumpus: | (and commit descriptions in git itself) |
| 09:19:50 | nsh: | ah, right |
| 09:20:11 | wumpus: | so if github goes down we'd lose the discussions that happened on github |
| 09:20:45 | _ingsoc: | That's concerning. |
| 09:20:56 | wumpus: | (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:16 | wumpus: | see http://developer.github.com/v3/ |
| 09:23:16 | _ingsoc: | Is there a simple way to get a dump? |
| 09:23:58 | wumpus: | I'm sure someone else already wrote a script for that |
| 12:00:27 | genjix: | genjix has left #bitcoin-wizards |
| 12:14:31 | adam3us: | 12hr async conversation, caught up, a couple of comments |
| 12:17:22 | adam3us: | 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:20 | adam3us: | 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:32 | adam3us: | 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:38 | adam3us: | 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:35 | jtimon: | adam3us: gmaxwell's thread is full of terrible covenants |
| 13:24:11 | adam3us: | jtimon: on bitcoin talk? a cautionary tale of why the virality of covenants can be a risky proposition? |
| 13:24:27 | jtimon: | but is any covenant economically worse than destroying coins (which we allow)? |
| 13:24:57 | jtimon: | I think is "coincovenants: a f** terrible idea" or something similar |
| 13:25:29 | jtimon: | https://bitcointalk.org/index.php?topic=278122.0 |
| 13:28:27 | jtimon: | actually, I propose the AML-KYC covenant there |
| 13:29:01 | jtimon: | and I think it can replace our optional "authorizer tokens" in freimarkets |
| 13:29:23 | jtimon: | not sure about the "issuance tokens" yet, I don't think so |
| 13:32:09 | adam3us: | 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:05 | jtimon: | 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:06 | adam3us: | 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:45 | jtimon: | 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:57 | jtimon: | 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:29 | jtimon: | destroying is not strictily "viral" but it's also irreversible |
| 13:35:54 | jtimon: | the effect on the quantity of "pure btc" is the same |
| 14:22:30 | adam3us: | 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:40 | adam3us: | 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:29 | adam3us: | 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:12 | jtimon: | well, let's use my visacoin example (KYC covenant) |
| 14:29:51 | jtimon: | if I give btc to an exchange and they give me viscoins back, I calll that fraud and never come back |
| 14:30:55 | jtimon: | the main problem would probably be education and smart clients that show a different separated balance for visacoins |
| 14:32:00 | jtimon: | if we solve that, it doesn't matter if 80% of the btc were turned into visacoins: bitcoins are still p2p |
| 14:32:35 | jtimon: | in the case of freicoin is again less to worry about |
| 14:33:03 | jtimon: | both visacoins and freicoins will be destroyed by demurrage, but miners get fresh clean freicoins |
| 14:33:39 | adam3us: | 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:27 | jtimon: | maybe I'm too optimistic or I expect people to be too smart |
| 14:35:28 | adam3us: | 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:43 | jtimon: | or maybe you're too pesimistic and expect people to be too stupid |
| 14:35:52 | adam3us: | jtimon: seemingly if bitcoin taught us anything its that people are too stupid :) |
| 14:35:57 | jtimon: | and don't distinguish between visacoins and bitcoins |
| 14:37:01 | jtimon: | adam3us: maaku had the same concern when we were discussing freimarkets authorizers |
| 14:37:53 | jtimon: | my believe is that people will tend to prefer non-authorized assets when they can |
| 14:38:01 | adam3us: | 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:32 | adam3us: | jtimon: i agree, but the virality and incremental leaking effect means you have no remaining effective say in the matter. |
| 14:38:33 | pigeons: | 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:44 | jtimon: | 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:15 | jtimon: | if btc are destroyed logarithmically, there will always be some of them left |
| 14:41:02 | adam3us: | 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:51 | jtimon: | please, don't say value, say price |
| 14:42:08 | jtimon: | you're making a lot of assumptions |
| 14:42:31 | jtimon: | why would the value of btc be correlated to the value of visacoin? |
| 14:42:53 | adam3us: | 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:55 | jtimon: | if there's 1% btc and 99% visa, btc are much more scarce |
| 14:43:11 | pigeons: | its similar to coinvalidate. you would think no one would want to use a whitelist, but once "everyone else" does |
| 14:43:57 | pigeons: | there become less options to use bitcoin and the only options are to use covenantcoin/visacoin/etc |
| 14:43:59 | jtimon: | what would I use whitelisted bitcoins? that's not a p2p currency |
| 14:44:08 | adam3us: | 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:01 | jtimon: | technical freedom is what bitcoin is about |
| 14:45:05 | adam3us: | jtimon: scarce as in about to become dodo i thin, due to incremental virality |
| 14:45:37 | jtimon: | if people think that bitcoin will go higher in price after they turn into visacoins they are blind |
| 14:46:09 | adam3us: | jtimon: i think it is more that the economic majority neither thinks, nor cares, they just want to buy a burger, etc. |
| 14:46:41 | adam3us: | 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:56 | pigeons: | well price isnt the concern, its usability and perhaps fungibility, if network effects help increase visacoin usage as the way to go |
| 14:47:02 | jtimon: | please, stop using the "people are dumb" fallacy |
| 14:47:52 | jtimon: | because the burguer costs 1 visacoin (1000 usd aprox) and 1 bitcoin costs 100,000 usd, for example |
| 14:48:18 | adam3us: | 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:33 | pigeons: | 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:43 | pigeons: | not reall dumb, just acting naturally for conditions |
| 14:49:38 | jtimon: | people are dumb, but if you need that fact to make a point there's something wrong with your reasoning |
| 14:49:38 | pigeons: | 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:54 | adam3us: | 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:56 | jtimon: | I'm just saying that's a fallacy, not that it is false |
| 14:50:24 | pigeons: | when bitcoin is more "entrenched" these outcomes are less of a concern |
| 14:50:39 | jtimon: | why would shops ask you for 1 btc for the burguer if they can sell 0.01 btc for 1 visacoin? |
| 14:51:53 | adam3us: | 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:07 | jtimon: | I could even be fine with assuming most cosnumers and some merchants are dumb |
| 14:52:40 | jtimon: | but certainly not assuming that most shops and producers will be dumb: because they go bankrupt when they're dumb |
| 14:53:02 | jtimon: | ok |
| 14:53:12 | jtimon: | what could happen... |
| 14:53:24 | pigeons: | policy risk points are not about business saavy, they are about external force imposed by regulators |
| 14:53:33 | adam3us: | jtimon: ok agree, no more dugging-krugeresque smugness. lets focus on the virality issue |
| 14:54:17 | jtimon: | no matter the law, if your business sucks you go bankrupt |
| 14:54:36 | jtimon: | no matter how happy the nsa is with say, coinbase |
| 14:54:53 | adam3us: | 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:03 | jtimon: | f they keep on doing stupid things like using databases without consistency they will go bankrupt |
| 14:55:44 | pigeons: | there is much moral hazard about that i'm not so sure that's true |
| 14:55:46 | jtimon: | but CAs are centralized |
| 14:55:52 | jtimon: | no? |
| 14:56:26 | adam3us: | jtimon: not fully, there are 100s of them in dozens of countries, operated by a variety of types of organizations. |
| 14:56:57 | pigeons: | 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:04 | adam3us: | 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:21 | jtimon: | I don't know, apparently I wasn't being able to make my point that, bitcoins != amlcoins |
| 14:59:05 | jtimon: | back to your "bitpay ports to amlcoin" example |
| 14:59:09 | adam3us: | 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:41 | jtimon: | there will still be people that have eyes to see they're are different currencies |
| 14:59:52 | adam3us: | 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:00 | jtimon: | so the prices will (at first slightly) differ |
| 15:00:46 | jtimon: | people paying with bitcoins don't want to have their btc valued as if they were amlcoins |
| 15:01:02 | jtimon: | and suddenly the impossible happens: bitpay2 appears |
| 15:01:16 | jtimon: | wait wait |
| 15:01:22 | pigeons: | and there are now more things you can buy with amlcoins than with bitcoins |
| 15:01:50 | adam3us: | 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:55 | jtimon: | you're now saying that all exchanges in the world will abandon bitcoin in favor of nsacoin at the same hour? |
| 15:02:02 | pigeons: | 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:18 | adam3us: | 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:31 | jtimon: | ok, we found were we disagree |
| 15:04:28 | jtimon: | 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:53 | pigeons: | not too dumb, just less concerned about the ideals of the issue and more concerned with getting a transaction done |
| 15:05:15 | jtimon: | so I could as well make a falsefreicoin covenant with a demurrage that goes to me instead of miners |
| 15:05:44 | jtimon: | sell them into existence for bitcoin at 1:1 ala mastercoin |
| 15:06:04 | jtimon: | but if bitpay moves from bitcoin to falsefreicoin nobody will notice the difference |
| 15:06:07 | adam3us: | jtimon: it might work :) look at all the scamcoins |
| 15:06:35 | jtimon: | scams work for a while |
| 15:06:37 | pigeons: | 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:54 | jtimon: | let's see how the scamcoin thing looks in a year |
| 15:07:17 | adam3us: | jtimon: so you agree that bitcoin with no access to exchange services is almost certain to have a lower price? |
| 15:07:55 | adam3us: | jtimon: indeed i hope the scam coins all die :) |
| 15:08:12 | jtimon: | 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:25 | pigeons: | no access to large public, in the open, exchange services? because exchange services can take many forms |
| 15:08:27 | jtimon: | why would btcchina care about nsacoin? |
| 15:08:41 | pigeons: | why does it have to be at once? |
| 15:08:58 | adam3us: | 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:15 | pigeons: | it inches toward more useful to merchants and users as bitcoin inches aways from it |
| 15:09:42 | adam3us: | jtimon, pigeons: well access to btc-china for non-chinese resident is not given. watch the 10% spread bitstamp to mtgox. |
| 15:09:51 | jtimon: | 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:56 | stonecoldpat: | adam3us: do you mean that a freshly minted coin from miners, has a premium over previously used coins? |
| 15:10:15 | adam3us: | stonecoldpat: apparently yes. there was someone selling virgin coins for a premium |
| 15:10:22 | stonecoldpat: | haha fantastic |
| 15:10:40 | pigeons: | 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:43 | adam3us: | 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:46 | jtimon: | stonecoldpat: I think only if they can buy them anonymously since this way "nobody" knows the source |
| 15:13:51 | stonecoldpat: | 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:02 | adam3us: | 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:45 | stonecoldpat: | although removing a coins link* to prev transactions is defo interesting |
| 15:15:25 | adam3us: | stonecoldpat: i suppose another indication is apparently people pay fees to mix coins to reduce the link |
| 15:15:58 | pigeons: | 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:47 | stonecoldpat: | 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:08 | jtimon: | stonecoldpat: coinjoin solves it by anonymous p2p mixing |
| 15:17:25 | jtimon: | coinswap is even more effective |
| 15:17:39 | adam3us: | 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:15 | adam3us: | stonecoldpat: yes coinjoin does that (trustless mix, the mix cant take your coins) |
| 15:19:42 | pigeons: | not that innovation should be abandoned because it can be abused, but the potential consequences should be taken very seriously |
| 15:19:51 | adam3us: | 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:42 | adam3us: | pigeons: which is to say probably covenant risks were considered by satoshi during his selection of the script-language. i expect. |
| 15:21:26 | adam3us: | road to hell is paved with good intentions, pragmatic programmers, fun science experiments etc. |
| 15:21:32 | pigeons: | hey, we can learn whatever lessons we can from freimarkets authorizers and such hopefully |
| 15:21:48 | jtimon: | adam3us: maybe satoshi didn't thought that much about the language choice |
| 15:22:19 | jtimon: | of course p2p currencies rely on free software, despite Nestcoin users ignoring that |
| 15:22:38 | adam3us: | pigeons, jtimon: well just to say consider virality risk as a security defect, and make sure new script feature dont introduce it. |
| 15:22:52 | jtimon: | what is the commited transactions risk? |
| 15:23:17 | adam3us: | jtimon: commited-tx is a mechanism to reduce the policy control from centralization in miners. |
| 15:23:55 | adam3us: | 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:09 | jtimon: | 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:35 | jtimon: | oh, I remember |
| 15:25:38 | adam3us: | 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:42 | jtimon: | I though it was another risk |
| 15:26:20 | jtimon: | again, unlike you I'm not very concerened about the censor miners "problem" |
| 15:26:59 | jtimon: | but that's not a problem with voip, only with skype |
| 15:27:38 | jtimon: | it's like saying "linux is flawed because many people prefer windows or macos" |
| 15:27:54 | adam3us: | 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:25 | pigeons: | 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:49 | adam3us: | jtimon: its not a bitcoin flaw, but it could become a problem perhaps. clients are individually less powerful. |
| 15:28:50 | jtimon: | 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:28 | adam3us: | 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:00 | jtimon: | nothing wrong being paranoid, I agree |
| 15:30:27 | jtimon: | just happens that the points where I get paranoid and where you get paranoid are not the same |
| 15:30:29 | pigeons: | 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:05 | adam3us: | 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:03 | jtimon: | I agree that having an in-chain anonymous transfer mechanism could be would for several reasons |
| 15:32:27 | jtimon: | I think it could operate alongside a "public" one |
| 15:33:06 | jtimon: | but I tend to like more petertodd's inputs-only transactions (although it's less developed) |
| 15:33:33 | adam3us: | 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:19 | jtimon: | maybe because I tend to get lost in your crypto spell scrolls...I mean...formulas |
| 15:34:36 | jtimon: | yeah, we discussed it other day at lenght |
| 15:35:00 | jtimon: | my argument was that censor miners would rapidly go out of business |
| 15:35:02 | adam3us: | 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:30 | adam3us: | jtimon: i agree. its like the amlcoin argument u made in some ways. |
| 15:35:36 | jtimon: | of course, I was assuming the distribution has ended, that risk is higher now I guess |
| 15:36:27 | adam3us: | 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:46 | jtimon: | and I guess is also good that freicoin only has 3 years of issuance ;) |
| 15:36:50 | pigeons: | well i know a few miners who see the control they exert as protecting the network from things like spam transactions |
| 15:36:57 | adam3us: | jtimon: so even their reward would be lost |
| 15:37:40 | pigeons: | and things like the address-reuse deprioritization wouldnt be possible i suppose |
| 15:37:42 | jtimon: | how and why would users ignore censor miners and how they find out what blocks are censored? |
| 15:38:05 | adam3us: | pigeons: the fact that we have pools at all people seem to think was an unfortunate unforseen technology limitation. |
| 15:39:03 | jtimon: | well, my argument is the same that with the ghash.io topic p2pool/eligious pools are not a problem |
| 15:39:05 | adam3us: | 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:51 | adam3us: | jtimon: its a technical insurance policy or threat. |
| 15:40:07 | jtimon: | I think inputs-only transactions would have a similar anonymity effect and they seem more scalable to me |
| 15:40:14 | pigeons: | its a shame it seems like its not technical limitations keeping p2pool adoption from increasing as much as places like ghash |
| 15:40:30 | jtimon: | and also more "compatible" with regular txs |
| 15:40:41 | adam3us: | 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:06 | pigeons: | and its not technical limitations why stratum is much more widepread than gbt |
| 15:41:22 | pigeons: | but yeah the limitations existed at the time pools emerged and grew |
| 15:41:53 | adam3us: | 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:41 | adam3us: | 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:48 | jtimon: | adam3us: this is ptertodd's very open design https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html |
| 15:44:10 | jtimon: | but let me summarize the way I see it integrated with regular transactions |
| 15:45:44 | jtimon: | 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:13 | jtimon: | the inputs may actually be garbage, refer to outputs that don't even exist |
| 15:46:54 | jtimon: | and all the history of the outputs is transmitted directly between users, it doesn't touch the chain |
| 15:46:58 | jtimon: | makes sense? |
| 15:47:51 | jtimon: | well, I haven't really though much about interoperate with regular transactions (going from private back to public) |
| 15:48:13 | jtimon: | the main problem here seems to be: how fees are paid? |
| 15:48:30 | jtimon: | and the only answer seems to be pow fees |
| 15:48:39 | jtimon: | petertodd doesn't go beyond that |
| 15:48:53 | jtimon: | I think you could have a regular blockchain |
| 15:49:03 | jtimon: | and optional pow fees |
| 15:49:27 | jtimon: | which miners can somehow "add" to their per-block PoW |
| 15:50:32 | jtimon: | 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:45 | adam3us: | 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:13 | jtimon: | yeah, seems very similar |
| 15:53:14 | adam3us: | 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:55 | adam3us: | 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:27 | jtimon: | if he had done that I would have explained the txin proposal to you much faster ;) |
| 15:56:05 | adam3us: | 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:57 | adam3us: | 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:57:26 | jtimon: | np |
| 15:58:05 | adam3us: | jtimon: i think gmaxwell said in the committed-tx thread it might nearly but not quite be implementable with script. |
| 15:58:33 | jtimon: | that post of him, reminded me a discussion Ryan and I had about a txid-only chain for one of our ripplecoins |
| 15:59:01 | jtimon: | we wanted to put the powin transactions |
| 15:59:56 | jtimon: | 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:39 | jtimon: | so people will commit their transaction on top of the longest chain they see |
| 16:01:10 | jtimon: | and then we needed a git-like merge |
| 16:01:21 | adam3us: | 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:32 | jtimon: | but we realize that didn't prevented doublespendings ;( |
| 16:02:09 | jtimon: | adam3us: ok, but it's good to know that it's not completely impossible |
| 16:03:00 | adam3us: | 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:08 | jtimon: | I think it started here? https://bitcointalk.org/?topic=4382.0 |
| 16:05:00 | jtimon: | disclaimer: we were mainly interested in ripple, so we just really wanted a minimal p2p timestamping mechanism |
| 16:05:30 | adam3us: | 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:37 | jtimon: | if this tx id gets into the chain before expiry, all the sub-txs in it are valid, otherwise none is valid |
| 16:06:08 | adam3us: | 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:51 | jtimon: | sorry don't know ghost |
| 16:07:29 | jtimon: | my latest idea as said was that miners added the user's tx-pow to their block pow |
| 16:07:40 | adam3us: | 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:34 | jtimon: | 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:06 | adam3us: | 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:00 | jtimon: | the users reward is getting their transaction into the block, why would they get anything else? |
| 16:10:03 | adam3us: | 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:57 | adam3us: | 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:24 | jtimon: | what's the purpose? |
| 16:11:39 | adam3us: | jtimon: dislike of mining pool cenrtalization risk :) |
| 16:11:58 | jtimon: | the purpose of mining is validation not distribution |
| 16:12:07 | adam3us: | jtimon: so i tried to explore how could i solo mine. one answer is to be able to mine for smaller amounts. |
| 16:12:52 | jtimon: | but if you're mining old stuff, why should the network reward you? |
| 16:12:58 | adam3us: | 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:27 | jtimon: | I tend to distrust PoS |
| 16:13:37 | adam3us: | 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:24 | jtimon: | in freicoin the retargetting is 9 blocks and if bitcoin ever hardforks I would suggest to update to our filter too |
| 16:14:25 | adam3us: | 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:06 | jtimon: | "mining only your public key" how do you mine "on a public key"? |
| 16:15:10 | adam3us: | jtimon: my idea is not at a working stage, this was just as close as i got . |
| 16:15:26 | jtimon: | oh, I see |
| 16:16:09 | justanotheruser: | Do you think PoS could ever work in a currency? |
| 16:16:09 | adam3us: | 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:01 | adam3us: | 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:33 | jtimon: | ok, now I get the point |
| 16:17:51 | jtimon: | but I disagree on "the idea is mining is like to get the right to vote on what the next block is" |
| 16:17:56 | adam3us: | jtimon: if thsoe problems could be convincingly fixed, it might be quite interesting |
| 16:18:08 | jtimon: | the idea of mining is sequencing events irreversively |
| 16:18:26 | adam3us: | jtimon: correct, and to vote on their validity (for SPV client reliance) |
| 16:19:00 | adam3us: | 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:26 | wallet42: | stealth addresses are base58_check encoded compressed pubkeys? |
| 16:19:29 | jtimon: | toss? |
| 16:19:34 | adam3us: | jtimon: (except for some issues with 0-confirm security model where network propagation such as it is provide some modest security) |
| 16:19:37 | wallet42: | whats the versionbyte? |
| 16:20:31 | jtimon: | 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:03 | adam3us: | 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:38 | jtimon: | 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:38 | jtimon: | adam3us, of course, the challenge is the infinitely scalable p2p timestamping system |
| 16:22:55 | adam3us: | 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:27 | adam3us: | 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:06 | adam3us: | 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:47 | jtimon: | 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:58 | adam3us: | 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:03 | jtimon: | 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:51 | adam3us: | 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:05 | stonecoldpat: | are miners pools not just a natural process that cant really be removed? It's a bit like industrialisation... |
| 16:29:11 | adam3us: | 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:25 | adam3us: | 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:08 | stonecoldpat: | is the vote to choose the correct branch? or how to distribute the coins? |
| 16:31:55 | stonecoldpat: | i remember having a thought about this before christmas (how to distribute coins) - i seen it as a pretty bad problem |
| 16:31:57 | adam3us: | stonecoldpat: correct branch and form part of a kind of distributed signature attesting all the transactions are valid |
| 16:33:13 | stonecoldpat: | 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:52 | stonecoldpat: | 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:55 | adam3us: | stonecoldpat: yes but the SPV (smartphone/limited bandwidth) clients accept whatevr is claimed by sampling a few nodes |
| 16:35:34 | adam3us: | 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:28 | adam3us: | stonecoldpat: yes if all candidate blocks are valid tossing a coin to choose a block at random would be just fine. |
| 16:44:15 | Luke-Jr: | I wonder if stealth addresses can be combined with P2SH^2 somehow |
| 16:46:20 | jtimon: | 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:19 | jtimon: | stoencoldpat: if you have ideas for coin distribution, maybe you're interested in this: http://foundation.freicoin.org/#/about |
| 16:48:14 | jtimon: | adam3us: about your "pools problem" what about this other approach: *somehow* prevent non-p2pool pools from mining |
| 16:48:45 | jtimon: | adam3us: solo miners could only mine on their own p2pool alone |
| 16:49:01 | jtimon: | /only/always |
| 16:49:38 | Luke-Jr: | jtimon: p2pool isn't special |
| 16:49:43 | adam3us: | 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:52 | Luke-Jr: | there is no reason to prefer it over other decentralised schemes |
| 16:50:40 | jtimon: | Luke-Jr I thought it was (and by p2pool I include eligious, just exclude "centralized pools") |
| 16:50:42 | adam3us: | 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:00 | jtimon: | maybe that term is more appropriate centralized vs p2p pools |
| 16:51:01 | Luke-Jr: | jtimon: p2pool is a specific pool, both decentralised and also p2p |
| 16:51:11 | Luke-Jr: | jtimon: BitPenny was the original decentralised pool ;) |
| 16:51:21 | jtimon: | I see |
| 16:51:33 | Luke-Jr: | unfortunately, they died out |
| 16:51:59 | jtimon: | well, I think most frc pools are based on p2pool software, that may have contributed to my confussion |
| 16:52:20 | jtimon: | in frc there's only centralized pools and p2pools |
| 16:52:56 | Luke-Jr: | makes sense, GBT isn't feasable for FRC as-is |
| 16:53:03 | jtimon: | my point for adam3us was "instead of thinking about micro-mining, think of a way were only p2p pools are allowed" |
| 16:53:21 | forrestv: | as usual, Luke-Jr ignores other benefits of p2pool |
| 16:53:24 | Luke-Jr: | ok, but my point is that p2p is a bad thing; what you want is decentralisation |
| 16:53:29 | forrestv: | 's complete decentralization |
| 16:53:52 | Luke-Jr: | forrestv: there are none, to the network |
| 16:55:29 | jtimon: | * jtimon doesn't understand the difference between decentralized and p2p in this context |
| 16:57:19 | Luke-Jr: | jtimon: decentralised = miners create the blocks; p2p = there's no server to coordinate things |
| 16:58:03 | jtimon: | I see, yeah decentralized is enough since all miners validate everything, no? |
| 16:58:19 | forrestv: | Luke-Jr, you really need to use a name other than "decentralized," considering that eligius definitely has a central server.. |
| 16:58:22 | Luke-Jr: | well, all nodes validate everything, miner or not |
| 16:58:46 | Luke-Jr: | forrestv: the mining isn't centralised though |
| 16:58:53 | jtimon: | I mean, in a centralized pool, a miner only hashes, doesn't see anything else |
| 17:00:07 | jtimon: | the validation node of a centralized pool can do more harm than the coordination server of a decentralized pool |
| 17:00:23 | adam3us: | jtimon: agreed |
| 17:01:11 | adam3us: | 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:40 | jtimon: | I don't know how this could work, probably changing the PoW, just wanted to inspire you adam3us |
| 17:01:53 | Luke-Jr: | jtimon: it cannot work. |
| 17:02:03 | Luke-Jr: | jtimon: if you take away centralised mining, hosted mining will flourish |
| 17:02:09 | jtimon: | I don't really like the word vote, then people say stupid things like "miners vote the rules of the system" |
| 17:02:23 | Luke-Jr: | "voice" perhaps |
| 17:03:09 | adam3us: | Luke-Jr: hosted mining is even worse, so that is a bad game theory outcome. |
| 17:03:13 | helo: | shoehorn? |
| 17:03:14 | jtimon: | which degenerates in even more stupid things like "scrypt is more democratic than SHA256" |
| 17:03:18 | Luke-Jr: | adam3us: that's my point |
| 17:03:41 | Luke-Jr: | adam3us: stopping hosted mining is impossible, and that's what we'll get if we take away centralised mining |
| 17:04:00 | adam3us: | 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:00 | jtimon: | Luke-Jr, why? |
| 17:04:01 | sipa: | Luke-Jr: decentralized != trust-free |
| 17:04:07 | sipa: | Luke-Jr: eligius is trust-free, but centralized |
| 17:04:21 | brisque: | "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:56 | jtimon: | sipa: yeah, I guess that's the word we were looking for: p2pool and eligious are both trustless pools |
| 17:05:05 | sipa: | yup |
| 17:05:14 | Luke-Jr: | sipa: that might be better terminology, but it's not the common terminology already in use |
| 17:05:35 | adam3us: | Luke-Jr: does eligius reject/not support non-GBT shares? |
| 17:05:48 | Luke-Jr: | adam3us: Eligius supports all protocols at the moment |
| 17:05:56 | sipa: | 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:11 | adam3us: | Luke-Jr: so its trustless to the extent users use GBT then |
| 17:06:31 | brisque: | Luke-Jr: what sort of percentage of users use GBT over stratum? |
| 17:06:41 | Luke-Jr: | brisque: probably near zero :/ |
| 17:06:43 | sipa: | trust-free doesn't mean you cannot trust anyone - it just means you don't need to |
| 17:06:55 | Luke-Jr: | the solution is to make decentralised mining just as easy/painless as centralised mining |
| 17:07:20 | Luke-Jr: | sipa: trust-free implies more than decentralisation IMO |
| 17:07:30 | adam3us: | Luke-Jr, sipa: so it seems to me there is some pain. the bw consumption. |
| 17:07:33 | brisque: | Luke-Jr: imagine i'm a miner, is there an incentive for me to use GBT on eligius over Stratum? |
| 17:07:45 | Luke-Jr: | brisque: only for the good of Bitcoin |
| 17:07:46 | jtimon: | Luke-Jr open transaction is trustless but centralized |
| 17:08:05 | brisque: | Luke-Jr: mm, there's the reason why lots of people don't use it. |
| 17:08:26 | sipa: | Luke-Jr: they overlap, but neither implies the other |
| 17:08:46 | sipa: | jtimon: trust-free to an extent - you still need to trust the issuer |
| 17:08:48 | Luke-Jr: | sipa: p2p != decentralisation |
| 17:09:39 | jtimon: | sipa : for non-p2p currencies you always need to trust the issuer anyway |
| 17:10:15 | jtimon: | if you issue usdCoins using colored coins is no different |
| 17:11:39 | adam3us: | 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:30 | adam3us: | 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:36 | jtimon: | adam3us: my point is that, despite being centralized, you don't need to trust the OT server |
| 17:13:39 | adam3us: | 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:14 | jtimon: | yes, the same issuer can operate in different OT servers at the same time |
| 17:15:36 | jtimon: | 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:37 | stonecoldpat: | 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:40 | adam3us: | 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:02 | jcrubino: | does there need to be any protocol level changes for stealth addresses? |
| 17:16:37 | Luke-Jr: | adam3us: I don't think that's very practical on a wide scale. |
| 17:16:46 | adam3us: | 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:53 | Luke-Jr: | adam3us: for the low variance many miners want, you *need* to keep a running balance somewhere |
| 17:17:04 | jtimon: | jcrubino: I don't think so, just the payment protocol |
| 17:17:16 | adam3us: | jcrubino: i do not think so. just client work. |
| 17:18:00 | jcrubino: | and does anyone in here have bitcoin-dev mailing list archived from the beginning? |
| 17:18:09 | adam3us: | 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:12 | Luke-Jr: | jcrubino: I think SF has an official archive |
| 17:18:28 | jcrubino: | Luke-Jr: can I download it all at once? |
| 17:18:35 | Luke-Jr: | no idea |
| 17:21:04 | jcrubino: | hmm |
| 17:21:27 | jcrubino: | I want to try to do a topic mapping of the messages |
| 17:21:56 | TD: | TD is now known as TD[away] |
| 17:22:30 | adam3us: | jcrubino: maybe wget -r from the right base url might do the trick |
| 17:24:45 | jcrubino: | adam3us: It looks like the actual messages are id with every other message on SF |
| 18:27:49 | michagogo|cloud: | ;;seen andytoshi |
| 18:27:50 | gribble: | 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:16 | michagogo|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:16 | gribble: | The operation succeeded. |
| 18:30:23 | wallet421: | wallet421 is now known as wallet42 |
| 18:32:33 | wallet42: | so stealth addresses are base58_check encoded compressed pubkeys? whats the version byte? |
| 19:25:48 | justanotheruser: | Is it possible to make an easy to confirm hashing function that involves all the previous confirmed tx? |
| 19:26:04 | justanotheruser: | *easy to validate |
| 19:33:57 | gmaxwell: | justanotheruser1: you mean what we're already using in Bitcoin? |
| 19:34:16 | justanotheruser1: | gmaxwell: no I mean your idea that would require miners to have the blockchain |
| 19:35:40 | gmaxwell: | justanotheruser1: I assume you mean easy to validate you mean fully validatable by someone who doesn't have that data? |
| 19:37:26 | justanotheruser1: | 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:05 | gmaxwell: | justanotheruser1: I thought I described such an approach in the post about that? |
| 19:38:24 | justanotheruser1: | gmaxwell: I haven't seen your post, just the wiki page. Could you link me it? |
| 19:39:06 | gmaxwell: | 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:50 | gmaxwell: | 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:03 | gmaxwell: | 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:46 | justanotheruser1: | gmaxwell: So N is generated based on the block header? |
| 19:43:49 | gmaxwell: | 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:33 | gmaxwell: | 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:10 | justanotheruser1: | 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:27 | justanotheruser1: | (in a hypothetical situation where miners only store 1mb of tx to save space) |
| 19:47:34 | gmaxwell: | previous header. as in the prior block. |
| 19:49:33 | justanotheruser1: | 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:48 | justanotheruser1: | s/to find the block/to find the tx for the block |
| 19:50:53 | gmaxwell: | only by doing N fold the work of finding a block. |
| 19:52:46 | justanotheruser1: | gmaxwell: well the work of finding a block is memory hard, but finding an easy header isn't. |
| 19:53:04 | justanotheruser1: | unless there's something I'm missing |
| 19:53:18 | gmaxwell: | I have no freeking clue what you're talking about there. |
| 19:54:06 | gmaxwell: | 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:17 | gmaxwell: | The explicit goal of that was not to make the POW memory hard. |
| 19:57:59 | justanotheruser1: | gmaxwell: I thought the purpose was to keep centralized pools that don't require blockchain ownership infeasible |
| 20:00:11 | maaku: | adam3us: there would need to be some infrastructure for recognizing and handling covenants at the user interface level. |
| 20:00:18 | maaku: | users will probably have to whitelist which covenants are accepted under which circumstances... there are some nontrivial problems here. |
| 20:00:18 | gmaxwell: | 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:28 | maaku: | 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:41 | maaku: | and that should certainly be the default behavior |
| 20:00:51 | maaku: | 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:04 | maaku: | but on the whole there are some definite advantages, such as the p2p lending case which was an outstanding unsolved problem |
| 20:01:26 | maaku: | 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:33 | maaku: | that's a definate improvement from the user's perspective. |
| 20:02:01 | maaku: | 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:08 | maaku: | 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:36 | maaku: | 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:48 | maaku: | 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:59 | justanotheruser1: | maaku: what? |
| 20:03:21 | justanotheruser1: | Where was I talking about PoS |
| 20:04:01 | maaku: | [08:16:06] Do you think PoS could ever work in a currency? |
| 20:08:43 | andytoshi: | 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:45 | andytoshi: | http://download.wpsoftware.net/bitcoin/cj-windows.zip |
| 20:08:54 | jtimon: | yes, maaku, we wouldn't remove the tagged assets with defined interest/demurrage |
| 20:09:39 | jtimon: | I'm thinking we might be able to replace validation scripts, thought I would like to check that case by case |
| 20:11:05 | maaku: | what for offers and stuff? I don't know, maybe |
| 20:11:11 | maaku: | it'd be a little convoluted |
| 20:11:23 | maaku: | /offers/options/ |
| 20:11:53 | maaku: | the delegation opcode is pretty elegant |
| 20:12:00 | jtimon: | well, we use them in most of our examples |
| 20:12:32 | maaku: | you could move the relevant coins into an output with a covenant attached governing their next use in the option or whatever |
| 20:12:36 | maaku: | obviously that would work |
| 20:12:47 | jtimon: | I was thinking about using the same opcodes somewhere else, but I haven't thought about it deeply enough |
| 20:12:51 | maaku: | but I don't think it's a very natural, succinct, or satisfying situation |
| 20:14:15 | maaku: | i think there are many use cases where the conditions are most naturally applied to the transaction itself |
| 20:14:42 | maaku: | 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:46 | adam3us: | 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:09 | jtimon: | yeah, as said I haven't tried yet, I was just thinking about what could be replaced and what not |
| 20:15:48 | jtimon: | "viral covenants that can apply to all further respends indefinitely" I thought that was the definition of a covenant |
| 20:15:55 | adam3us: | gmaxwell: btw i asked djb and cfrg some questions about ed25519, will see if we get some clarity. |
| 20:16:31 | maaku: | jtimon: we can probably shuffle stuff around, if we start over assuming a more powerful scripting language |
| 20:16:39 | andytoshi: | adam3us: thx much |
| 20:16:46 | maaku: | but i wouldn't get rid of tx-level validation scripts |
| 20:17:08 | maaku: | adam3us: isn't there an rfc process going on? you might want to forward comments to those relevant mailing lists as well |
| 20:17:52 | gmaxwell: | 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:19 | adam3us: | 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:54 | maaku: | adam3us: covenants also allow you to do things which you can't currently do, at all (like restricted buy back) |
| 20:19:15 | gmaxwell: | 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:17 | maaku: | that's a very serious pro against a very hypothetical con |
| 20:19:23 | jtimon: | adam3us: not english but I thought: quine = reproduction of code, covenant = viral perpetual quine |
| 20:19:24 | adam3us: | 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:49 | gmaxwell: | adam3us: it seems really hard to achieve that. |
| 20:19:55 | adam3us: | gmaxwell: precisely. i think ethereum is creating unlimited danger as there are no restrictions and it is intentionally as general as possible |
| 20:20:11 | gmaxwell: | (achieve that while also permitting the good use) |
| 20:20:33 | adam3us: | 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:41 | maaku: | 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:52 | maaku: | relegated to the equivalent of a spam wallet |
| 20:21:18 | gmaxwell: | 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:42 | maaku: | we can then experiment and slowly add functionality to allow users to enable certain covenants, pattern matched or detected by theorum proving |
| 20:21:55 | adam3us: | 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:49 | jtimon: | adam3us what do you think about maaku's suggestion of killing fungibility in the clients? |
| 20:22:57 | gmaxwell: | 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:56 | jtimon: | gmaxwell: I think the validators maaku has in mind would answer a) It is not a covenant b) I don't know |
| 20:24:09 | adam3us: | 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:13 | gmaxwell: | lol, post on liberation-tech: |
| 20:25:15 | gmaxwell: | As one anecdote, when I TAed the MIT Network and Computer security |
| 20:25:15 | gmaxwell: | course, we assigned "Why Johnny Can't Encrypt" as the first reading. |
| 20:25:15 | gmaxwell: | We asked the students to send us a PGP encrypted & signed message and |
| 20:25:15 | gmaxwell: | tell us how long it took. |
| 20:25:17 | gmaxwell: | If I recall correctly, it took an average of 30 minutes for |
| 20:25:18 | adam3us: | 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:19 | jtimon: | adam3us isn't your "all exchanges will port to kycCoin" concern eliminated? |
| 20:25:20 | gmaxwell: | non-existing users to figure out how to use PGP. Think about that. |
| 20:25:22 | gmaxwell: | These were graduate & upperclass undergraduate computer science |
| 20:25:25 | gmaxwell: | students enrolled in a network security course. Everyone had accounts |
| 20:25:27 | gmaxwell: | on the same university system and were mostly using standalone email |
| 20:25:30 | gmaxwell: | clients. |
| 20:25:32 | gmaxwell: | Best of all, someone decided it would be funny to generate a fake key |
| 20:25:35 | gmaxwell: | for me and post it to pgp.mit.edu. Several students fell for the |
| 20:25:37 | gmaxwell: | trick, didn't verify the key, and encrypted their homework with the |
| 20:25:40 | gmaxwell: | wrong key. |
| 20:25:49 | maaku: | gmaxwell: sure you can, an inconclusive result is assumed to be worst-case |
| 20:26:24 | jtimon: | adam3us: the point of all this is precisely to increase the language power |
| 20:26:30 | adam3us: | jtimon: amlcoin via virality risk reduced not eliminated |
| 20:26:41 | gmaxwell: | maaku: ugh, okay I suppose. But you're going to be inclusive an awful lot of the time. |
| 20:26:56 | adam3us: | jtimon: well the point should be to allow contracts to be conveniently expressible language power = danger also. |
| 20:27:21 | maaku: | 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:15 | jtimon: | gmaxwell do you share adam3us concerns on all btc becoming amlcoins without the dumb users noticing? |
| 20:29:47 | adam3us: | 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:54 | gmaxwell: | jtimon: Yes. It's not about "dumb" it's about having forced choice. |
| 20:29:57 | jtimon: | maybe maaku and I are too optimistic but to me it seems an exhageration |
| 20:30:17 | adam3us: | * adam3us is loathe to repeat that long thread |
| 20:30:28 | jtimon: | "having forced choice"? I don't understand |
| 20:30:31 | gmaxwell: | 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:43 | gmaxwell: | Not all choices are meaningful, even in the presence of perfect information. |
| 20:30:53 | jtimon: | who forces you to accept amlcoins? who forces you to turn your btc into amlcoins? |
| 20:30:53 | maaku: | jtimon: well, we're also thinking about this in the context of having 5% of the monetary base refreshed annually |
| 20:31:11 | adam3us: | 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:50 | jtimon: | 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:04 | adam3us: | 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:23 | jtimon: | 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:33 | andytoshi: | 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:06 | andytoshi: | 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:13 | adam3us: | 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:20 | andytoshi: | which led to things like, eg the cds market hitting a 4 quadrillion cap :P |
| 20:34:40 | jtimon: | " amlcoin enforced at exchanges" you mean prohibiting bitcoin exchanges? |
| 20:35:00 | adam3us: | andytoshi: fascinating analogy. and we think we can protect that by restricting the contract language? (probably not) |
| 20:35:22 | gmaxwell: | 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:13 | andytoshi: | 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:15 | adam3us: | 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:19 | jtimon: | adam3us: I just don't believe all countries will prohibit bitcoin exchanges |
| 20:36:31 | andytoshi: | and have a very simple-to-describe but very precise "here is where the thinking went wrong" explanation of that whole situation |
| 20:37:37 | jtimon: | " 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:59 | adam3us: | 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:32 | andytoshi: | adam3us: re "restricting language", maybe that is exactly what we want to do, combined with maaku's "provably nonviral" ideas |
| 20:38:37 | adam3us: | jtimon: right. thats what would happen to any exchange that was forced by regulation to use amlcoin covenants |
| 20:38:56 | andytoshi: | 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:01 | adam3us: | andytoshi: i dunno sounds like halting problem^2 in hardness |
| 20:39:25 | gmaxwell: | adam3us: no, because as maaku pointed out, you can fail-safe. |
| 20:39:39 | gmaxwell: | If the static analysis can't prove your transaction sufficiently non-viral, its just not valid. |
| 20:39:56 | andytoshi: | 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:57 | adam3us: | 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:04 | adam3us: | gmaxwell: maybe. now security depends on a few more components including a theorem prover's comprehension vs virus writers |
| 20:42:44 | adam3us: | andytoshi: nice to have a fast to verify compact proof yes. |
| 20:43:25 | andytoshi: | 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:32 | nsh: | we're on to viral transactions now? great... |
| 20:43:54 | andytoshi: | 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:10 | adam3us: | andytoshi: maybe. or we could amuse ourselves with what we can do with non-extrospection languages |
| 20:44:34 | andytoshi: | yeah, i'm really impressed and surprised with what you guys have found to be possible |
| 20:44:40 | nsh: | i'd like to see a fully darwinian transactosphere... |
| 20:45:04 | adam3us: | nsh: suggest looking at ethereum. will be interesting to spectate :) |
| 20:45:22 | nsh: | * nsh nods |
| 20:47:56 | nsh: | 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:54 | nsh: | not sure exactly what all those words means though so it'll probably remain pretty deep in my imagination :) |
| 20:49:16 | adam3us: | * adam3us wonders if its considered part of redcode game to write ethereum stealing viruses? |
| 20:49:57 | andytoshi: | that's interesting, if you can infect a majority of hashpower you can "hack the matrix" so to speak :P |
| 20:50:31 | nsh: | (it's always part of the metagame to cheat in ways that haven't be considered and thus explicitly prohibited) |
| 20:50:32 | andytoshi: | i guess i mean, if you can infect almost all the validating nodes |
| 20:51:08 | gmaxwell: | 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:29 | gmaxwell: | so you've got a couple of pools, a couple of exchanges, an odd geek or two, and thats it. |
| 20:52:17 | adam3us: | 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:17 | gmaxwell: | 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:14 | adam3us: | gmaxwell: ha not only no tx, no wallet, but not even any full nodes. |
| 20:53:16 | nsh: | hmmm |
| 20:54:47 | gmaxwell: | 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:51 | adam3us: | 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:09 | gmaxwell: | adam3us: you could call it "mastercoin" |
| 20:55:41 | adam3us: | gmaxwell: minioncoin. many someone should fork mastercoin and put it on top of dogecoin |
| 20:56:02 | gmaxwell: | Every dog has his master. |
| 20:56:25 | gmaxwell: | Many leashes. Such dogwalk. |
| 20:56:51 | gmaxwell: | the "exodus" needs to be DogCarRide |
| 20:57:47 | adam3us: | gmaxwell: please can 2014 be the year of the death of tulip coins? |
| 21:00:36 | kinlo: | heh, to see gmaxwell talk dogetalk made me laugh :) |
| 21:03:35 | michagogo|cloud: | andytoshi: Erm, you've given me an error I've never seen before |
| 21:03:36 | michagogo|cloud: | http://imgur.com/ZTcyCyR,kwBmvFO |
| 21:04:21 | michagogo|cloud: | andytoshi: Is the file I got broken? |
| 21:04:21 | michagogo|cloud: | 3836c0fef1bffbb4ed7c35564dbb23ad51295a74df7bc53b234b13e198bf4264 */cygdrive/c/Users/Micha/Downloads/cj-windows.zip |
| 21:04:24 | gmaxwell: | kinlo: that meme was a favorite in my household two months ago. dogecoin is kinda overplaying it at this point. |
| 21:04:27 | michagogo|cloud: | (sha256) |
| 21:04:34 | maaku: | "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:45 | maaku: | i was suggesting it as part of the IsStandard check and wallet code |
| 21:05:17 | adam3us: | 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:26 | kinlo: | 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:30 | gmaxwell: | 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:03 | andytoshi: | michagogo|cloud: strange, i'll refresh the download, one sec |
| 21:06:55 | maaku: | adam3us: I think that's the discussion I heard about |
| 21:07:44 | andytoshi: | michagogo|cloud: that is a bad hash, thx for letting me know, fixed now |
| 21:07:48 | maaku: | gmaxwell: with sufficient user level protections I don't rate amlcoin as a serious existential risk |
| 21:08:20 | michagogo|cloud: | ;;cjs |
| 21:08:22 | gribble: | Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one. |
| 21:08:55 | michagogo|cloud: | andytoshi: woot |
| 21:09:07 | michagogo|cloud: | (so far, so good... no errors this time, it knows there's no open session) |
| 21:09:52 | andytoshi: | michagogo|cloud: excellent :) sorry, i forgot to stand up the testnet instance of the server, will do that now |
| 21:10:19 | adam3us: | * adam3us is old enough to remember people making analogous claims to reason about systematic MITM, CA malfeasance in the CA security model. |
| 21:11:09 | michagogo|cloud: | andytoshi: What's the format of cjclient.conf? |
| 21:11:19 | michagogo|cloud: | atm I see joinerserver = https://wpsoftware.net/coinjoin/cj-client.php in there |
| 21:11:21 | michagogo|cloud: | and that's it |
| 21:11:24 | adam3us: | maaku: (i was complaining at the time.. 1993ish that a dissident trusting CA infrastructure is crazy) |
| 21:11:59 | maaku: | adam3us: so? that was as sensible a thing to say then as now |
| 21:12:26 | maaku: | that doesn't mean you're right on this issue |
| 21:12:30 | adam3us: | 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:46 | michagogo|cloud: | andytoshi: (I mean, what are the other options) |
| 21:12:49 | maaku: | apples and oranges |
| 21:12:53 | andytoshi: | michagogo|cloud: rpcconnect, rpcuser, rpcpassword and rpcport all work as in bitcoind |
| 21:13:08 | maaku: | if the NSA demands the root cert from the CA, it *is* undetectable |
| 21:13:16 | michagogo|cloud: | So to use testnet I'd set rpcport = 18333? |
| 21:13:25 | michagogo|cloud: | 18332* |
| 21:13:26 | andytoshi: | michagogo|cloud: yeah, that should work |
| 21:13:29 | michagogo|cloud: | And what's the URL? |
| 21:13:38 | maaku: | covenants, on the other hand, by their very nature are prominently part of the script |
| 21:13:40 | andytoshi: | http://testing.wpsoftware.net/coinjoin/ |
| 21:13:45 | adam3us: | 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:01 | maaku: | to do... what exactly? |
| 21:14:21 | michagogo|cloud: | andytoshi: bleh... |
| 21:14:26 | michagogo|cloud: | Syncing with joiner, session ID unknown |
| 21:14:26 | michagogo|cloud: | Join server: SSL: no alternative certificate subject name matches target host name 'testing.wpsoftware.net' |
| 21:14:42 | maaku: | 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:44 | adam3us: | maaku: anything that is expedient if history teaches us anything. mandate viral amlcoins per example |
| 21:14:49 | andytoshi: | michagogo|cloud: sorry, testing.wpsoftware does not have an SSL cert, just use HTTP |
| 21:15:05 | michagogo|cloud: | Ah, k |
| 21:15:35 | adam3us: | 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:45 | adam3us: | 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:45 | andytoshi: | michagogo|cloud: ok, how about we do a 1.1 testnet join? |
| 21:16:46 | michagogo|cloud: | andytoshi: "Joiner status: session not found." |
| 21:17:02 | andytoshi: | michagogo|cloud: oh :P click "Session->Forget Session" |
| 21:17:07 | andytoshi: | oh, wait.. |
| 21:17:14 | maaku: | adam3us: at least where there is rule of law, taking away someone's capability to use their property is amount to theft |
| 21:19:16 | adam3us: | 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:49 | spenvo: | #go-nuts |
| 21:21:52 | adam3us: | 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:57 | spenvo: | sorry about that |
| 21:22:43 | adam3us: | maaku: jtimon gave an example of something he claimed was impossible without covenants? |
| 21:22:44 | maaku: | 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:57 | maaku: | all before it gets far enough along to be entrenched |
| 21:23:24 | maaku: | adam3us: yes, restricted buy-back (of IOUs, to use his example) |
| 21:23:28 | adam3us: | maaku: i dont know. but the adversary is adaptive and intelligent also. coinvalidation would itself be viral |
| 21:24:10 | maaku: | 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:30 | maaku: | /demurrage/interest/ |
| 21:24:45 | michagogo|cloud: | andytoshi: I ticked my inputs and clicked view transaction |
| 21:24:49 | michagogo|cloud: | Now it's frozen |
| 21:25:43 | adam3us: | maaku: so what about a micro-channel. either party can pull-out and claim whats paid to date. interest paid periodically. |
| 21:25:58 | andytoshi: | michagogo|cloud: aw, shit |
| 21:26:12 | michagogo|cloud: | andytoshi: Oh, wait |
| 21:26:14 | maaku: | adam3us: tx replacement? vulnerable to double-spend |
| 21:26:31 | michagogo|cloud: | Just opened up a tailf on bitcoin's debug.log |
| 21:26:48 | michagogo|cloud: | Looks like it's busy drawing addresses |
| 21:27:07 | andytoshi: | how many output did you ask for? |
| 21:27:08 | maaku: | not to mention you wouldn't be able to move around ownership (resell debt) |
| 21:27:15 | andytoshi: | it shouldn't do an infinite loop if that's what you're seeing |
| 21:27:29 | adam3us: | maaku: or is there a less powerful language feature that could enable the class of use cases? |
| 21:27:42 | maaku: | adam3us: that would be entirely missing the point |
| 21:28:03 | maaku: | we *want* these crazy covenant use cases |
| 21:29:12 | maaku: | it's just doing so with the decentralized host currency that is problematic |
| 21:29:16 | michagogo|cloud: | andytoshi: My output is in the 5 digits |
| 21:29:28 | adam3us: | maaku: most of the examples on the covenant bct thread looked grey-goo like in their end game. |
| 21:29:41 | michagogo|cloud: | andytoshi: I think it's drawing ~21k keys... |
| 21:29:48 | maaku: | well that was the point of the covenant thread |
| 21:30:04 | andytoshi: | michagogo|cloud: hahahaha, ok, i should definitely do a sanity check there |
| 21:30:25 | andytoshi: | (and you probably want to kill it) |
| 21:30:29 | adam3us: | 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:33 | michagogo|cloud: | It's about half-way done |
| 21:31:02 | maaku: | adam3us: that's something for the payment protocol |
| 21:31:31 | adam3us: | maaku: (he's using some PoW thing i mentioned to him in ethereum it seems) |
| 21:32:23 | justanotheruser1: | maaku: I see. Do you think anything but PoW could work? |
| 21:32:32 | adam3us: | 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:48 | andytoshi: | 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:59 | maaku: | justanotheruser1: what for consenus? no. proof-of-work is absolutely perfect |
| 21:33:24 | maaku: | the defficiencies people often quote are actually what makes it work |
| 21:33:34 | Luke-Jr: | O.o |
| 21:33:38 | Luke-Jr: | far from perfect imo |
| 21:33:43 | justanotheruser1: | maaku: No it isn't. Someone 20% of the processing power could reverse 6 confirmations within a day |
| 21:33:53 | adam3us: | 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:25 | maaku: | 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:30 | maaku: | at the moment |
| 21:34:38 | michagogo|cloud: | 2014-01-15 21:34:29 keypool reserve 17592 |
| 21:34:53 | Luke-Jr: | maaku: I didn't say I knew something better, just that PoW isn't perfect :P |
| 21:34:54 | adam3us: | 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:06 | maaku: | justanotheruser1: and there's no getting around that. not without compromising what PoW gives you |
| 21:35:25 | maaku: | don't mistake a rule of thumb (6 confirms) with the actual security model of proof of work |
| 21:35:38 | justanotheruser1: | maaku: I never said there is a way to get around that. I just am pointing out that it is an imperfection. |
| 21:35:56 | maaku: | adam3us: sure, who cares if you put a crazy grey-goo covenant on your personally issued asset? |
| 21:36:07 | maaku: | in freimarkets at least, where user assets aren't host currency |
| 21:36:16 | adam3us: | maaku: the person who bought it cares maybe |
| 21:36:50 | justanotheruser1: | whats freimarkets |
| 21:37:06 | maaku: | 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:06 | adam3us: | maaku: especially if it was expensive or the issuer is a bank say |
| 21:37:40 | gmaxwell: | 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:49 | gmaxwell: | (nice metaphor) |
| 21:37:54 | adam3us: | 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:32 | maaku: | 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:42 | maaku: | that is actually pro-consumer |
| 21:39:22 | maaku: | (idk. maybe we end up using old-style bitcoin scripts for host currency outputs, to avoid the grey-goo, or disable opcodes) |
| 21:39:31 | adam3us: | maaku: yeah that i like and is a central promise of smart-contracts as applied to block-chain validation |
| 21:40:26 | adam3us: | 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:44 | michagogo|cloud: | andytoshi: Ah, so you just call createrawtransaction? |
| 21:40:54 | maaku: | justanotheruser1: ok i'm a pragmatist who defines "perfect" as the best which can be actually achieved :) |
| 21:41:31 | justanotheruser1: | maaku: okay. |
| 21:41:31 | maaku: | justanotheruser1: https://bitcointalk.org/index.php?topic=278671.0 |
| 21:41:55 | michagogo|cloud: | andytoshi: Hmm, I clicked the "Submit Transaction to Joiner" button |
| 21:41:59 | michagogo|cloud: | Nothing seems to have happened |
| 21:42:17 | michagogo|cloud: | http://testing.wpsoftware.net/coinjoin/ doesn't show there being a session |
| 21:43:25 | justanotheruser1: | maaku: is there a reason this has to be part of bitcoin and not just merged mined with it? |
| 21:43:59 | maaku: | adam3us: I think if you disabled the LOAD_TRANSACTION opcode in host currency, all of these fears would disappear |
| 21:44:20 | maaku: | justanotheruser1: what are you talking about? |
| 21:44:49 | justanotheruser1: | maaku: What do you mean by "an extension of bitcoin"? |
| 21:46:08 | maaku: | 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:12 | maaku: | this are hard-fork changes |
| 21:46:29 | justanotheruser1: | maaku: does it have merged mining? |
| 21:47:01 | maaku: | justanotheruser1: that's a tangential question. this could in principle be applied to bitcoin in a future hard fork |
| 21:47:23 | maaku: | 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:00 | maaku: | so yes, it will be merged mined, but that's a point separate from the proposal itself |
| 21:49:23 | michagogo|cloud: | andytoshi: aha, the cj-client tries to spend to the mainnet fee/donation address |
| 21:49:32 | michagogo|cloud: | So it fails because that address isn't valid |
| 21:51:18 | justanotheruser1: | maaku: whats the difference between this and protoshares an mastercoin? |
| 21:51:18 | justanotheruser1: | *and |
| 21:51:18 | justanotheruser1: | and coloredcoins |
| 21:51:46 | maaku: | justanotheruser: read the thread |
| 21:51:57 | justanotheruser: | I am |
| 21:52:19 | michagogo|cloud: | andytoshi: Heh, I tried manually creating that transaction |
| 21:52:30 | maaku: | also this one : https://bitcointalk.org/index.php?topic=280292.0 |
| 21:52:51 | michagogo|cloud: | On attempt to submit to the coinjoiner's web interface, 413 Request Entity Too Large |
| 21:52:51 | maaku: | (more appropriate to post there if you have technical questiosn than the crowdfund thread) |
| 21:57:07 | adam3us: | 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:52 | maaku: | 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:01 | adam3us: | 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:21 | maaku: | yeah forth is kinda on the level of intermediate code |
| 21:59:43 | adam3us: | maaku: i dont know what load-tx does? |
| 21:59:47 | gmaxwell: | adam3us: really? I think forth is basically ideal. |
| 22:00:09 | gmaxwell: | adam3us: The problem with higher level languages is that they're easy to hide subtle behaviors in. |
| 22:00:21 | adam3us: | gmaxwell: taste i guess. i did some dc programming, kind of reminds me. yes unambiguity is a good thing |
| 22:00:41 | maaku: | 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:42 | adam3us: | maaku: i guess the extrospection hook? |
| 22:00:47 | maaku: | yeah |
| 22:00:50 | gmaxwell: | "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:23 | gmaxwell: | The forth is high enough level to express what it means, mostly, but low enough level to also express what it does. |
| 22:01:49 | adam3us: | gmaxwell: only complaint is like readability. especially with the long OP_BLAH names. |
| 22:01:55 | gmaxwell: | takes more study to understand than something higher level but has a harder time lying to you. |
| 22:02:04 | gmaxwell: | oh well yea, surely better tools could be done for working with it. |
| 22:02:51 | gmaxwell: | including things like pesudo opcodes that compress common and easily explained idioms. |
| 22:04:10 | adam3us: | 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:44 | maaku: | adam3us: yes you would have to use user-issued IOUs, although that was the original scenario |
| 22:07:11 | maaku: | in fact I'm not sure how you'd do the loan trading freicoins for freicoins |
| 22:07:26 | maaku: | the point was that you loan the freicoins into existence |
| 22:08:17 | maaku: | you could still do some nasty things based on UTXO state (maybe you disable that as well) |
| 22:08:31 | adam3us: | maaku: doesnt that risk uncontrolled supply side inflation? |
| 22:08:56 | maaku: | that's ... rather the point isn't it? |
| 22:09:02 | maaku: | debt-based IOU currency |
| 22:09:36 | maaku: | maybe there's a misunderstanding here? i'm not sure what it is |
| 22:09:40 | adam3us: | maaku: fair enough there, but in relation to there existing two types: mined freicoins with demurrage and iou ones |
| 22:12:06 | maaku: | well sortof. IOU freicoins are actually freicoins, just a promise from whoever issued them to eventually, someday redeem them |
| 22:12:31 | maaku: | they're only usable as currency in so much as other people are willing to accept that IOU promise |
| 22:12:55 | maaku: | ripple is built on this premise |
| 22:13:31 | gmaxwell: | How is ripple doing btw? |
| 22:13:32 | adam3us: | 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:01 | maaku: | oh i meant pre-OpenCoin ripple. no idea what they're up to :) |
| 22:14:43 | maaku: | adam3us: yes, and with sub-transactions you can build atomic movements of these IOUs through the trust graph |
| 22:14:43 | adam3us: | maaku: i think it'd be fair to call this real-ripple. |
| 22:15:06 | gmaxwell: | meh. I still think real-ripple ought not need a global consensus system. |
| 22:15:30 | maaku: | but where there are gaps in the graph, exchanging IOU-for-freicoin instead of IOU-for-IOU lets you get hard currency |
| 22:16:02 | maaku: | gmaxwell: agreed, except when you want to interact with non-ripple assets like bitcoin/freicoin |
| 22:17:00 | maaku: | 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:01 | gmaxwell: | maaku: well, when you want to interact with them in a way which isn't trusting of an issuer. |
| 22:17:08 | maaku: | yes |
| 22:20:00 | midnightmagic: | real-ripple didn't. |
| 22:20:09 | midnightmagic: | :-( |
| 22:21:52 | maaku: | midnightmagic: unfortunately the distributed protocol was never implemented :\ |
| 22:22:08 | midnightmagic: | yah. sad-midnight-face |
| 22:31:53 | andytoshi: | michagogo|cloud: sorry, was afk |
| 22:31:58 | andytoshi: | michagogo|cloud: one moment, cj |
| 22:32:25 | andytoshi: | 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:38 | andytoshi: | michagogo|cloud: gonna head out now, will work on this later tonight, i have having decode problems that didn't happen with mainnet, sorry |
| 22:57:48 | am42: | ? |
| 23:10:34 | jgarzik: | adam3us, unlinkedable static address... USA! USA! USA! |
| 23:10:41 | jgarzik: | * jgarzik waits for the conspiracies to start |
| 23:11:30 | adam3us: | jgarzik: not getting conspiracy part? |
| 23:12:08 | jgarzik: | adam3us, a poor attempt at a joke. e.g. paid by USA to develop tech whose acronym is USA |
| 23:12:26 | adam3us: | jgarzik: oooh.. didnt notice the acronym :) |
| 23:12:33 | jgarzik: | plus an acknowledgement that the bitcoin community will imagine a conspiracy for all events. |
| 23:12:48 | jgarzik: | It's like the multiverse of conspiracies |
| 23:12:56 | jgarzik: | quantum conspiracy theory |
| 23:13:43 | adam3us: | 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:00 | jgarzik: | indeed |
| 23:14:33 | sipa: | that seems contradictory |
| 23:14:43 | sipa: | you want something that achieves privacy from the public |
| 23:14:51 | sipa: | but still want them to do efficient filtering for you |
| 23:15:06 | jgarzik: | 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:06 | adam3us: | sipa: when presented with a key though |
| 23:15:12 | jgarzik: | miner payouts, salary payouts, etc. |
| 23:15:25 | jgarzik: | no good way exists to give a payment stream a set of addresses |
| 23:15:33 | sipa: | adam3us: they could reveal that key |
| 23:15:34 | TD: | lol |
| 23:15:36 | TD: | wallet author lazyness |
| 23:16:04 | TD: | adam3us: you can follow HD wallets in bitcoinj development work here: https://code.google.com/r/hearn-bitcoinj/source/list?name=keychain |
| 23:16:12 | TD: | as you can see lots of code has been going in for the past 6-7 weeks |
| 23:16:30 | adam3us: | 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:44 | Luke-Jr: | jgarzik: HD wallet spec has stuff for that |
| 23:16:51 | TD: | 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:06 | am42: | lol |
| 23:17:17 | am42: | guys... |
| 23:17:37 | jgarzik: | Luke-Jr, yes, any derivation scheme fits the use case |
| 23:17:39 | adam3us: | 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:43 | jgarzik: | as long as it is standardized |
| 23:17:51 | jgarzik: | and private |
| 23:18:13 | jgarzik: | the whole world doesn't need to track my salary |
| 23:18:20 | Luke-Jr: | but it's so fun! <.< |
| 23:19:14 | jgarzik: | 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:48 | TD: | * TD shrugs |
| 23:19:52 | TD: | the point of bitcoin is to move money, well |
| 23:19:57 | TD: | that's why we need to scale the tech |
| 23:20:01 | kinlo_: | kinlo_ is now known as kinlo |
| 23:20:06 | TD: | so we're not afraid of making little transactions if that's what it takes to give good privacy |
| 23:20:29 | TD: | adam3us: anyway if you're feeling non-lazy you're welcome to help chip in with the implementation ..... |
| 23:20:33 | adam3us: | TD: scary looking spec there. btw relatedly petertodd was saying that bloom is not that private with default parameters |
| 23:20:37 | TD: | :) |
| 23:20:48 | TD: | yeah current bitcoinj has a default very low false positive rate and a few bugs |
| 23:21:04 | TD: | ways the remote node can trick you into revealing whether you own a particular key, stuff like that |
| 23:21:21 | TD: | 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:38 | TD: | then if we're on wifi we can ramp it up, etc |
| 23:21:47 | TD: | either that, or some kind of auto measurement/adaptation, but that's harder |
| 23:21:48 | sipa: | well, as long as bitcoinj wallets reuse addresses by default, there's little point in trying to protect privacy using bloom filters ) |
| 23:22:00 | TD: | yeah - that's why i'm working on HD wallets at the moment and not bloom filtering :) |
| 23:22:11 | adam3us: | 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:12 | sipa: | yeah, i know, not commenting there |
| 23:22:23 | am42: | guys i want to buy safe bTC wia Western Union |
| 23:22:30 | am42: | or MoneyGram |
| 23:22:32 | TD: | 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:32 | adam3us: | sipa: ha ha |
| 23:22:41 | am42: | how to do that safe? |
| 23:23:21 | sipa: | am42: not here, try #bitcoin |
| 23:23:35 | wallet42: | td: will bloom filters work with stealth addresses? |
| 23:23:50 | adam3us: | jgarzik: "I would love to find a solution for mass payouts killing privacy." this seems like a coin control issue. |
| 23:23:52 | TD: | i don't know. i haven't really worked through the details of ... lets call them "routing addresses |
| 23:23:55 | adam3us: | wallet42: i think not |
| 23:24:42 | TD: | 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:43 | adam3us: | TD: i was suggesting unlinkable static (vs the current static aka reused). |
| 23:24:56 | TD: | with the payment protocol it might be different because then you don't have to find payments only via the chain |
| 23:25:09 | TD: | adam3us: yeah but i think "static" is jargony |
| 23:25:19 | adam3us: | TD: exactly. the client would have to give the node a private key to scan with. and that scanning is like heavy |
| 23:26:02 | TD: | 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:06 | TD: | but then you have to be online |
| 23:26:10 | adam3us: | 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:11 | TD: | or have a dropbox of some kind |
| 23:26:40 | adam3us: | 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:20 | adam3us: | TD: routing address is not bad. |
| 23:28:50 | adam3us: | 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:52 | TD: | i think it paid dust outputs to miner fees |
| 23:43:30 | EasyAt: | 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:08 | adam3us: | EasyAt: apparently they send tiny payments to lots of people, then watch them be respent. |
| 23:44:52 | EasyAt: | Can't I just track outputs from a target address without tagging it |
| 23:44:53 | adam3us: | 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:18 | adam3us: | EasyAt: well not if someone is not reusing addresses so much. |
| 23:45:47 | EasyAt: | Yea, but once they target my address they can just watch all outputs and the chain of TXs following? |
| 23:46:18 | maaku: | EasyAt: these addresses are one-use only |
| 23:46:19 | adam3us: | 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:29 | maaku: | oh n/m |
| 23:47:03 | sipa: | i really prefer a model where you have to ask for every transaction you have to send first |
| 23:47:20 | sipa: | but it seems the bitcoin economy hasn't evolved that way |
| 23:47:57 | adam3us: | 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:00 | EasyAt: | 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:18 | adam3us: | 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:41 | adam3us: | 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:18 | EasyAt: | adam3us: Indeed, I follow you |
| 23:50:25 | EasyAt: | tainting people |
| 23:50:35 | EasyAt: | Or address grouping, I suppose |
| 23:51:17 | EasyAt: | sipa: In your model I would need permission from the receiver? |
| 23:52:05 | adam3us: | 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:02 | EasyAt: | Interesting, thank your for the input |
| 23:54:35 | adam3us: | in an ideal world we'd have better privacy so people could send you small payments and it wouldnt matter. |
| 23:55:35 | sipa: | EasyAt: i would like that yes |
| 23:55:49 | sipa: | EasyAt: that you could not send coins without permission from the receiver |
| 23:56:13 | EasyAt: | How would cold wallets receive funds in that case |
| 23:56:35 | sipa: | nothing prevents it from being presigned |
| 23:57:41 | EasyAt: | Hm, then wouldn't I need prior knowledge of the TX? How about a cold wallet used for donations? |