| 00:00:22 | vetch: | you're limited thermally with that approach, the conductivity of most resins is extremely poor. |
| 00:01:36 | vetch: | gmaxwell: http://www.ecnmag.com/sites/ecnmag.com/files/legacyimages/Figure%203%20copy.jpg < they do exist commercially |
| 00:01:59 | vetch: | ( http://www.ecnmag.com/articles/2012/04/robust-hardware-security-devices-made-possible-laser-direct-structuring ) |
| 00:02:15 | gmaxwell: | in any case, since you seem to find it interesting: here was my notes on the time-oracle stuff: http://0bin.net/paste/PMy9LsmZKsGqn2aA#2gk4A4I7aSezYi24wNaAZe0TMg6bFfxEc6gBOFJXSoU= |
| 00:03:21 | gmaxwell: | vetch: damnit, how did you find that— and so quickly? I spent a bit of time searching for that a while back. I found that they're pretty common inside microchips for things like smartcards... but I couldn't find any macroscale stuff. |
| 00:04:43 | vetch: | beginners luck :) |
| 00:06:19 | gmaxwell: | my thinking is that a common design using COTS parts would enable nutballs like me to build their own and start putting these things into service. |
| 00:06:28 | gmaxwell: | it's really easy to fall into feature creep. |
| 00:06:44 | gmaxwell: | actually this whole time-centered oracle thing fell out of feature creep from some other oracle stuff I was doing. |
| 00:07:50 | vetch: | hm, I think the thermal limit might be an issue for my chuck-it-in-an-acrylic-cube idea. I don't think you can dissipate that much heat through one. |
| 00:08:02 | vetch: | you're talking a lot, lot more intensive than I was expecting |
| 00:08:39 | gmaxwell: | yea, so ... the chip scale atomic clocks are 120mw devices normally now, ... though 20-30mw average in a special power save mode that only turns on the atomic reference periodically. |
| 00:09:40 | gmaxwell: | So thermals is a challenge. |
| 00:11:23 | vetch: | could have a cube of acrylic resin with a central stainless steel or copper tubes leading though to dissipate the heat. you could knit it into tamper proof mesh so it's not a tampering problem. |
| 00:12:12 | gmaxwell: | yea, I wondered if a heat-pipe kind of thing might be viable... though making it be an EMI leakage vector is a challenge then. |
| 00:12:42 | gmaxwell: | and needing beryllium oxide to build it didn't exactly seem user-friendly to me. |
| 00:12:51 | gmaxwell: | or diamond. :P |
| 00:13:55 | vetch: | I'm sure there's ways around that, the heat isn't *that* big of a problem |
| 00:14:41 | gmaxwell: | well they make epoxies for potting electronics which have 'high' thermal conductivity. I expect that 'high' is not very high, but I don't think that the power usage has to be that high. |
| 00:15:41 | vetch: | http://www.epoxies.com/_resources/common/userfiles/file/managing_heat_transfer_potting_compounds.pdf |
| 00:16:00 | gmaxwell: | I think what I'd like to do there could be fit into a 500mw envelope, with the clock... and all the components could be speced to handle 100degC so you'd still get a good delta-t in a unsurvivably hot room. |
| 00:16:25 | vetch: | that has a nice table of the conductivities, the epoxy is actually quite a good conductor of heat considering |
| 00:19:07 | gmaxwell: | (BeO is 265w/m k) |
| 00:20:15 | vetch: | great. lets all use gmaxwell's super secure carcinogenic box :P |
| 00:20:22 | gmaxwell: | (and it's actually cheap enough to consider using for this application, though the dust it emits if you grind or break it is super super super toxic) |
| 00:20:27 | gmaxwell: | yea... :( |
| 00:20:51 | vetch: | well, I suppose that would add to the anti tampering bit. maybe not in the right way though. |
| 00:21:46 | maaku: | vetch: nah, toxic is not transferrable. you just get some homeless guy or 3rd world kid to grind it open |
| 00:22:21 | vetch: | maaku: oh that's grim. we have robots for that. use the robots and the chambers with rubber gloves. |
| 00:22:26 | gmaxwell: | haha well the security doesn't come from it being toxic. :P "warning: contains plutonium" |
| 00:23:10 | maaku: | use U+235, then you also get anti-hoarding properties ;) |
| 00:24:30 | vetch: | gmaxwell: you'd also want to measure the resistance of the hilbert-wire continuously, otherwise somebody could scrape down to that layer and bridge one side to the other, inactivating that portion of the curve. very unlikely, but plausible. |
| 00:24:50 | gmaxwell: | in any case, it doesn't have to be perfect. The users would all use it in an N of M capacity. It just needs to be sufficiently persuasive such that no one will bother trying to coerce its operator. |
| 00:25:08 | gmaxwell: | vetch: actually what you do is send a pseudo random bit pattern into it and compare it. |
| 00:25:16 | gmaxwell: | so changing the length doesn't work. |
| 00:27:45 | vetch: | right. other than that I can't think of a sensible way to break a potted box with a space filling curve detection wire. |
| 00:28:33 | gmaxwell: | right, so next you use a partical accelerator and try glitching it... but adding a photodiode ionizing radiation detector is a cheap thing. |
| 00:28:45 | gmaxwell: | particle* |
| 00:29:33 | vetch: | sounds implausible |
| 00:30:13 | gmaxwell: | actually successful against smartcards! |
| 00:30:16 | vetch: | you could use time dilation to attack the atomic clock, but presumably not a GPS |
| 00:30:57 | maaku: | * maaku wonders if atomicly precise designs exist which are tamper resistant in the face of atomicly precise tools.. |
| 00:31:04 | gmaxwell: | vetch: they can only delay it! same as a dos attack! |
| 00:32:20 | gmaxwell: | vetch: in any case against glitch attacks I mostly propose having a lockstep cpu (two cpus which compare each other) and if it faults it reboots into a self test for a couple minutes, if it faults too many times it zeroizes. |
| 00:32:32 | gmaxwell: | which should generally prevent glitch attacks. |
| 00:33:20 | gmaxwell: | security trackrecord for the IBM cryptocards has been pretty good, and their physical security is wire-in-epoxy... though I don't know how much they've really been attacked, considering they cost about $15k new. |
| 00:33:56 | vetch: | oh, wow I wasn't actually aware that wire-in-epoxy was a thing used by anybody |
| 00:34:42 | gmaxwell: | but I think the security goal for this is lower, it's mostly to protect the operator from coercion or to complicate attacks where you identify the location of a bunch of the clocks and then go capture them. |
| 00:34:44 | vetch: | the tamper detection in POS I've seen in tear downs is usually things like switches and boards you can't help but separate and break a small connector inside |
| 00:35:46 | vetch: | indeed. I doubt we'll see a paper about using time dilation to attack oracles |
| 00:36:49 | gmaxwell: | vetch: http://www-03.ibm.com/security/cryptocards/ < nah, these things are pretty awesome, dual lockstep ppc with crypto accelerators in a epoxy box, with a battery... keys in static ram, tamper zeroizes. The bootloader signs the running code, the bootloader itself is signed by ibm, so you can prove to a third party what code is running on it. |
| 00:37:06 | gmaxwell: | But they're $15k new, and the internal clock isn't good enough for time-oracleish applications. |
| 00:37:53 | gmaxwell: | (it's a non-temp compensated crystal osc, ... good luck keeping it within 2 minutes over a year, and you can attack it by running the card at different temps) |
| 00:38:23 | vetch: | keys in memory just makes me think of old arcade gaming machines, they did the same trick :) |
| 00:38:29 | gmaxwell: | They show up used on ebay cheap-ish from time to time, but it's a bit sketchy buying a used one since if the battery ever failed or if it was taken outside of the allowed temp/pressure it's a brick. |
| 00:38:54 | gmaxwell: | Hal used one of the older models as the basis of his rpow system. |
| 00:40:11 | vetch: | looks like a neat piece of hardware. no doubt expensive because of R&D rather than components |
| 00:40:38 | vetch: | though realistically, for a high security device a chinese knockoff probably isn't the best idea. |
| 00:40:40 | gmaxwell: | yea, nothing too fundimentally expensive about it... sadly they have really seen supermassive adoption. |
| 00:41:43 | gmaxwell: | Right, someone _other_ than IBM probably couldn't make such a thing. In my own anti-tamper thinking I'm mostly trying to address the "okay, sure I think gmaxwell was honest when he set the service up, but what happens if someone puts a gun to his head" (the answer is: I do whatever I can that they want, so I have to precommit to not being able to help them) |
| 00:42:45 | vetch: | the Trezor is sort of interesting in that regard too. anything but the genuine run by the creators is probably fairly suspect. it's attempting to be a high security device on a meagre budget. |
| 00:44:41 | gmaxwell: | yea, the nice thing about oracles is that they're somewhat centeralized so that its reasonable to sink in a few extra hundred dollars in cost to boost the security. |
| 00:44:53 | gmaxwell: | whereas adding $100 in cost to a trezor would be right out. |
| 00:44:59 | vetch: | gmaxwell: that sort of thinking is sort of uncomfortable. given that situation I would much rather not be a player than need some sort of indestructible carcinogenic box. it's easier just to be completely unassociated and live without the fear that I will be gunned down for the contents of an oracle. |
| 00:46:24 | gmaxwell: | vetch: defense in depth. My thinking is that there would be a bunch of these, compromising any small number would be pointless, some would be hidden inside regular servers, accessible only over tor, and unknown in location. And if you someone shows up with guns, you hand them the oracle and say "good luck!" |
| 00:48:40 | andytoshi: | i worry that people with guns won't understand the crypto needed to believe you when you refuse to be helpful |
| 00:49:04 | vetch: | gmaxwell: I don't think that anybody threatening your life to get at an oracle will be capable of understanding that it's guardian can't help. |
| 00:49:23 | gmaxwell: | andytoshi: well, you've hopefully disqualified those people by making the actual operation of the oracle hard to find in the first place. :) |
| 00:50:10 | gmaxwell: | one thing about the tamper resist design is that the person who sets it up and the person who operates it don't have to be the same either. |
| 00:51:02 | gmaxwell: | who knows, I've not heard of anyone going after the authors of powerful crypto tools with weapons anytime recently. |
| 00:51:18 | gmaxwell: | And certantly there are people who think that the authors of software control it completely and forever. |
| 00:51:40 | vetch: | bitcoin is different to other crypto. there's money involved. |
| 00:52:25 | vetch: | I'm not saying it will happen, just that it's a different game to other projects |
| 00:52:45 | gmaxwell: | It's true, but the funny thing is that the alternative to tamper resist oracleish stuff that people actually deploy is centeralized services. |
| 00:54:23 | vetch: | can't argue with you there |
| 00:56:53 | vetch: | presumably the Ethereum folks will want to think more about oracles, if they want to fill their "script for everything!" philosophy. |
| 00:57:39 | gmaxwell: | well amusingly, you must have oracles to do IO in a consensus cryptocurrency... and once you have oracles and are trusting them for IO you might as well use oracles for computation too.. and then all you need in the currency is threshold cryptography. |
| 00:58:14 | gmaxwell: | and you get much better privacy, much better scaling, ... though a reduction in security for cases where you're not totally at the whim of IO. |
| 00:58:28 | vetch: | yes, we're getting back to altcoins implementing flashy things to improve their pump before they dump. |
| 01:00:20 | vetch: | their failure at conceiving a POW is sort of a demonstration of how much thought is going into the whole thing. |
| 01:00:45 | gmaxwell: | part of it is the bitcoin ecosystem's failure to build some of these alternatives. |
| 01:02:15 | gmaxwell: | E.g. people promote alt on things bitcoin itself can do, but there are no interfaces or tools... so the ability is only theoretical. |
| 01:02:45 | vetch: | I personally believe it's just that none of this is sexy enough. I think the idea of an oracle like that is incredible, but it just doesn't sell. you need an IPO, a flashy name, a post explaining how rich it will make everybody who buys in. |
| 01:02:51 | gmaxwell: | or I say for many contract applications (esp anything that needs IO) oracles are better than script ... but there are no oracles, much less any highly trustworthy ones. |
| 01:03:08 | vetch: | if you're not promising that your oracle will make 20% return in a week, it's not worth reading. |
| 01:03:22 | gmaxwell: | well it's sexy to me, and maybe you, but not joe sixpack who is still not quite clear on what the actual reason he shouldn't give his money to mtgox is.... |
| 01:03:28 | gmaxwell: | that too. |
| 01:04:30 | gmaxwell: | I mean, I can tell you how to monetize these things... you pay them bitcoin, they give you chaum tokens that you can redeem for position in a priority queue to use the thing... but of course, now you want people to pay to use the oracle and it was going to be uphill to convince them to use it instead of centeralizing everything even with it being free. :) |
| 01:04:39 | gmaxwell: | but yea, it's not a 20% return in a week. |
| 01:04:57 | gmaxwell: | of course, its not like coinpumps have sustainable returns like that either. |
| 01:05:42 | vetch: | it's sort of unfortunate that dismal failures like Mastercoin still exist. I still don't even understand what the point of it is. any research into it just returns catchphrases. |
| 01:06:21 | vetch: | I mean, it's a complete waste of every bodies time when there's interesting projects get stuffed away in the depths of Bitcointalk. |
| 01:06:26 | gmaxwell: | yea, its actually even hard to be critical about some of it because there is so little substance that it's hard to get past the "but it's all nonsense!" |
| 01:12:34 | Burrito: | I still don't really know what mastercoin is, I've only gotten as far as "platform to make cryptocurrencies based on proof of burn" |
| 01:14:01 | vetch: | as far as I can make out, a bunch of people bloated the UXTO set to buy "master coins", at which the "developer" essentially quit to "spend more time with his family" |
| 01:18:32 | vetch: | Burrito: oh wait no, they didn't burn them, that was another thing. they just paid into the guys address in exchange for "mastercoins" ;) |
| 01:18:51 | Burrito: | That's stupid |
| 01:20:14 | vetch: | Burrito: 5000BTC, 1000BTC unspent. |
| 01:20:47 | Burrito: | Jesus Christ |
| 01:20:51 | Burrito: | He could do so much with that. |
| 01:22:33 | vetch: | that's actually an accurate curse for once. he seems to have called his idea the second satoshi whitepaper, and the address is a reference to the second book of the Christian bible (exodus). |
| 01:23:12 | Burrito: | Not sure if arrogance or stupidity |
| 01:25:17 | vetch: | I haven't read enough about it to be sure. the impression seems to be the former though. |
| 02:52:45 | dexX7: | vetch: actually only 15 % of those 5000 were spent and the rest was moved to cold storage / board members. re: utxo -- msc multisig outputs are redeemable and about 2/3 of all were already redeemed. |
| 10:55:47 | adam3us: | maaku: "use U+235, then you also get anti-hoarding properties ;)" ha an analogy for freicoin.. u dont want to hoard it because it decays. (and u-235 physical embodiment comes with teeth - u get radiation sickness:) and actually u235 is a rare and expensive element, in the line of stupid analogies gold (bitcoin: correct if was first and there can only be one first), silver (litecoin), oil (ethereum), u235 (freicoin) LOL |
| 11:44:20 | vetch: | adam3us: ethereum is oil, as in snake oil? |
| 12:21:13 | cbeams: | andytoshi, any chance the logs for this room could be stripped of join/quit messages? They create quite a bit of noise, making it hard to catch up. |
| 12:21:45 | Luke-Jr: | grep? |
| 12:23:56 | cbeams: | Luke-Jr: just looking for parity with the logs in the bitcoin-dev room, really. It's simple there to just open up a browser and scan through. Not so easy with -wizards logs, though. |
| 12:28:27 | andytoshi: | cbeams: thx, your opinion has added weight to the pressure i feel to do that |
| 12:30:31 | andytoshi: | i think i want to go whole-hog and convert it all to HTML, would not be much more work than just stripping join/part, i just need to take the time to do it |
| 12:30:56 | cbeams: | andytoshi: perhaps just follow suit with whatever approach is being used to log -dev now? |
| 12:31:28 | vetch: | andytoshi: why not ask the bitcoinstats guy to log it / throw you a copy of his software? |
| 13:54:11 | jgarzik: | jgarzik is now known as home_jg |
| 14:08:54 | [\\\]: | [\\\] is now known as rg |
| 14:08:58 | rg: | rg is now known as [\\\] |
| 14:44:55 | phrackage_: | phrackage_ is now known as phrackage |
| 15:11:19 | maaku: | andytoshi: there has got to be a script somewhere to do that |
| 18:47:49 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 19:08:07 | zzyzx: | zzyzx is now known as roidster |
| 19:08:42 | roidster: | roidster is now known as Guest45875 |
| 19:16:58 | jtimon: | so I propose "compact proof of ownership" as challenge of the day |
| 19:17:54 | jtimon: | adam3us recommends me to google ross anderson and guy fawkes |
| 19:20:05 | adam3us: | jtimon: its a kind of hash based signature related to lamport signatures. starts "underlying idea came to us on the 4th November 1996 while discussing how |
| 19:20:05 | adam3us: | a modern day Guy Fawkes, about to blow up the Houses of Parliament, could |
| 19:20:05 | adam3us: | arrange publicity for his cause - but without getting caught" |
| 19:21:29 | jtimon: | background: this is important for: |
| 19:21:30 | jtimon: | 1) unileteral redemptions on public-private 2 way peg |
| 19:21:30 | jtimon: | 2) it could by chance improve the SPV status of main-side 2 way peg |
| 19:21:30 | jtimon: | 3) petertodd's set of proposals depending on client-only validation and proof of publication |
| 19:23:08 | jtimon: | adam3us sounds like the ingredients we need for this spell, googling and reading... |
| 19:23:56 | jtimon: | but maybe we should start on the minimum we could do without magic |
| 19:25:10 | adam3us: | jtimon: previous discussion suggest this is easier to do between side-chain and private-chain that are format aware, because a peg from side-chain to main, main would like not have to know anything at all about side-chain formats. it is for the side-chain to produce a prescribed return-proof |
| 19:25:18 | jtimon: | you could have a pruned tree from all coinbases to the current output |
| 19:26:01 | jtimon: | yes, but we mostly explored the main-side details |
| 19:26:35 | jtimon: | maybe paying too much attention to current main-side limitations |
| 19:27:19 | jtimon: | by exploring side-private in more detail we may found changes that we really want on main to make this better |
| 19:27:38 | adam3us: | jtimon: if it was possible to do unilateral side to main return without requiring main to understand side formats, that would be a bonus |
| 19:30:01 | jtimon: | yes |
| 19:31:35 | gmaxwell: | lamport signatures are easily guyfawkes ifyably. |
| 19:31:44 | gmaxwell: | encode the signature such that you can prune it later. (e.g. signature hash in the transaction itself) |
| 19:31:51 | gmaxwell: | and then use— say— the next block's hash to decide which of the lamport preimages you keep long term. |
| 19:31:59 | gmaxwell: | also works reasonably nicely for other hash based signatures. |
| 19:32:30 | jtimon: | but this time the bonus would be for the sidechain not having to understand particular private constructs, which gives us more liberty because the sidecahin scripting language is not defined |
| 19:33:22 | jtimon: | I know you gmaxwell ave been thinking about multisig script prunning |
| 19:33:49 | jtimon: | which should apply to all scripting prunning |
| 19:34:57 | adam3us: | jtimon: what about if the side-chain as well as whatever bitcoin-alien script/logic it has, maintains in parallel atomically for the user sufficient information to unilaterally return the coin in the bitcoin main prescribed format? |
| 19:35:18 | jtimon: | that was one requirement maaku asked for on #concatenative : that the abstract syntax tree should be merkized and prunable |
| 19:36:20 | jtimon: | adam3us I'm just saying we can think about later and see how far we can get with joyscript |
| 19:36:47 | jtimon: | we can come back to reality later |
| 19:37:05 | jtimon: | it's just a thought exercise |
| 19:37:35 | adam3us: | jtimon: i am not sure i see the connection with a given script lang? do u mean if u had that script deployed in bitcoin main via p2sh2 soft-fork? |
| 19:38:45 | jtimon: | in the side chain, you have something like OP_FULL_PROOF_OF_OWNERSHIP_FROM_BLOCK_X |
| 19:38:47 | adam3us: | jtimon: istm that the principle should work (if it can be shown to work) for any script lang capable of consuming the return proofs |
| 19:39:51 | jtimon: | so the inputs to that operator are blocks headers, transactions and merkle tree links |
| 19:41:38 | jtimon: | since it would return true/false we ideally would always be in the softfork realm I'm just proposing not to focus on current bitcoin structures since this is, just side-private |
| 19:42:46 | jtimon: | I mean, ignore the current limitations if we can, not redesign everything, we still talk inputs outputs tx and blocks |
| 19:42:51 | wallet42: | wallet42 is now known as Guest13653 |
| 19:42:51 | wallet421: | wallet421 is now known as wallet42 |
| 19:43:17 | jtimon: | but we could have commited anything on the sidechain |
| 19:44:15 | adam3us: | jtimon: maybe recap how the private to side-chain unliteral return works. |
| 19:44:17 | jtimon: | and of course I-sign-anything on the private chain (that's effectively a 100% hashing attack on main-side) |
| 19:45:04 | adam3us: | jtimon: even tho the private-chain may trivially refuse to sign a withdraw, the user can send a self-signed withdrawal. it is up to the private-chain to track the side-chain and disprove any unilateral withdrawals during their maturity period |
| 19:45:13 | tacotime: | Was there a discussion of Bytecoin privacy features here recently? |
| 19:45:28 | adam3us: | tacotime: a little. you mean cryptonote right? |
| 19:45:34 | tacotime: | Yeah. |
| 19:45:58 | adam3us: | tacotime: (there being 2 bytecoins + bitcointalk:bytecoin user who i still havent figured out if he's related to cryptonote) |
| 19:46:35 | jtimon: | adam3us "a self-signed withdrawal" means a "compact proof of ownership" from the older block on the peg-pool |
| 19:46:38 | adam3us: | tacotime: i think its quite cool. linkable EC schnorr based ring sigs between equal denominated coins, and standardized coin sizes |
| 19:47:17 | tacotime: | Yeah, the ring signatures portion I didn't totally understand (how it related to privacy). |
| 19:47:30 | tacotime: | I probably just need to read up on it more. |
| 19:48:13 | adam3us: | tacotime: so 3 steps. bitcoin multisig. then compact multiparty sig (eg ec schnorr can do those), then ring sig is like a 1 of n multi-sig where you the signer can chose who the other claimed possible signers are |
| 19:48:19 | jtimon: | tacotime adam3us any link on cryptonote that will save us from googling? |
| 19:48:32 | adam3us: | jtimon: cryptonote.org i think |
| 19:49:30 | adam3us: | tacotime: its been around for a while, i have no idea why no ones heard of it. drowned out by stupid alts maybe. also the name clash from teh later bytecoin that is a dump alt afaik but hadnt hearrd of bytecoin the original |
| 19:50:56 | tacotime: | Whitepaper for CryptoNotes/ByteCoin: https://bytecoin.org/whitepaper.pdf |
| 19:51:33 | tacotime: | adam3us: Okay, interesting. |
| 19:51:37 | adam3us: | tacotime: ring-sig is of size linear with the n from the 1 of n. but its indistinguishable who signed it. so thats where the privacy comes from. but to prevent double-spending they intentionally make it linkable (each time you sign a parameter I is published that would be the same everytime) so if you are A and do a ringsig with B,C then another one |
| 19:52:16 | adam3us: | tacotime: with C,D it'll still come out with the same I value. and so they just prevent reusing I, and then you can chose your anon-set as you wish withoverlappign random fake possible signers |
| 19:52:20 | jtimon: | thank you, we depend too much on dns-like identities, I've been thinking more about maaku's and mine "freiname" design and I think it should be mostly useless: identities should be cheap and ugly and people should just reject addresses in favor of I-don't-read-just-click/press-myfavourite's-editor-favourite'skey-links |
| 19:52:42 | jtimon: | then only your own program can cheat you |
| 19:53:09 | tacotime: | That sounds pretty elegant. |
| 19:53:35 | tacotime: | It's a shame it was 80% darknet-elite distributed for the past two years. :P |
| 19:53:37 | adam3us: | jtimon: isnt that a rejection of zooko's triangle? |
| 19:54:00 | adam3us: | tacotime: yeah they seem to be low profile maybe. perhaps they are trying to good job of being anon. |
| 19:54:31 | adam3us: | tacotime: i think there are some threads on bitcointalk, but i only stumbled across it last month or so. its been around for several years as u said |
| 19:55:25 | jtimon: | so I've ended up convinced that namecoin is actually better than freiname, they just should name it certificatecoin because names there are useless |
| 19:55:44 | jtimon: | maybe I'm rejecting zookos triangle, I don't know |
| 19:55:56 | adam3us: | jtimon: could u elaboate why u say namecoins are useless? |
| 19:56:07 | jtimon: | I still don't see what's wrong with private namespaces |
| 19:56:42 | adam3us: | jtimon: btw i was thinking if it makes sense it might be interesting to put a namespace on a side-chain so u can pay for them in bitcoin |
| 19:57:03 | jtimon: | adam3us not namecoins, just namecoins names, in the sense that is too sensible to squatting, but certificates don't care about squatting |
| 19:57:34 | jtimon: | adam3us in freimarkets you can have private namespaces with unique tokens |
| 19:58:04 | jtimon: | freiname was trying to appliy free-land/georgism to names |
| 19:58:09 | adam3us: | jtimon: private namespaces = pet names? http://www.skyhunter.com/marcs/petnames/IntroPetNames.html |
| 19:59:00 | jtimon: | for each issued asset, you have a full private namespace of unqieu toekns bitstrings |
| 19:59:27 | adam3us: | jtimon: as i recall petnames argues that u dont worry about global, i just learn of tacotime via an introduction from jtimon so i know him as jtimon->tacotime (the tacotime that jtimon intro'ed me too, with sigs & certs, WoT style) |
| 20:00:24 | adam3us: | jtimon: and jtimon aso doesnt need to be unique, its just a label in my address book for a key i received somehow. everything is relative and defined by introducer |
| 20:00:31 | jtimon: | reading petname...sounds interesting |
| 20:01:08 | adam3us: | jtimon: but whats the scope of a freimarkets name? i just my own namespace and then i own everything in it? |
| 20:01:58 | jtimon: | issue != own |
| 20:02:21 | jtimon: | you issue all the unique tokens for that asset, but you can transfer them |
| 20:02:48 | adam3us: | jtimon: SDSI by rivest is another related key as principal model http://people.csail.mit.edu/rivest/sdsi10.html (pronounced "sudsy" |
| 20:04:13 | jtimon: | thanks again for the links |
| 20:04:26 | jtimon: | there's also gnunet I think |
| 20:05:27 | jtimon: | anyway, that's about names, I'd like to go back to the private-side withdrawal |
| 20:06:09 | jtimon: | you first deposited on the private chain, with a deposit transaction on the sidechain |
| 20:07:38 | jtimon: | now you want to withdraw and you do it directly on the sidechain since you have a 1000% attack on the private chain (if you assume the private chain is always trying to screw you) |
| 20:08:30 | jtimon: | we could treat any orphan block on the private chain as cheating, although I'm not sure how that helps |
| 20:09:43 | jtimon: | I guess we don't have to consider double-spends or the longer chain here is the highest blockheight? |
| 20:11:30 | jtimon: | maybe I shouldn't have talked about magic, we may need to know private-side 2-way peg in more functional detail first |
| 20:11:58 | home_jg: | home_jg is now known as jgarzik |
| 20:12:43 | adam3us: | jtimon: recap again "even tho the private-chain may trivially refuse to sign a withdraw, the user can send a self-signed withdrawal. it is up to the private-chain to track the side-chain and disprove any unilateral withdrawals during their maturity period" |
| 20:15:31 | adam3us: | jtimon: so long as each coin to be considered valid includes a parent chain prescribed return-claim, it is up to the child-chain to follow the parent-chain and speak up during the maturity period to block fraud attempts. i think thats it. and that could work on main as it seems not particularly more complex or different from main's perspective than child-chain approved return |
| 20:20:44 | jtimon: | yeah, I think that's where I was trying to go |
| 20:22:21 | jtimon: | and now, if the accountant accepts more than one withdraw attempts, what would happen? |
| 20:22:32 | jtimon: | which one is the more legit one? |
| 20:27:16 | adam3us: | jtimon: the first in time-stamp order. (as the child-chain is time-stamped in the parent chain) |
| 20:31:32 | adam3us: | jtimon: this is good, because it avoids needing a redundant side-chain just to add format awareness to consume unilateral returns. should help petertodds justifiable fear of centralization in general. centralization somewhat countered via unilateral return |
| 20:32:51 | adam3us: | petertodd: jtimon: then main chain could reduce its blocksize or redirect pressure for large blocks to a side-chain secure in the knowledge that users are not at risk fro the centralization because for the few tx it happens to they can unilaterally move them back. which also acts as a threat against centralization policy exercise: if its ineffective why do it |
| 20:36:44 | jtimon: | mhmm, are we trusting clocks? who's clock? |
| 20:37:03 | roasbeef: | '" |
| 20:37:04 | roasbeef: | ''''''''' |
| 20:37:54 | adam3us: | jtimon: bitcoin order (local time to the chain returning to) |
| 20:39:40 | jtimon: | ok, just wanted to remember you have a 100% attack on the private chain clock |
| 20:40:41 | adam3us: | jtimon: yes. fortunately in this case it is the hashed-chain that decides rather than the signed. (or the main vs the side) |
| 20:41:11 | adam3us: | jtimon: ie it is the chain you are resorting to to unfreeze/fore transact your coin |
| 20:42:23 | jtimon: | so after the last sidechain commitement, 3 transactions want to withdraw the same funds, which one does get it? maybe none (meaning either one and peope should wait for confirmations) |
| 20:43:20 | jtimon: | sorry, going to somke, but I think I know the problem I want ot think about now... |
| 20:50:06 | jtimon: | I think the only conclusion is that a private chain can always abuse a dob-spend |
| 20:50:40 | jtimon: | because he's the master of time in the private chain |
| 21:00:01 | hanncx: | hanncx has left #bitcoin-wizards |
| 21:19:28 | adam3us: | jtimon: right he has to own a coin before he can double-spend it, and that is an attack with a victim, and detectable via the auditors of the chain, at which point all the users unliaterally remove their coins and switch to a new private-chain server |
| 21:19:53 | gmaxwell: | perhaps of interest here: |
| 21:19:54 | gmaxwell: | 14:05 < espringe> Hey guys, I just released a service to help revert unconfirmed transactions |
| 21:19:57 | gmaxwell: | 14:06 < espringe> www.bitundo.com |
| 21:20:58 | Apocalyptic: | gmaxwell, do you see this as a threat ? |
| 21:21:23 | jtimon: | interesting, does it work by paying higher fees and hoping that miners get smarter? |
| 21:22:00 | gmaxwell: | Apocalyptic: I think I (and others) considered it would be inevitable that eventually miners would prioritize most profitable (with perhaps some indiffernece to small profits)... didn't expect someone to try to make a service out of it, that seems odd. |
| 21:23:08 | gmaxwell: | * gmaxwell now waits for a bitundoundo that has miners run a fast sharechain to decide what transactions they won't undo, and block-punishes the main chain if it violates. |
| 21:23:33 | adam3us: | jtimon: also i was thinking this is a single server, there is no consensus convergence window, just a signed block. it wouldnt cost much to verify there is only one tx with that input in the block (if it is stored in a trie like the utxo commitments proposal). then double-spend is not possible if the user waits for the main-chain time-stamp convergence. short-term they are exposed to multiple blocks. kind of analog of 0-conf |
| 21:23:58 | jtimon: | interestingly enough, payer/recipient can set a contract in which it would be irrational for any of them no to collaborate, enabling 0-conf payments |
| 21:26:23 | Guest45875: | Guest45875 is now known as roidster |
| 21:26:32 | adam3us: | jtimon: amusingly that comment is apropos for either discussion thread gmaxwell on bitundo or the private chain thread |
| 21:29:40 | jtimon: | the web doesn't seem very informative |
| 21:30:07 | gmaxwell: | he apparently intends merchants to use some API of his to tell him not-fraud. |
| 21:30:51 | jtimon: | I'm not a miner, am I supposed to join their pool to know how it works (after reading that section)? |
| 21:31:33 | shesek: | "by including a transaction that would conflict with it (aka having a conflicting input)." |
| 21:31:56 | shesek: | they seem to really want to avoid using the phrase "double spend", which is the standard way of describing that |
| 21:32:06 | shesek: | probably because it has some negative associations |
| 21:32:41 | jtimon: | gmaxwell: I think I wouldn't worry about fraud if I knew that the only person that has a direct incentive to cheat me can only do so by spending twice what he could gain |
| 21:33:17 | jtimon: | shesek moral associations shouldn't be an impediment to science |
| 21:33:51 | jtimon: | obstacle |
| 21:35:57 | jtimon: | I'm not sure if bitundo is what I think it is, but if they're helping miners to get the higher fees desite time watermarks, bravo |
| 21:36:35 | jtimon: | miners should get the higher fees, period |
| 21:36:42 | jtimon: | no seq |
| 21:37:08 | jtimon: | miners are the sequencing |
| 21:41:06 | shesek: | its that that simple... its quite dangerous to do this until a. clients are aware of that and know to react appropriately to double spends (send everything to fees) and b. all miners implement child pay for parent (for a to work) |
| 21:41:13 | shesek: | otherwise double spends are super trivial |
| 21:41:23 | shesek: | * its not that simple |
| 21:42:41 | jtimon: | good summary, it's the future but maybe not the present |
| 21:43:48 | jtimon: | maybe the same could be said about "market balanced tx fees" |
| 21:44:01 | jtimon: | and actually I think this is easier |
| 21:44:47 | jtimon: | it's mostly about miner's policies, kind of a softfork without touching the protocol |
| 21:45:41 | jtimon: | once you know most miners are being smart, you can start doing interesting game-theory contracts |
| 21:46:57 | jtimon: | like "trust me, It would be terribly stupid to even try it, mathematically proven, you could steal me if I try" |
| 21:48:08 | jtimon: | basically the payer puts some collateral at stage, but "he knows" he's not going to try to cheat himself for a bigger sum |
| 21:48:33 | jtimon: | s/at stake |
| 21:53:03 | adam3us: | jtimon: seems to somewhat destroy best effort 0-conf security which is a (weak) part of the protocol and full-node/miner defined validation |
| 21:55:09 | jtimon: | how's 0-conf weak? you could have pre-signed the stuff in advance if you're in a hurry, maybe to a low-trust 3rd party |
| 21:55:56 | jtimon: | if you're paying big amounts you should never trust short times, period |
| 21:56:39 | jtimon: | serously, who can't wait 3 hours to sell a house? |
| 21:57:24 | gmaxwell: | jtimon: not every transaction is buying a house. :P |
| 21:58:25 | gmaxwell: | my expirence in doing some escrows for friends doing digital currency trades is that pratically everyone takes irreversable actions with zero-conf today, even with tens of bitcoins involved... but ::shrugs:: thats really not all that viable. |
| 21:59:15 | gmaxwell: | if this service gains any non-trivial hashpower I assume we'll need to change the reference client behavior to be the economically rational one. |
| 21:59:50 | jtimon: | gmaxwell: that's why you can say "I bet you 4 loafs of bread that I won't try to cheat you 2 loafs of bread" |
| 22:00:27 | jtimon: | I think they shouldn't be a pool |
| 22:00:38 | jtimon: | just a policy provider |
| 22:01:03 | gmaxwell: | jtimon: this guy is trying to collect 10% off every 'undo', it's a make money fast scheme for him. |
| 22:01:10 | gmaxwell: | Which is why its implemented in a kind of lame way. |
| 22:01:31 | jtimon: | I mean the 2 days miners need to find out they can do it on their own |
| 22:02:30 | jtimon: | the policy is good the conditions for the customer, I agree, don't look good |
| 22:03:32 | jtimon: | (honeslty, I can't find any data on their page, like at all, not even claims) |
| 22:03:54 | shesek: | I think that its very good for a service like this to exists and be out in the open, to help educate people about the safety of zero confirmation transactions |
| 22:04:18 | jtimon: | sorry, I see, they only reverse it if they mine the block? |
| 22:04:40 | jtimon: | shesek +1 |
| 22:04:56 | gmaxwell: | yea, its a mining pool with a gimmic that they run a policy that is greedy and encourages people to pay them to attempt to reverse transactions. |
| 22:05:39 | jtimon: | but I really mean it, once we rely on selfish miners we can have good standard low-risk-fast payment protocols |
| 22:05:46 | shesek: | people will start doing that eventually - its better to be in the open rather than on some underground forums or something. |
| 22:06:14 | jtimon: | down with seq, up with fee++ |
| 22:07:00 | jtimon: | it's just like asics, it is something good, you should encourage it |
| 22:07:51 | jtimon: | "fee++: bitcoin tx sequencing protocol, pay your higher fees NOW!" |
| 22:07:52 | gmaxwell: | You don't need to convince me, basically I was able to buy _both_ arguments, the argument that greedy behavior is inevitable and enables some good security measures, and that the protective behavior is also helpful— that today the income difference won't be enough to matter, and it improves security for things not using fancy protocols or incentive schemes but instead just using bitcoin in the simplest way possible. |
| 22:08:27 | gmaxwell: | so my thinking on this would be that we'd do the latter as long as we could get away with it, and the former once someone broke rank or when enough developed of tools for that case made it a no brainer. |
| 22:13:36 | jtimon: | mhmm, I think I got your point, correct my translation if it's wrong: |
| 22:13:36 | jtimon: | miners are receiving gold subsidy now and we want them to compete for copper fees that won't work, I know we willl eventually run out of air and will have to hear copper, which I've tasted, but nobody will like nowadays" is that an accurate description of your opinion on higher-fees-first mining policy? |
| 22:14:51 | jtimon: | uff, so many gramatical mistakes... |
| 22:16:03 | gmaxwell: | yes, today they're not competing for fees, they're nearly irrelevant. So if being 'altruistic' and abandoning some higher fees makes bitcoin work better for some people, it's a good long term strategy for miners. |
| 22:16:38 | gmaxwell: | ... until some non-trivial miner breaks rank, in which case 0conf without special techniques is not safe, and there is no altruism benefit, you're just throwing away (small amounts) of fee income. |
| 22:17:50 | sipa: | or in other words: as soon as someone starts competing for fees, they are is reason why you wouldn't join im |
| 22:17:56 | phantomcircuit: | gmaxwell, just have pools publish shares with difficulty = network difficulty / 600 |
| 22:18:15 | phantomcircuit: | magic now you can see which transaction pools are mining with a resolution of 1 second relatively cheaply |
| 22:19:12 | phantomcircuit: | it seems odd to me that that isn't being done now actually |
| 22:19:42 | gmaxwell: | phantomcircuit: it's called p2pool. |
| 22:19:54 | gmaxwell: | phantomcircuit: yes, I suggested to gavin that if he thought we should be interested in lowering bitcoins block time that instead we should just softfork in a p2pool like sharechain that exposes transactions and gives you faster soft confirmation. |
| 22:20:01 | phantomcircuit: | gmaxwell, p2pool is a *bit* more than that :P |
| 22:21:22 | gmaxwell: | phantomcircuit: right, but it does that as a side effect. |
| 22:22:36 | gmaxwell: | there are three many things you can do in that space: use the chain to manage subsidy (what p2pool does), use the chain to manage transactions (fast confirmation), use the chain to just expose activity (fast measurement). |
| 22:24:48 | vetch: | gmaxwell: that might actually be a use case for an alt coin for once. |
| 22:25:11 | vetch: | alt coin as a "testing ground" I mean. |
| 22:25:31 | sipa: | no need for an altcoin, p2pool does it already for bitcoin |
| 22:26:01 | gmaxwell: | p2pool only forces the subsidy today, but the same mechnism could instead force transactions.. e.g. to get you fast confirmation. |
| 22:26:18 | gmaxwell: | The nice thing is that it doesn't bloat the history or spv clients who don't care about the fast confirm reports. |
| 22:26:37 | vetch: | wouldn't the whole network *have* to use the new mining system? |
| 22:26:53 | jtimon: | I think I disagree, they're competing for the variable 0.0001%of the reward, so what? still all the deposits will bemultiples of the instant-bought product |
| 22:26:55 | vetch: | otherwise you'd have the "p2pool" confirming transactions, and a pool whisking all of that sub-work away |
| 22:26:58 | phantomcircuit: | vetch, no but your fast confirmation would only be for the fraction using the p2pool chain |
| 22:27:03 | gmaxwell: | vetch: if you wanted it to be fast confirmation then it would be a softforking change, e.g. compatible but unsafe until a supermajority of the network deployed it. |
| 22:27:25 | vetch: | phantomcircuit: gmaxwell: got it. |
| 22:28:27 | jtimon: | if you want to instant-pay without big insurance-deposits there's a way, it's called mututal credit and it depends (not a limitation, in this case a feature): trust |
| 22:28:40 | gmaxwell: | If do both and some kind of subsidy constraint (doesn't have to work like p2pool does) and the whole network deploys it then it is very nearly the same as reducing the network block time but with better (more flexible) scalablity behavior. |
| 22:29:28 | vetch: | gmaxwell: I really, really like that as a concept. |
| 22:29:38 | vetch: | how realistic would it be to see as a future soft fork? |
| 22:30:10 | gmaxwell: | I dunno, gavin had mused about decreasing the interblock time as something intersting in a hardfork and my responses was that this soft fork idea was probably superior. |
| 22:31:19 | jtimon: | I don't know what you mean by "do both and some kind of subsidy constraint" |
| 22:31:20 | vetch: | it has clear benefits for everybody, so I don't see why it's users wouldn't become the supermajority |
| 22:32:07 | sipa: | just decreasing tje interblock time seems crazy |
| 22:32:31 | vetch: | with a p2pool-like thing you get to both reduce the block size AND not have to store the blocks |
| 22:32:43 | vetch: | best of both worlds. |
| 22:33:44 | phantomcircuit: | sipa, that would end very very poorly |
| 22:33:45 | phantomcircuit: | :/ |
| 22:33:47 | jtimon: | actually, I was very convinced on lowring times to days or weeks on the "root chain" whatever that means, I think that was gmawell and Luke-Jr |
| 22:33:56 | gmaxwell: | jtimon: both enforce that successive shares have all the same transactions as their ancestors (plus potentially more), and require that they pay subsidy according to the prior shares. |
| 22:34:26 | vetch: | a super-block a day would have interesting consequences. you'd have huge merle trees. |
| 22:34:35 | gmaxwell: | yea, I don't think decreasing interblock time alone makes a lot of sense.. but providing a mechenism for fast (if weaker) confirmation could be pretty prudent. |
| 22:35:27 | jtimon: | mhmm, I see, protocol-enforcing rational mining fee policy, very intersting |
| 22:35:54 | vetch: | eventually if it's users became a superiority you could enforce it ala p2sh |
| 22:35:54 | gmaxwell: | vetch: yea there is a logical conclusion where you're sort of all working on an infinite difficulty block to be finished in infinite time.... and accumulating progress along the way. |
| 22:36:44 | vetch: | gmaxwell: not too dissimilar to what we are doing today |
| 22:36:59 | jtimon: | and seq-advocates get an explicit seq that cannot be more cheated that plain anyone-can-write seq |
| 22:37:54 | gmaxwell: | jtimon: yes. |
| 22:38:04 | gmaxwell: | well, 'is costly to cheat' you should still reorg. |
| 22:38:07 | jtimon: | vetch maybe what we're dooing today is not bad |
| 22:39:49 | vetch: | jtimon: the idea of sub-blocks is basically what alt coins are crudely doing. we can objectively say that "fastcoins" block period of 12 seconds is stupid for storage and SPV purposes. this implementation of sub-blocks allows faster confirmations without the bloat. |
| 22:40:24 | gmaxwell: | vetch: it's not quite so simple though because you do start making latency problems for miners.. |
| 22:40:40 | gmaxwell: | e.g. at some point you create a consolidation benefit and preclude mining on tor. |
| 22:43:24 | vetch: | gmaxwell: as we discussed before though, Tor isn't that bad. as long as you didn't have 1 second block times you'd probably be alright. p2pool manages currently with 30 second block times. |
| 22:43:40 | gmaxwell: | yea, 'at some point' |
| 22:44:10 | gmaxwell: | p2pool actually doesn't have to send quite as much data because it doesn't have to verify transactions in losing shares... so it's not quite 1:1 |
| 22:45:48 | jtimon: | I think it souhld be all the compressed power-of-2 difficulty tree, miners validate whatever they want and also include without validating whatever they want, my prediction (different from petertodd's): most in-chain validated transactions will pay substantial but flat fees, most publicly-sequenced-but-not-validated transactions won't be powed (will be just private server signed, maybe by multiple private servers) |
| 22:46:21 | vetch: | jtimon: if you don't validate what you put in a block you risk your whole block being useless |
| 22:47:01 | gmaxwell: | jtimon: makes mostly secure stateless validation of transactions basically impossible. You can't speak to what the network thinks. |
| 22:47:12 | gmaxwell: | vetch: part of the assumption there is you don't require validity. |
| 22:47:27 | jtimon: | no, vetch, this is data meaningless for the protocol, only validated on the client |
| 22:47:32 | gmaxwell: | you can produce a working system that way, but I don't think the properties are a good tradeoff. |
| 22:47:51 | vetch: | right. |
| 22:47:59 | gmaxwell: | vetch: basically someone gives you a coin and you have to inspect its (likely exponential in size!) history to decide if it is valid.. the blockchain just provides timestamps. |
| 22:48:37 | gmaxwell: | and maybe you wave your hands at some recursive snark and say that there is a way to compress the history with computational soundness. |
| 22:49:15 | gmaxwell: | I think without that actually being pratical the idea isn't so hot. |
| 22:49:37 | jtimon: | it's just like timestamping, but the argument is that by paying the pow fees you're ensuring many people got the msg, because, you know, there's so many people subscribed to bitcoin's blockchain, than say, centralized impure forex... |
| 22:51:37 | jtimon: | the more hashing power you through into a channel, the more subscribers you get, isn't it? |
| 22:52:02 | jtimon: | throw |
| 23:01:15 | jtimon: | why would I listen to my local market where I could buy food to eat today if there's an obscure market far away that can ensure me the provably-fair best price simultaneously and atomically on the markets: frc/btc, btc/eur, eur/cny, cny/regionEur, regionEur/localTimeBankHRS, HRS/Beers ? |
| 23:02:21 | jtimon: | all those pairs, at so called "fair price" |
| 23:03:44 | jtimon: | I though Nietsche made clear that "fair" was the most rotten word in the history of communication protocols |
| 23:07:16 | Apocalyptic: | *Nietzsche please |
| 23:08:29 | jtimon: | yep, sorry |
| 23:14:12 | stqism: | stqism is now known as Guest94419 |
| 23:14:24 | jtimon: | well, sorry in general for getting so philosophical, but I reallly feel the word "fair" does not apply in this context, let the client decide what's fair, you can't promise him full vision and, more importantly, the seller won't pay for a full-vision adversing (assuming the most non-validating-pow would somehow cause more viwers for your binding advertisement) |
| 23:15:04 | jtimon: | s/viewers |
| 23:17:26 | warren: | http://www.bitundo.com/ ... |
| 23:20:55 | vetch: | warren: there's some back scroll in #bitcoin about that. |
| 23:21:06 | stqism_away: | stqism_away is now known as stqism |
| 23:21:13 | vetch: | keyword "espringe" |
| 23:27:26 | rdymac-: | rdymac- is now known as rdymac |