00:10:28starsocc-:starsocc- is now known as starsoccer
00:10:58starsoccer:starsoccer is now known as Guest60116
00:58:48starsoccer:starsoccer is now known as Guest12217
01:27:48rusty:gmaxwell: so, would OP_SIDECHAINPROOFVERIFY use a genesis block id of the sidechain as the sidechain identifier?
01:35:29bramc:My impression is that op_sidechainproofverify is supposed to mostly check the amount of work done in the sidechain with very little other requirements on it. The paper does seem vague about it though.
01:36:18sipa:the sidechain needs a transaction type that freezes/burns coins, which OP_SIDECHAINPROOFVERIFY understands
01:37:05gmaxwell:rusty: Yes, the proofs need to be rooted in the genesis block ultimately. though they could instead just prove they continued the chain last used in the last sidechain proof, which would makes them somewhat smaller.
01:37:52bramc:gmaxwell, Why do they need anything more than a transaction giving a destination for the utxo followed by an amount of work?
01:38:13gmaxwell:bramc: to show that the work had anything to do with the chain in question.
02:01:09rusty:gmaxwell: OK, so bitcoind would maintain a sidechains set, which would only ever grow over time.
02:02:36Luke-Jr:rusty: the existing UTXO set works
02:03:13Luke-Jr:or could anyway, maybe it will end up being more efficient to specialise it
02:03:40gmaxwell:rusty: it's just a property of the coins assigned to the sidechain.
02:03:58gmaxwell:(e.g. just conditions in the scriptPubKey)
02:03:58sipa:using the UTXO set means that all sidechain transfers need to be serialized
02:04:32gmaxwell:As you know, bitcoin doesn't track "ownership" but "conditions to release" and conditions get specified in the scriptpubkeys, so it fits nicely.
02:12:12rusty:So, a transfer back from the sidechain would consume N previous to-sidechain UTXOs in some defined order, and (optionally) produce an additional to-sidechain output (for change).
02:14:26Luke-Jr:or undefined order
02:17:07lechuga_:will it just be like coin selection in a wallet?
02:17:52rusty:Luke-Jr: True, but if you want to save utxos somewhere in the blockchain I think you need to define it, otherwise the new UTXO (the to-sidechain change) wouldn't be known?
02:18:23Luke-Jr:lechuga_: hopefully a bit smarter to avoid multiple attempts to claim the same UTXO
02:18:33gmaxwell:The code we've been working on basically lets you do a merge of sidechain coins without any proof. (basically a covenant on the output) so presumably you'd mostly issue proofless transactions to aggregate up the coins.
02:19:18Luke-Jr:gmaxwell: eh, if there's only ever one UTXO to claim, it kinda limits redeeming them
02:19:29Luke-Jr:although I suppose miners can combine multiple
02:19:35gmaxwell:Luke-Jr: you can redeem many at once.
02:19:56gmaxwell:(and I expect expect the sidechain itself to batch the redemptions)
02:20:10Luke-Jr:ah
02:20:14Luke-Jr:that's a good idea
02:26:31rusty:gmaxwell: sweeping sidechain coins together is logical, but it seems like it has a commons problem: the miner who does it just expands their block, whereas the other miners benefit from the decrease utxo set size.
02:27:41gmaxwell:rusty: It benefits the sidechain, if you don't sweep you end up with enormous proof transactions spending many inputs (with many proofs), so someone who wants to emerge coins can reduce their cost of doing so by sweeping.
02:27:53gmaxwell:(and paying fees in the process)
02:31:00rusty:emerge?
02:31:03rusty:* rusty is lost...
02:31:27gmaxwell:return coins from the sidechain.
02:32:13rusty:Right, so that tx would explicitly list the (to-sidechain) inputs it's spending? I was assuming it was implicit, but I guess this is more bitcoiny.
02:41:26Luke-Jr:rusty: iow, it's cheaper to have a transaction merging the sidechain UTXOs followed by redeeming one of them, than to redeem multiple
02:49:30rusty:Luke-Jr: Thanks, right. This is because we're shoehorning it into the bitcoin prove-each-input-separately model. If the inputs were implied, that would not be a problem. We'd just have other problems :)
02:54:05gmaxwell:the inputs model in bitcoin is pretty nice, it sort of magically solves a bunch of corner cases that smack you in the face (or ... stab you in the back, sadly more likely considering how easy it is to make mistakes) as soon as you move away from it.
02:56:14rusty:gmaxwell: OK, so continuing that model, a "oops, that was a fork" disproof would consume (all!) the "bad emerge" outputs?
02:59:21gmaxwell:Yes.
03:00:00rusty:gmaxwell: OK. Would the OP_SIDECHAINPROOFVERIFY ScriptSig explicitly reference a tx output which proved a previous point in the sidechain? Or would it have to prove it since one of its txins?
03:00:19rusty:gmaxwell: assuming we don't want an SPV-since-genesis every time.
03:01:42gmaxwell:In that case it would just show that the linkage back to the block referenced in the prior proof (sort of changing along so it's still ultimately a proof to genesis, just spread over multiple transactions)
03:03:50rusty:gmaxwell: so, the highest-proven block has to be explicitly listed in the sweep txout (and others), otherwise you'd have to traverse back further when it was spent?
03:04:57rusty:ok, scratch (and others), since the others contains a proof which terminates at some block.
03:05:30rusty:I'm looking forward to seeing an actual implementation, or BIP.
03:08:06bramc:The paper does seem oddly vague on the details
03:09:05gmaxwell:It's considerably more detailed than the Bitcoin whitepaper. And it already was 20 something pages long.
03:09:33rusty:bramc: I agree. It had some fascinating stuff, but it read more like a conglomeration than a focussed plan.
03:09:45gmaxwell:The actual mechenism details need to follow from the broader ideas, and also require a lot of public scrutiny to make sure the accomidate people needs are met.
03:10:45rusty:gmaxwell: true, it had to cover a fair bit of ground. The section on SPV proofs was particularly ... unsatisfying.
03:11:51rusty:gmaxwell: but as someone who was actually implementing a "sidechain" at the time, a clear-cut plan would have been nice too :)
03:14:26gmaxwell:rusty: the other element is avoiding that computational security against review problem. Ignoring attention constraints it could have kept the protocol mockup, but then people would fixate on that particular construction, and would be disinclined to review revised versions.
03:16:32gmaxwell:I mean, I think both of you failed to grasp that the proposal is just a soft fork change, though the paper says so directly in plain english. (and also has to explain what a soft-fork change is in order to do it). Communicating is hard.
03:16:47gmaxwell:(failed initially, I mean, even after seeing the paper)
03:17:00rusty:gmaxwell: Yes, mea culpa.
03:19:42bramc:gmaxwell, I'm particularly not-practiced at reading papers and almost always have to ask questions about what they mean
03:20:36bramc:But I was just reading that paper again today having asked a bunch of questions by now because I wanted to see the specifics of the new opcode and was surprised that they're not there.
03:20:39gmaxwell:bramc: sorry, I wasn't trying to single you out. It's the papers fault it didn't communicate to everyone what it needed to. I was just rasing it to show that adding more details isn't free.
03:21:33gmaxwell:Like ... decribing the mechenism in general for a tech audience also sends you down a path of explaining how script works. And the Script as a generalization of script cryptosystems, and the atomic inputs model and...
03:22:03rusty:gmaxwell: I realized after that that I'd skimmed the paper after the first pages and the appendices, meaning to re-read, and didn't.
03:22:09lechuga_:communicating in code easier but more costly
03:23:06gmaxwell:code can be precise, but not clear. Especially without an understanding of the general idea to set the stage. :)
03:24:28gmaxwell:rusty: what about the SPV proof part were you unsatisfied with in particular? It was an appendix in part because it's not core to the concept. Since at least conceptually it can work without the compact proofs (e.g. included every header incrementally in usage); though thats not very awesome. Part of the challange in writing about that area is that its unclear exactly what should be the standar
03:24:34gmaxwell:d for resistance to luck. Pratically all work around bitcoin security in the past has totally ignored this angle. (and, in fact, an attacker with an arbritarly low constant fraction of the hashrate, given infinite time in competition with the honest chain can replace the whole chain with probablity 1; if you assume that the hashrate has exponential growth forever... which is quite surprising, an
03:24:40gmaxwell:d wasn't published until a few months ago)
03:25:26gmaxwell:(this works out for the same reason that SPV proofs have _exactly_ the same expected work as the full header sets they stand in on but higher chance of getting lucky)
03:25:52rusty:gmaxwell: *that* part I loved. I disliked that you didn't say which of the solutions you preferred :)
03:26:19rusty:(and I hadn't realized the issue with SPV proofs until I read that appendix, so it was eye opening)
03:28:52rusty:gmaxwell: BTW I was thinking that a sidechain could have a rule to allow to-bitcoin txs only in the block after a "short" SPV path back to the previous block-with-to-bitcoin-txs. That would help optimize emerge proofs on the bitcoin side, though I haven't thought about whether it makes SPV fakery easier or not...
03:30:35gmaxwell:I think we'd swung back and forth at how much we cared about the variance attacks. If you're adopting a security model where you demand everything to work if all the participants are greedy, then it's easy to discount negative expectation attacks. ... But really that kind of security model is a massive oversimplification of reality (no less so than just stipulating that a majority will follow t
03:30:41gmaxwell:he protocol).
03:31:47bramc:gmaxwell, It seems like when things are put on a sidechain they're likely to have to be pulled off and put back on again from time to time just to reset the amount of work necessary to release them
03:35:55rusty:gmaxwell: For pettycoin I limited the number of prev blocks in the merkle, naturally limiting the SPV jumps and alleviating this problem. Mainly because pettycoin has a horizon, and I didn't want SPV jumps back arbitrary distance (since you might not know that block header).
03:39:10amiller:i have a nagging point of dissent about the sidechains roadmap: among the presented options for SPV proofs, one of them, the "ratchet" mechanism, is pedagogically much simpler than the others
03:39:13rusty:bramc: in practice I'm guessing sidechains would run using functionaries until they get over "Satoshi's Gap" (i.e. enough mining power to be difficult to exploit). By then, there would be regular emerging, I'd expect.
03:39:41amiller:yet it's apparently fallen out of favor because it is not "scalable", to "millions of sidechains", under some assumptions about transaction volume between those sidechains and bitcoin
03:41:18rusty:amiller: dumb q: where is the "ratchet" mechanism presented?
03:41:21amiller:the alternative involves more moving parts such as interactive fraud challenges/proofs, so i think it's an overoptimization
03:42:34bramc:I still don't know what one might actually want to do with a sidechain, but that's a whole other issue
03:42:35amiller:"If we expect many transfers per sidechain, we can maintain a special output in the parent chain
03:42:35amiller:which tracks the sidechain’s tip. This output is moved by separate SPV proofs (which may be
03:42:35amiller:630 compacted in one of the above ways), with the result that the parent chain is aware of a recent
03:42:35amiller:sidechain’s tip at all times.
03:44:23rusty:bramc: I wanted to do microtransactions. But faster (and less variant) block times are another practical interest.
03:44:49jaekwon_:amiller: what is the ratchet mechanism?
03:45:30rusty:amiller: AFAICT that's an optimization of the above options, and approximated nicely by gmaxwell's sweeping transactions. It's not a self-standing solution.
03:45:33amiller:i just pasted the "ratchet" paragraph from appendix B (the word 'ratchet' isn't actually used, the conversation apparnetly comes from an old forum thread where it was discussed)
03:46:12amiller:rusty, well, it's not
03:46:37jaekwon_:For tendermint that's basically what I plan to do. A special primitive that tracks the blockchain tip of sidechains.
03:46:48petertodd:amiller: "parent chain is aware of a recent sidechain’s tip" <- don't forget the data loss issue; there won't be just one tip
03:47:22jaekwon_:bramc: sharding onto pegged chains, as well as a mechanism for backing coins via an exchange mechanism. tendermint.com/posts/sidechains-without-pegging/
03:47:24bramc:amiller, the stuff in appendix B seems sketchy. You need a huge number of samples to make an attacker unlikely to be able to get a big discount on work, big enough to make it seem implausible that there will be that many samples for quite a long time and just including the whole chain is smaller
03:47:25amiller:petertodd, right, i imagine there will be thousands or tens of thousands
03:47:36petertodd:amiller: no, I mean per sidechain there will be more than one
03:48:01amiller:petertodd, well the tip keeps advancing and old tips can be pruned away
03:48:21amiller:petertodd, creating a side chain would be similar to creating a single utxo, with similar overhead
03:48:54petertodd:amiller: you're still missing my point: from the parent's view a tip is just a link; but you don't have the data behind that link, so the structure allowed has to be a dag
03:49:25petertodd:amiller: otherwise I could advance that tip, never publish the block, and cause problems
03:49:43amiller:petertodd, you could do that with SPV proofs today
03:49:49amiller:against bitcoinj clients
03:50:32petertodd:amiller: yup, and they reorg when they see the longer tip - the consensus rules in the bitcoin blockchain therefore must allow multiple tips to exist for a given sidechain
03:50:58jaekwon_:rippling fork horrors
03:51:03amiller:petertodd, not quite
03:51:15amiller:petertodd, it needs a single tip at any given time, and you can extend that tip with a 'fork' as well
03:51:26petertodd:amiller: it's either that or they allow arbitrarily deep reorgs in the proof that advances that tip
03:51:47amiller:there isn't really anything wrong with allowing arbitrarily deep reorgs
03:52:28petertodd:amiller: no, but like I say, this does mean the notion of the "one" tip is kinda odd - ifit's a rachet where ever block header is put in the bitcoin chain for instance
03:52:32amiller:especially since deep reorgs are exponentially unlikely
03:52:52petertodd:amiller: it's a sidechain - it'll have shitty amounts o fhashing power on occasion, or often - lots of attack scenarios
03:52:53amiller:petertodd, the point is that you don't need to have a UTXO for every sidechain block
03:53:25amiller:anyway, the point is there are two main alternatives for the sidechain spv proof mechanism
03:53:39amiller:one of them involves these 'compressed' SPV proofs that always refer to the genesis
03:54:02amiller:you only need to create these proofs when someone actually withdraws a coin, which it's possible isn't very frequent if people prefer just to stay on the sidechain for a while
03:54:15amiller:however because of variance attacks, it's necessary to do this challenge response thing
03:55:31jaekwon_:any discussions yet on how to handle a pow algorithm hardfork for a sidechain?
03:55:58petertodd:the challenge response to establish if the proof really did represent a highest known total work right?
03:56:30bramc:amiller, that compression has a good asymptotic but very big constant factors, and always has to have some play in it
03:56:58amiller:petertodd, yes roughly
03:57:31petertodd:and your comparing it to a rachet that puts some/all of the sidechain headers in the chain directly, correct?
03:57:36rusty:amiller: you *really* don't want to have to prove back to the genesis each time. Every block header for a mergemined chain is order of 1k...
03:57:38amiller:petertodd, yes
03:57:55bramc:jaekwon_, I think it doesn't
03:58:32amiller:rusty, a proof back n blocks stlll only takes something like log n elments, it uses a skiplist kind of thing
03:58:46bramc:rusty, There's a clever trick which makes that a lot smaller, but I'm complaining that it doesn't really work that well
03:59:02gmaxwell:jaekwon_: it's pretty trivial, you'd handle it like and hardfork generally, sidechain would (according to its own rules) transfer all the coins to a new set of rules.
03:59:30bramc:gmaxwell, Doesn't the opcode for release have to understand the sidechain's proof of work?
03:59:38rusty:bramc: yes, a compact SPV proof.
03:59:38jaekwon_:right ^^
03:59:50gmaxwell:bramc: the proofs we give in the paper are substantially more efficent than the FST sampling proofs you were looking at that paper.
04:00:06petertodd:amiller: so like I say, with a rachet, remember you do need to account for the fact that the blocks associated with some chain may simply not be available - ugly economic attacks there
04:00:27bramc:gmaxwell, Yes but they still aren't all that great, and still have some play
04:00:29rusty:bramc: yes, but a sidechain of a sidechain is possible, hence a stepping-stone sidechain (which understands many different PoWs) is possible.
04:00:37gmaxwell:bramc: and in terms of the expected work they are immediately tight without any sampling at all. (but they have high variance as a side effect of their efficiency)
04:00:49jaekwon_:gmaxwell: i don't see how it's trivial, since as far as the mainchain can see, the old fork still has real bitcoins associated with it and can't know for sure (easily) that there was a hardfork.
04:00:51rusty:amiller: um, isn't that just a compact SPV proof then?
04:01:13jaekwon_:e.g. how does it know that the new sidechain fork is official?
04:01:23rusty:jaekwon_: it has more work?
04:01:27gmaxwell:jaekwon_: it requires the system to decide to move the coins, if some other incompatible system says it's owed the coins, thats called theft. :)
04:01:44jaekwon_:gmaxwell: which system, the mainchain system?
04:01:59gmaxwell:jaekwon_: the sidechain itself the original system.
04:02:42bramc:gmaxwell, Maybe I missed something, but I *think* the compact spv works by taking the root of a a merkle tree of the whole history, and then uses the bits of that root to generate challenges of which leaves have to have the paths to them revealed
04:03:01gmaxwell:jaekwon_: at any transfer the sidechain can change the rules for future validation the coins that come out as change.
04:03:14petertodd:gmaxwell: re: theft, is there any progress on the fact that the 2-way-pegs let miners with sufficinet hashing power steal coins at will?
04:03:32gmaxwell:bramc: No. Thats the fiat shamir transform approach, it's inefficient, and cannot prove a precise amount of work in the expectation.
04:03:46rusty:bramc: there was a good explanation somewhere in the forums when the original idea was proposed. Let me see if I can find it for you...
04:03:58gmaxwell:rusty: you want maaku's post.
04:04:27gmaxwell:bramc: http://sourceforge.net/p/bitcoin/mailman/message/32111357/ (though I think the paper is even more clear than that)
04:05:15rusty:gmaxwell: I was actually thinking of https://bitcointalk.org/index.php?topic=98986.msg1083483#msg1083483
04:05:24petertodd:amiller: note btw how a rachet system with headers published in-chain gives the SPV users much better assurance they're not being sybil attacked
04:05:40petertodd:amiller: same proof-of-publication mechanism behind uniquebits
04:05:43gmaxwell:as far as the commitments go, ... if youre only going back to the genesis, you can use a very small number of commitments. But since the commitments are a hash tree, its stuidly cheap to use all of them and then you can easily jump to any block.
04:06:13gmaxwell:rusty: ah, well thats actually amillers old post which is something different and also cannot prove work in the expectation. (because there is no commitment)
04:06:33amiller:it's trivially modified so you can also get the 'in expectatoin' thing, if you want it
04:06:54amiller:a) "because there's no commitment" has nothing to do with the "in expectation" property, b) the "in expectation" property is kind of useless
04:08:15gmaxwell:amiller: The commitments are absolutely integral to that. In particular, it's essential if you want to use it to compare the difficulty between two honest chains, even absent any attacker at all, and always select the one that has the most cumulative work by the normal single stepping method.
04:08:36gmaxwell:(e.g. to actually instantiate the bitcoin chain selection algorithim)
04:09:21amiller:honest chains commit to their total work count, so it's totally fine to compare honest chains that way
04:10:53amiller:this is a digression, i don't think it matters much
04:11:47amiller:even if you have a *fairly* precise proof about the total amount of work contained in a chain, it still doesn't reduce the variance that an attacker could extend a 1000000 block honest chain just a little bit, like 100 blocks, that's still enough to do a fraudulent spv spend or something
04:11:58amiller:which is why the compact SPV proof isn't enough on its own, you also do the challenge/response thing
04:12:43amiller:so, even with my data structure, or maaku's, or a combination of the two, you're still stuck with needing that interactive challenge/response thing
04:13:01gmaxwell:It's mine, incidentally. Not maaku's.
04:13:37amiller:ok
04:13:58gmaxwell:amiller: depends on what you're considering the threat model. I don't see why you think it's not interesting and important that the expected work to create a fradulent proof is exactly equal to the expected work to create an honest one.
04:14:30gmaxwell:Since thats something of a prereq to making an incentives argument for a greedy/rational attacker.
04:15:38gmaxwell:If nothing else it gives you an assurance against DOS attacks.
04:15:46gmaxwell:wouldn't you agree with at least that?
04:18:07rusty:gmaxwell: I simulated this a while back, and a naive "jump back N when hash < target/N" doesn't give you log(blockheight). It might be O(log(blockheight)), but it's not O(blockheight).
04:19:06gmaxwell:rusty: yea thats a dumb prover. :)
04:19:56rusty:gmaxwell: you're saying jump < N where it results in a shorter path, right?
04:19:56gmaxwell:rusty: the optimal path to genesis can be found in amoritized constant time (really linear time) via dynamic programming.
04:20:59gmaxwell:baslically for every block you keep track of how far from it it takes to get to genesis. then for every new block you consider you consider each path you can reach and take the best path + distance to that path. and that becomes your cost to genesis.
04:21:55amiller:gmaxwell, "exactly equal" isn't a necessity, as long as it's close within some small fraction with high probability
04:22:12amiller:gmaxwell, either way, you can have both properties easily enough
04:22:39gmaxwell:rusty: and thats provably optimal. Though it's only so cheap to compute when you only want a single destination. :)
04:23:14rusty:gmaxwell: indeed. Coding it up now to check :)
04:33:43rusty:gmaxwell: yep, that works.
04:35:25gmaxwell:(FWIW, you suffer from being a noob: I'd mentioned that solution in here a long time back. :) )
04:37:12gmaxwell:One thing I did never solve was good strategies for including commitments to a subset of the blocks. If you're only interested in a path to genesis than immeidately you can eliminate all dominated hops (some earlier path back took you further), but beyond you should old need log() number of candidates to still keep log() behavior overall. But I never figured out an optimal approach for that.
04:37:54gmaxwell:since it's attractive to be able to go anywhere, and since adding more edges is cheap due to the hashtree it didn't seem worth giving it a ton of thought.
04:39:09rusty:gmaxwell: a side question, how do you derive amount of work from that proof? Conservatively, you'd assume worst-case factor of 4 difficulty changes in fortnights you don't know.
04:40:28rusty:gmaxwell: which opens the possibility of a proof with more points demonstrating more work.
04:42:09gmaxwell:rusty: you include it in the commitments, which also limit how far back you can go. e.g. your commitment says there existied a block one back with work 1 back to it, two back with work two back to it.. 2018 back with work 2019.2 back to it (difficulty changed), etc.
04:42:28rusty:gmaxwell: ah, OK.
04:42:29gmaxwell:and you can only skip back in proportion to your own solution lowness.
04:43:08gmaxwell:so claming there was more work in the gap doesn't help you _on average_ since it just makes it more likely you can't skip over your lie.
04:44:34rusty:gmaxwell: I think I like the solution restricting the distance jumped back, and tracing to any previous proof. It's simple.
04:47:57bramc:What is the point of Counterparty?
04:48:37lechuga_:wall st on the blockchain
04:48:44gmaxwell:(1) create speculative asset (2) no step 2 is required. (3) profit ?
04:48:58lechuga_:so yeah
04:49:18bramc:I can't even tell what their technology does from their home page
04:49:35bramc:something about an alternative currency... which crams records into the bitcoin blockchain...
04:49:56gmaxwell:basically it's a competator to mastercoin.. it was announced later, but actually wrote some software earlier.
04:51:22gmaxwell:Both are, IMO, a little inexplicable. but they've been interesting sources of examples of interesting errors that happen when people write non-trivial things using bitcoin.
04:51:52bramc:Yeah, umm... I can't figure out what mastercoin does either
04:52:03bramc:something about using the bitcoin blockchain for communications?
04:53:08gmaxwell:They're basically altcoin systems but skipped the whole creating a p2p network part by packing data into bitcoin transactions. Avoiding systems programming allows innovation like ... the first mastercoin software was written in visual basis. :P
04:53:40gmaxwell:er basic.
04:53:43bramc:gmaxwell, How do they prevent double spending without real integration?
04:54:19gmaxwell:bramc: because your foo coins are also bitcoins (though of as small a value as the network will allow you to transact)
04:55:06bramc:what happens if somebody makes a transaction which mashes together a foo coin and a non-foo coin as inputs?
04:55:17gmaxwell:e.g. you have some 1e-8 bitcoin txout and by convention of your system (gleemed from tracing all its transactions through the bitcoin blockchain history) that 1e-8 btc is worth 100 foocoin.
04:55:50gmaxwell:bramc: system has some rules for dealing with it. I think in the case of mastcoin at least if you don't follow the rules (e.g. including the right goop in your transactions) the coin is just burned.
04:56:20bramc:It's got all the benefits of bitcoin, but proportionately much larger transaction fees?
04:57:48iang_:iang_ is now known as iang
04:58:37gmaxwell:At least some of the benefits, but larger txn, so thus larger fees. Mastercoin's definition previously (I haven't checked later) required every transaction to pay mastercoin's creator some trivial amount. (I guess it still does: see the history on 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P ). And then you also get fun like miners censoring the transactions, because its a competing currency and inefficien
04:58:43gmaxwell:t user of the blockchain space to boot.
04:58:43kanzure:bramc: i don't know about mastercoin, but counterparty does these things: https://github.com/CounterpartyXCP/counterpartyd/tree/224b56eb23824f0ed83c8088741f32664ce26233/lib/messages
04:59:54bramc:kanzure, that's a link to a bunch of source code
05:00:00kanzure:ah wait, how about this:
05:00:00kanzure:https://github.com/CounterpartyXCP/counterpartyd/blob/224b56eb23824f0ed83c8088741f32664ce26233/lib/blocks.py#L52
05:00:10kanzure:of course i'm linking to source code
05:00:14gmaxwell:yea, some of the applications they talk to are the same ones as colored coins, but instead cramming more data into the blockchain and requiring another speculative asset.
05:00:19kanzure:20:49 < bramc> I can't even tell what their technology does from their home page
05:00:25kanzure:in general you should ignore all landing pages
05:00:52bramc:kanzure, even a pitch would be good, as in a high level description of value add
05:01:05kanzure:yeah those are usually fake
05:01:09kanzure:people can just say anything
05:01:13kanzure:source code is what you want to look at
05:02:26bramc:gmaxwell, leading to my inevitable next dumb question, what are colored coins?
05:02:55kanzure:there are many things that have been called colored coins
05:02:57kanzure:some exist more than others
05:03:23gmaxwell:Say you want your soul to be a tradable asset, split into lots of parts. You could launch your own altcoin to track the ownership. But that seems pretty inefficient.
05:03:25op_null:kanzure: I’m not convinced of that really. looking at the bitcoin source is a load more efficient if you actually know what’s going on. a good portion of it is meaningless as to the actual goal and design.
05:03:25kanzure:i believe the original idea of colored coins was about colored satoshis (non-fungibility)
05:03:46kanzure:but now there are various OP_RETURN based things that claim to be colored coins
05:04:12gmaxwell:Instead you say here is a bitcoin It represents 1000 shares of my soul (imagine drawing on a dollar bill). and you define some convention for how the tracking uses the non-fungiblity of bitcoin to flow around through trades.
05:04:26kanzure:(mastercoin, counterparty, openassets, the list goes on) (and chromawallet is more the colored satoshi direction? i haven't read their source code yet)
05:05:51kanzure:oh am i supposed to list sidechains now when people ask about colored coins? i'm worried about the epistemics here.
05:05:59gmaxwell:bramc: which is all well and good; though since the utility of bramc's soul coins is ultimately tied to your willingness to back them ... one might ask the question as to what was actually accomplished here. (it's not completely pointless, since it does take you out of the loop for trading ... but some of the applications people have dreamed up for this stuff is pretty tortured)
05:06:40gmaxwell:kanzure: hm? I don't think so. I certantly don't think of sidechains as colored coins... sidechains don't have any dependency on non-fungiblity, for example.
05:07:53gmaxwell:Though you could use sidechains to address some/most of the applications for colored coins. My impression is that most of the people talking about colored coins, or at least the ones who've been at it the longest, are mostly interested in the result: being able to digitize ownership information about a broader set of assets... the colored coin tracing stuff is just a mechenism.
05:08:07bramc:gmaxwell, if I wanted to create an exchange for bits of my soul where people had confidence that their transfers were happening and only had to worry about me doing eventual redemptions then this sounds like a good idea. But using colored coins for coloring bitcoins or some other completely meaningless currency seems ridiculous
05:08:17grau:gmaxwell: did I miss somaething obvious in my post on burn mining sidechains? I am a bit puzzled of no reaction. I's really appretiate a word.
05:08:41gmaxwell:(CC in bitcoin in the traditional formulation is a little ugly because there is no real way to make a SPV-like client for them, ... not unless we had a covenant functionality in script or explicit support for tracing other kinds of assets)
05:10:13gmaxwell:grau: hah. only 21 hours. I saw your post and though. "Hm Okay this deserves a considered reply, when I have the energy to actually think about it"
05:10:33grau:I am glad. that is enaough for now.
05:10:43grau:thank you
05:12:14gmaxwell:bramc: yes, I agree with you generally. But there is some suspension of disbelief related to "some other completely meaningless currency" in this space because creating 'completely meaningless currency' seems to be one of the most commonly used fundraising mechenisms around.
05:13:11bramc:gmaxwell, To be fair the same applies to bitcoin, but if you're going to do something new it should have some selling point to it beyond what bitcoin does
05:13:43bramc:And most of these things seem to solve 'problems' which aren't actually problems
05:14:21gmaxwell:bramc: In Bitcoin's case it was totally different from anything in existance already. And you get a limited supply 'thing' totally without a central issurer of any kind. This is pretty neat, but ... you only really need one of those. :)
05:14:29bramc:scrypt not being turing complete, for example, is not even vaguely a problem
05:14:47gmaxwell:script (I make that substitution too)
05:15:04bramc:I thought you said scrypt specifically to mean bitcoin script
05:16:10gmaxwell:bramc: yea, so ... I hope you can forgive some of the bad attitude about alt-thing-of-the-day thats powered by the same kind of 'oh come on' as those and other things. (also funny is many of the altthings that have tried to do something technical have emitted swiss cheese that was broken enough that there were no engineering lessons in them, only sociology lessons)
05:17:16gmaxwell:Oh no, bitcoin script is just called Script. scrypt is the memory hard proof of work function created by the tarsnap person (C. Percival), which is used by litecoin in its hashcash.
05:18:14bramc:A good example of not sweating the details: Bitcoin's susceptibility to malleability is very easy to avoid if you're doing things from scratch. Hitting that was an understandable gotcha when bitcoin was first made, but it's well enough understood and simple enough that if you don't fix it in an altcoin you aren't trying to fix any actual problems
05:19:16op_null:as far as I know no altcoin has changed ECDSA signatures in Bitcoin from being DER encoded. low hanging fruit isn't the problem, it's just that fixing little technical quirks doesn't make for a good pump and dump.
05:19:17gmaxwell:(maybe I should say 'used by tenebrix' instead of litecoin)
05:19:57bramc:op_null, you don't even have to fix the encoding, you just have to make the utxos be referenced by transaction instead of transaction + hash
05:20:14bramc:er, transaction + signature I mean
05:20:43op_null:I meant the actual signatures, they are very wasteful in their encoding. they're 71 bytes rather than the ~65 they should be
05:20:50gmaxwell:bramc: maybe not that easy to avoid. For example, "miniblockchain" (another altcoin) advertised immune to malleability on its marketing material ... but it's not. it's a ground up rewrite, but they fixed malleability by basically eliminating the scripting system and having no complex serialization.
05:21:32bramc:gmaxwell, By the way there's been some interesting conversation in ##altcoin-dev which I moved over there to avoid getting on peoples's nerves
05:21:44gmaxwell:(but are still malleable because ECDSA is not a strong signature)
05:22:29bramc:gmaxwell, malleability isn't actually a problem if the transaction itself is fixed
05:23:30gmaxwell:Removing the witness (signature) is adequate. I think thats a fine thing to do. I'm just pointing out someone sought to fix this and card enough to explicitly market it, and still got it wrong.
05:24:02op_null:bramc: what I was trying to get at is that people won't fix all of the little quirks because it's not really all that interesting. there's things that bug technical users like OP_CHECKMULTISIG getting a bit too frisky, but alas.
05:24:58bramc:gmaxwell, I understand the problem well enough to know that I have little confidence in my ability to well and truly remove malleability, which only increases the importance of removing the witness
05:26:12bramc:op_null, That's my point as well
05:26:47gmaxwell:bramc: the only downside I've come up with for this is that sometimes it has semantic or legal significance, so it still makes sense to explicitly commit to a particular value in blocks. (and obviously in the p2p network, if it uses the inv/ask pattern for flooding that bitcoin uses) but yes, I agree its an obvious design choice.
05:27:24bramc:gmaxwell, Yes the block which accepts the transaction should also specify the signature it relied on for the acceptance
05:27:56gmaxwell:(er s/card/cared/)
06:16:16rusty:op_null: re: "no altcoin has changed ECDSA signatures in Bitcoin from being DER encoded." Agreed, but pettycoin did!
06:17:35op_null:I have no idea what that is
06:22:17gmaxwell:A number of things are not DER encoded in fact.
06:22:40rusty:op_null: my sidechain project, before the word sidechain. gmaxwell accused me of making an altcoin, so I'm glad there's now a known term for pegged not-bitcoins.
06:22:48gmaxwell:Miniblockchain isn't (and thought they were malleability immune, nope). IIRC the bytecoin/monero/things are just constant length serializations.
06:23:13gmaxwell:rusty: doesn't help that you called it 'pettycoin' :P
06:23:53op_null:gmaxwell: I sort of meant bitcoin clones, but I guess the mini block chain one fits in there.
06:24:16op_null:if you were re-writing bitcoin from scratch you obviously wouldn't make the same odd design choices
06:24:20gmaxwell:it's not a clone, its a rewrite.
06:24:39op_null:I could have sworn it was a heavy fork of bitcoin
06:24:46gmaxwell:Oh it wasn't _that_ odd, it's what the crypto library gave you. :) "who am I to question the encryption black box?!"
06:26:12rusty:gmaxwell: xyz-coin is almost inescapable as a name. These days I'd got for pettysidecoin or somthing. Hmm, that sucks too...
06:26:42gmaxwell:pettybitcoin
06:27:09bramc:Maybe you could call it threefishcoin
06:27:38bramc:*rimshot*
06:31:01rusty:bramc: I guess that's a reference I wasn't supposed to get... ?
06:33:21bramc:rusty, The pgp team dumped AES in favor of threefish, because they were being petty
06:33:41rusty:bramc: that's... a stretch.
06:33:58bramc:It was really childish
06:35:12rusty:gmaxwell: IMHO pettybitcoin is a moral trademark violation; it kind of implies endorsement.
06:37:51bramc:Maybe I should make a bitbitcoin
06:38:32gmaxwell:rusty: why is it that some people are so easily concerned with such matters, and other people see no problem calling their projects "bitcoin 2.0".
06:40:26rusty:gmaxwell: I always approached bitcoin as an interesting FOSS project. Took me a while to realize that others have different motivations...
08:12:02lclc_bnc:lclc_bnc is now known as lclc
08:58:43lclc:lclc is now known as lclc_bnc
09:05:16rajaniemi.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: andy-logbot Shiftos vdo CoinMuncher davejh69 soundx grau_ damethos Luke-Jr askmike devrandom Dr-G Graftec midnightmagic Grishnakh EasyAt paveljanik op_null coiner TheSeven wallet42 ryanxcharles Starduster jchp dansmith_btc zooko DougieBot5000 eordano hashtag postpre Emcy Flyer33 OneFixt luny ebfull nullbyte Greed xabbix shesek wumpus dgenr8 mkarrer waxwing Baz__ bramc mappum jbenet atgreen btcdrak prodatalab hollandais gues_ nsh gribble
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: zwischenzug HaltingState phantomcircuit gwillen Nightwolf gazab PaulCapestany Tjopper Anduck spinza go1111111 adlai Guest4661 Dyaheon null_radix kyletorpey tacotime samson_ hashtag_ cfields digitalmagus8 c0rw1n stonecoldpat gmaxwell SubCreative [\\\] pigeons ahmed_ copumpkin Transisto isis nuke1989 jgarzik tromp super3 andytoshi lechuga_ bobke coutts CryptOprah artifexd Muis hguux_ michagogo kumavis nickler gavinandresen Hunger-
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: NikolaiToryzin warptangent Fistful_of_Coins heath koshii HM2 paperbot kefkius zibbo maaku epscy lnovy jaekwon_ Cory LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ fenn bosma iambernie mr_burdell nsh_ yoleaux btc__ Graet Logicwax pi07r Meeh DoctorBTC K1773R nanotube kanzure arowser1 berndj lclc_bnc s1w Eliel_ LaptopZZ sneak harrigan JonTitor sl01 sipa Alanius MRL-Relay fluffypony BlueMatt a5m0 AdrianG livegnik BananaLotus
09:05:16rajaniemi.freenode.net:Users on #bitcoin-wizards: @ChanServ burcin wizkid057 bbrittain tromp_ Krellan poggy comboy mmozeiko Taek optimator_ Apocalyptic throughnothing petertodd crescendo so [d__d] espes BigBitz jaromil helo Keefe Iriez huseby phedny BrainOverfl0w warren asoltys harrow roasbeef ryan-c TD-Linux catcow danneu amiller smooth
10:01:08lclc_bnc:lclc_bnc is now known as lclc
11:08:28lclc:lclc is now known as lclc_bnc
11:53:07cbeams_:cbeams_ is now known as cbeams
12:27:07nubbins`:hi
12:53:17lclc_bnc:lclc_bnc is now known as lclc
13:35:38lclc:lclc is now known as lclc_bnc
16:05:43zooko:zooko has left #bitcoin-wizards
16:40:04Luke-Jr:https://www.crowdsupply.com/inverse-path/usb-armory launched FWIW
16:41:33pigeons:thanks Luke-Jr
16:42:36Luke-Jr:(also, there's like 12 left at the "ships as soon as funding reached" level
17:03:21wumpus:Luke-Jr: cool
17:35:25lclc_bnc:lclc_bnc is now known as lclc
17:41:18zooko:gmaxwell: please give me the link to your tutorial about ZK with simple symmetric crypto.
18:00:35Dr-G2:Dr-G2 is now known as BillGates
18:01:05BillGates:BillGates is now known as Guest1675
18:01:17Guest1675:Guest1675 is now known as WarrenBuffet
18:01:55WarrenBuffet:WarrenBuffet is now known as moolah
18:03:08moolah:moolah is now known as Dr-G
18:06:56lclc:lclc is now known as lclc_bnc
18:07:06Dr-G:Dr-G is now known as SteveJobs
18:07:45SteveJobs:SteveJobs is now known as Guest80387
18:08:57Guest80387:Guest80387 is now known as Dr-G
20:25:46super3:is blockstream working on a codebase for sidechains? i'll ive seen publicly is the whitepaper
20:42:04kanzure:super3: this is related https://github.com/Blockstream/contracthashtool
20:42:17super3:yeah saw that already
22:13:36starsoccer:starsoccer is now known as Guest9091
23:30:02bramc:Can anybody explain the opcode extensions proposed for supporting fidelity bonded banking?