| 00:06:55 | petertodd: | nsh, gmaxwell: oh, on debian just do apt-get install statue-of-limitations-calendar |
| 00:07:01 | petertodd: | really useful tool |
| 00:08:23 | nsh: | heh heh :) |
| 01:06:50 | phantomcircuit: | gmaxwell, http://www.bunniestudios.com/blog/?p=3657 |
| 01:07:08 | phantomcircuit: | a while ago you pointed me towards someone who was working on a truly open hardware laptop |
| 01:07:14 | phantomcircuit: | was it this same guy? |
| 01:07:53 | gmaxwell: | yes |
| 01:08:48 | phantomcircuit: | gmaxwell, that looks pretty neat |
| 01:10:03 | phantomcircuit: | gmaxwell, btw https://news.ycombinator.com/item?id=7517296 |
| 01:12:51 | phantomcircuit: | gmaxwell, lol all the people who are complaining about how expensive it is |
| 01:12:53 | phantomcircuit: | hilarious |
| 01:13:29 | petertodd: | phantomcircuit: I'm buying one |
| 01:19:27 | phantomcircuit: | petertodd, any planned use case or just for fun :P |
| 01:19:34 | phantomcircuit: | (or just to support the endeavor) |
| 01:23:59 | petertodd: | phantomcircuit: both - be a good thing to do secure stuff on, e.g. signing software, pgp keys, etc. |
| 01:25:07 | phantomcircuit: | petertodd, yeah |
| 01:25:15 | phantomcircuit: | im interested to see how well the trezor works |
| 01:25:26 | phantomcircuit: | TD's initial review seemed very positive |
| 01:35:59 | petertodd: | after seeing that discussion about that BIP my opinion of the trezor guys has kinda dropped, but we'll see |
| 01:36:27 | petertodd: | at worst it'll at least be another orthogonal systems that I can store coins in to further divide up my risk |
| 01:36:36 | petertodd: | (I preordered a plastic one) |
| 01:37:04 | gmaxwell: | hopefully they get multisig support at some point. :-/ |
| 01:40:14 | petertodd: | hopefully the units they ship can easily have their firmware reprogrammed - but not too easily |
| 01:40:47 | phantomcircuit: | gmaxwell, it feels like taking a cheap android cell phone and physically disabling the wifi would be roughly as effective |
| 01:41:06 | phantomcircuit: | of course you dont get the benefit of a tamper proof chip |
| 01:41:20 | phantomcircuit: | but something tells me the trezor doesn't really have that in any meaningful way |
| 01:41:45 | copumpkin: | any thoughts on http://hardwarewallet.com/? |
| 01:42:30 | phantomcircuit: | copumpkin, there doesn't appear to be any screen |
| 01:42:39 | copumpkin: | oh, must be useless then |
| 01:42:39 | phantomcircuit: | which makes it effectively useless |
| 01:42:40 | copumpkin: | >_> |
| 01:43:12 | shinybro: | shinybro is now known as halflonghalfshor |
| 01:43:26 | phantomcircuit: | copumpkin, thus my thoughts on the android phone |
| 01:43:45 | phantomcircuit: | it has everything you need to make a hw wallet except the tamper proof chip |
| 01:43:55 | halflonghalfshor: | halflonghalfshor is now known as shinybro |
| 01:44:59 | copumpkin: | yeah |
| 01:45:03 | copumpkin: | does trezor support multisig? |
| 01:45:22 | copumpkin: | hmm, doesn't appear to mention it |
| 01:46:05 | phantomcircuit: | copumpkin, no it doesn't but maybe the firmware can be changed to support it later |
| 01:46:12 | phantomcircuit: | it really depends on what the design is |
| 01:46:48 | phantomcircuit: | if they have a generic microcontroller or arm cpu with some small chip that does dump signing then probably yes |
| 01:46:58 | phantomcircuit: | if they implemented it with a bunch of logic on the chip then maybe not |
| 01:47:07 | phantomcircuit: | i would be surprised if it wasn't the first one though |
| 01:47:11 | maaku: | phantomcircuit: a cheap smart phone with wifi + telphany disabled running Android Wallet would be better, about as secure, and cost about the same as Trezor |
| 01:48:00 | maaku: | I've mentioned this to multiple people at every conference & meetup I go to, and I'm surprised it hasn't happened yet |
| 01:48:04 | phantomcircuit: | i suspect the trezor will get much cheaper after they have covered R&D |
| 01:49:02 | phantomcircuit: | maaku, the hard part with that is transmitting messages to the network |
| 01:49:12 | phantomcircuit: | you'd normally use a usb cord |
| 01:49:14 | maaku: | phantomcircuit: NFC & bluetooth |
| 01:49:24 | phantomcircuit: | but the usb stack isn't super secure |
| 01:49:40 | phantomcircuit: | maaku, the entire nfc stack is basically untested security wise |
| 01:49:50 | phantomcircuit: | i would strongly advise against having it enabled |
| 01:50:16 | maaku: | phantomcircuit: have it on a physical switch |
| 01:50:38 | phantomcircuit: | maaku, there needs to be two way communication |
| 01:51:18 | phantomcircuit: | i guess if you used usb and removed effectively all of the usb drivers such that you could only do usb 1.1 and only with raw messaging it would be reasonably safe |
| 01:51:35 | maaku: | phantomcircuit: for PoS apps, you flick a switch and enable local comms and use either USB or bluetooth |
| 01:51:43 | maaku: | for user-to-user, that's what the camera is for |
| 01:52:03 | maaku: | (remember, smartphone) |
| 01:52:12 | maaku: | present a qr code, scan a qr code, etc. |
| 01:52:36 | phantomcircuit: | yeah i guess the bluetooth stack isn't so bad |
| 01:52:41 | phantomcircuit: | (lol not really) |
| 01:52:59 | phantomcircuit: | maaku, i suspect the best course of action would be to pay someone to o a security audit of the linux bluetooth stack |
| 01:53:03 | phantomcircuit: | and then use that |
| 01:53:15 | phantomcircuit: | or i guess nfc because it's all over the place already |
| 01:53:39 | maaku: | phantomcircuit: yes, but that shouldn't stop someone from deploying early beta versions of this |
| 01:53:54 | phantomcircuit: | maaku, hmm i guess that's fair |
| 01:53:56 | maaku: | you could do a preorder, ship an early product, and use revenue from that to clamp down the software stack |
| 01:54:03 | phantomcircuit: | it would be more secure than what everybody is doing now |
| 01:54:24 | maaku: | ideally a 2.0 would have hardware isolation separating the comms and the chips running the bitcoin wallet |
| 01:54:55 | maaku: | but perfect is the enemy of good |
| 01:55:53 | maaku: | getting hardware wallets with at least limited protections widely deployed is better than the situation we have now .. even better if there is a firmware upgrade path to better security |
| 02:03:57 | gmaxwell: | maaku: trezor is based around a $2ish SOC (a pretty spiffy 200mhz arm core) |
| 02:05:05 | Luke-Jr: | maaku: I think BFL's BitSafe is supposed to have 2 CPUs |
| 02:05:11 | gmaxwell: | I think it would be pretty hard to make an android device that was remotely robust against someone with physical access to it. |
| 02:05:30 | Luke-Jr: | if it ever gets released :x |
| 02:06:07 | copumpkin: | the iPhone SOC has some built-in crypto but it's not going to do ECDSA for you |
| 02:06:20 | copumpkin: | and you'll most likely need to jailbreak to even use it |
| 02:06:57 | gmaxwell: | an obvious thing to do is to use a traditional smartcard and the surrounding device is just providing the UI |
| 02:19:04 | maaku: | gmaxwell: I'm not convinced that's the right requirements |
| 02:19:29 | maaku: | there is use for a bitcoin safe - but there is also use for a bitcoin wallet, which is only secure so long as it remains in your posession |
| 02:20:58 | gmaxwell: | maaku: the requirements are partially overlapping due to evil-maid attacks. Also if you want to increase your security against coercion you may need a safe that can enforce policy against _you_. |
| 02:23:22 | gmaxwell: | I don't think they need to be mutually exclusive. e.g. you can use a lower security device as the approval UI but have the keys and policy in tamper resistant hardware. This way an evil maid attack could at worst tamper with the UI and hope you unlock it again before detecting the tampering, and still couldn't override any programmed policy (e.g. time limits on value) |
| 02:23:33 | gmaxwell: | and tamper resistant smart cards are an off the shelf part. |
| 02:24:12 | gmaxwell: | (also having a standardized tamper resistant part inside opens the doors to doing othercoin-style offline transactions) |
| 02:28:03 | petertodd: | gmaxwell: speaking of, othercoin sounds like it's progressing |
| 02:29:44 | adam3us: | was othercoin the one using microsd form-factor tpm's to do offline private key transfer (using remote attestation and hw signed key exchange)? |
| 02:29:51 | gmaxwell: | ah, I hadn't seen any updates on it. |
| 02:29:54 | gmaxwell: | adam3us: yep. |
| 02:30:29 | petertodd: | adam3us: specifically a javacard, which is an open platform (kinda open) |
| 02:30:39 | adam3us: | gmaxwell: all fun and games until the camel gets its nose inside the tpm enforced walled garden :) |
| 02:31:02 | petertodd: | adam3us: camel's actually pretty tasty |
| 02:31:41 | adam3us: | petertodd: should be good for low/moderate value tx tho |
| 02:32:03 | gmaxwell: | yea, I see this as useful for low value stuff. |
| 02:32:12 | gmaxwell: | The coffee shop usecase sort of thing. |
| 02:32:19 | gmaxwell: | <$20 worth or so. |
| 02:32:37 | petertodd: | I mean, hell, I've happily trusted $20 to anonymous instawallets |
| 02:32:42 | gmaxwell: | I hope they picked up some of the suggestions I had (e.g. making it really easy to instantiate a new coin inside the enviroment, so that you can easily refresh your coins to erase the risk of past exposure) |
| 02:32:58 | petertodd: | gmaxwell: yeah, I think they do that |
| 02:33:30 | petertodd: | open to some of my ideas w/ time locks for v2.0, and the guy added a simple pin mechanism for escrow in v1.0 |
| 02:34:09 | gmaxwell: | yea, the ability to create timelocked sweep transactions to secure the chips against loss sounded go to have too. |
| 02:37:00 | adam3us: | does anyone know how chris odom's opentransactions protocol interacts between smart contracts and chaum ecash? it seems so far to me that its kind of tricky to have a public audit function for a blind ecash token (at least in the straightforward sense as they are intentionally unlinkable to the extent that you have to trust the issuer not to inflate coins) |
| 02:38:09 | adam3us: | (he has chaum cash support, and smart-contracts via a pluggable interpreter eg javascript, lua etc).) one general comment someone made was they thought you convert the coins to non-chaum form before using them with a contact, and then use then in bare coin form after receiving proceeds from contracts |
| 02:38:11 | gmaxwell: | I've never been able to get a clear answer on anything with open transactions from FellowTraveler. :-/ |
| 02:38:50 | adam3us: | he doesnt hang out on here i guess. he's quite keen to explain things if you talk to him in person. but the documentation is a bit lacking so far i think |
| 02:38:53 | gmaxwell: | That would be an obvious thing to do for the contract stuff. |
| 02:39:05 | gmaxwell: | He's hung out in #bitcoin and #bitcoin-dev in the past. |
| 02:41:47 | adam3us: | gmaxwell: in the context of a private-chain (which is similar to an opentx tx server) i was thinking it would be nice if you could get blinding based fungibility (and privacy) while providing smart-contracts and the public auditability necessary for the reactive security model. i would think it could work with snarks, but without that it degraded pretty fast to ZKP of set-membership even using brands (eg contract limited to those expressible with br |
| 02:43:28 | gmaxwell: | well I don't think that emerging a blineded coin momentarily for a contract then re-hiding it again actually hurts privacy at all. (of course you don't have privacy for the contract itself, which is bad... but no solution there short of snarks... or something like the rational-actors-assumption protocol Felton's crew were talking about) |
| 02:44:55 | gmaxwell: | the latter is pretty nice. You can think of it as kind of applying the ideas from the how 2-way-peg fraud proofs work to how coinswap hides the real contract. |
| 02:44:58 | adam3us: | gmaxwell: yes. its probably not bad that way (which i think is what opentx is doing). Felten's idea i have my doubts. what happens if a lot of irrational actors create a big mess that then gets exposed and collapses. how would you incentivize or force people to not include nonces in their tx, making them impossible to disprove |
| 02:45:29 | gmaxwell: | adam3us: well if it's a two party exchange then there should always be an interested party who can disprove. |
| 02:45:47 | gmaxwell: | And if not— ... if a coin is stolen in the forrest and there is no one there to hear it, does it make a sound? :) |
| 02:46:23 | adam3us: | gmaxwell: oh so the usual step 1 time lock refund, step 2 multisig, step 3 both parties agree on and sign a contract. |
| 02:46:52 | kanzure: | are there any useful notations in game theory other than graphs, tables, matrixes, charts, or diagrams with giant arrows pointing at giant rectangles? |
| 02:47:03 | gmaxwell: | right well in the two party case you can totally do that. The felton stuff just replaces the multisig with a deposit/challenge/ protocol. |
| 02:47:42 | adam3us: | gmaxwell: do you think that game theory logic could work for committed tx? |
| 02:47:57 | kanzure: | FellowTraveler is in #opentransactions |
| 02:48:01 | gmaxwell: | an interesting middle ground would be to use N of M with oracles as the first step, but then be able to use the challenge protocol if the oracles cheat. |
| 02:48:43 | gmaxwell: | adam3us: hm. the problem there I think is that all parties with knoweldge of the transaction could have an incentive to lie... e.g. I'll happily let you spend a coin that doesn't actually exist. :) |
| 02:52:01 | adam3us: | gmaxwell: so what is felten saying exactly: that if two parties agree on a contract and decide to agree it went in a certain direction without revealing the cntract to the network, then the rest of the network can just let that stand without caring what the contract actually was? |
| 02:52:36 | adam3us: | gmaxwell: (so long as both parties have the opportunity to disprove it if they dont like the attested but unproven outcome) |
| 02:54:01 | adam3us: | gmaxwell: i think wei dai's b-money with smart contracts was envisioned as pseudonymous. so the contracting parties would not directly be protected by blinding either. |
| 02:54:59 | gmaxwell: | Right, doesn't necessarily have to be two parties, however... just all parties who are aware of and care about the contract. Particularly they make an argument for game theoretic security, where to make the initial claim you put up a deposit... that if someone comes along and challenges your claim they can go claim your deposit. |
| 02:55:49 | gmaxwell: | The whole thing with coinswap was really pointing out that in the two party case you can do something stronger to hide the contract. |
| 02:56:08 | gmaxwell: | In any case, if script were sufficiently powerful (tm) you could just do this sort of thing as a function of your contract. |
| 02:56:36 | gmaxwell: | E.g. your contract has two execution paths, one that is the attest/deposit/challenge/etc. path, and another code path (hidden by a hash) with the real contract in it. |
| 02:58:25 | adam3us: | gmaxwell: well coinswap is that you can have a pay b and b pay c in two not obviously related transactions such that a can be sure c will get the funds without needing to trust b? |
| 02:58:49 | adam3us: | gmaxwell: or are you saying something about being able to add more arbitrary contract rules into that picture? |
| 03:00:23 | gmaxwell: | adam3us: In coinswap parties A and B (c really can be a bystander with a acting on their behalf with no real loss of generality) can do a contract— in that case a hash-locked atomic exchange— but hide the contract from the blockchain via multisig. Which is spiffy, but it does require enumerating the participants in the contract in advance. |
| 03:01:21 | gmaxwell: | what I'm saying above is that if script were somewhat more powerful (e.g. had general covenant ability) you could instead do the protocol felton suggests— which lets you not enumerate in advance the people participating in the contract— without any explicit support in the coin. |
| 03:01:57 | sl01: | ~ |
| 03:03:56 | adam3us: | gmaxwell: i suppose the downside with felton's approach is if i lose the contract game, and you are about to collect, i can just falsely assert I won, then DDoS you during the maturity period, and defacto win. is his motivation transaction privacy? or bandwidth to not have to serialize the tx to the network? |
| 03:05:11 | gmaxwell: | right it fails to jamming. The motivation is scaling mostly, I think. Keeping the contract out of the network so you're not expecting a zillion nodes to run the same code. |
| 03:06:19 | adam3us: | gmaxwell: (in coinswap case because there is the threat that if the other party refuses to sign in line with the outcome of the contract, the wronged party can fix it by broadcasting the actual contract tx) |
| 03:07:16 | gmaxwell: | right. |
| 03:07:56 | gmaxwell: | thats the case for the game theoretic thing too... and the deposits should more than cover the required transaction fees to do so. |
| 03:12:01 | adam3us: | gmaxwell: btw the thing you accidentally suggested yesterday (it was actually in reply to someone else on a diff topic) seems to work anyway. if you want an asic to have an owner and only be able to work on blocks signed by its current owner, and yet do not want to implement ecdsa in the asic hw (nor include a small cpu core) |
| 03:13:31 | adam3us: | gmaxwell: then you could just tell the asic the first tx in the block must be a spend to self from a given addr. if the operator does not have that key, they cant make a sig, the miner doesnt check the sig, just the presence of it string wise, but the block will be thereby invalid if the sig is invalid, so the operator cant (usefully) divert the mining policy and needs no ecdsa hw :) |
| 03:20:05 | phantomcircuit: | gmaxwell, i was assuming you were protecting against a device considered 100% lost and against malware |
| 03:20:10 | phantomcircuit: | not against a device being tampered with |
| 03:20:20 | phantomcircuit: | i would be surprised if the trezor was safe against that... |
| 03:21:18 | phantomcircuit: | gmaxwell, implementing a device that's secure against a maid-attack seems complicated/expensive |
| 03:21:28 | gmaxwell: | phantomcircuit: trezor is supposted to be resistant to extracting anything useful after stealing it. I doubt it is. |
| 03:21:36 | phantomcircuit: | gmaxwell, oh |
| 03:21:45 | phantomcircuit: | you can just do FDE w/ android |
| 03:21:50 | phantomcircuit: | only the bootloader is plaintext |
| 03:23:44 | phantomcircuit: | gmaxwell, i recall someone who i cant recall talking about the trezor protocol using some kind of memory mapping |
| 03:23:55 | phantomcircuit: | which isn't unusual with cheap usb controllers |
| 03:24:01 | phantomcircuit: | but i would be surprised if that was secure |
| 03:58:52 | LaptopZZ_: | LaptopZZ_ is now known as LaptopZZ |
| 04:07:01 | super3: | posted some details about storj today if anyone wants to take a look. https://bitcointalk.org/index.php?topic=555159.0 |
| 04:26:46 | CryptoPhox_: | CryptoPhox_ has left #bitcoin-wizards |
| 04:55:39 | maaku: | so do we count BIP-42 as a hard fork? :P |
| 04:56:36 | Luke-Jr: | soft |
| 04:56:43 | Luke-Jr: | nothing hard about it |
| 04:56:55 | maaku: | ah right |
| 04:57:33 | maaku: | * maaku is not thinking clearly tonight |
| 07:30:09 | austinhill: | I'm surprised this wallet on Indiegogo didn't get same attention the Trezor did |
| 07:30:10 | austinhill: | http://www.indiegogo.com/projects/pitbull-wallet |
| 07:34:06 | Ademan: | austinhill: What they showed appeared to be a mockup which was literally a printed card, and as far as I could tell the team did not have the expertise to create such a device, finally, making things that thin is HARD |
| 07:34:10 | Ademan: | especially for so cheap |
| 07:34:27 | Ademan: | inexpensive* target price was iirc $20-30 |
| 07:50:41 | austinhill: | Aderman: Yeah, but would be nice. Also nice to get some TPM hardened devices into the BTC ecosystem |
| 14:38:20 | austinhill: | adam3us & I are going to be hosting a bitcoin core dev & volunteer summit sometime in June. The concept is to provide travel vouchers & facilities to host the people who have contributed to bitcoin open source project (Testers, Code authors, documentation people) and provide a location for them all to meet in person for a number of days (3-4) to collaborate, plan and interact in person. Gmaxwell has said that he thinks it would be very helpful |
| 14:38:43 | austinhill: | We would like help in suggestions on names, possible topics that we should throw on the agenda etc. |
| 15:49:02 | petertodd: | austinhill: $150k would easily be not enough money to implement the hardware for that wallet |
| 15:49:46 | petertodd: | austinhill: scaling and mining incentives |
| 15:50:28 | petertodd: | austinhill: p2pool |
| 15:52:36 | austinhill: | petertodd: I agree, I've priced out a larger budget for a good TPM wallet air-gapped solution |
| 15:53:08 | petertodd: | austinhill: ideally we want a remote attest general purpose thing, where it being a wallet is just one application |
| 15:53:29 | austinhill: | petertodd: agree as well with mining incentives & p2ppool + a few other ideas the wizards & adam3us have come up with to avoid sybil attacks and offset the risks of centralization of hashing power in data centers |
| 15:54:06 | petertodd: | austinhill: I hear that ARM TrustZone has run into the problem that banks have decided it's chaper to buy laws so they don't have to implement security - might be easier to work with those mfgs now that they are looking for a market |
| 15:54:32 | petertodd: | austinhill: get a model where bitcoin scales better and physics will naturally decentralize |
| 15:56:46 | austinhill: | petertodd: the AC & power requirements of ASICs at any decent scale are already moving mining out of residential homes that aren't equipped for power & cooling needs, so the move to data will happen regardless (made worse by cloud hashing companies selling mining bonds at $35/Ghash on the greater fool theory and being able to monopolize the ASIC purchasing supply chain & handle delivery risks better then small miners due to their capital purchasi |
| 15:57:32 | austinhill: | petertodd: so centralization of hashing in data centers is something that will need to be dealt with to avoid multiple future ghash.io's overtaking the rest of the network in hashing capacity |
| 15:59:18 | petertodd: | austinhill: that's simply wrong. individual ASIC chips have low AC & power requirements - cost per hash goes up as scale increases at some point because getting rid of large amounts of heat costs more per joule removed than small |
| 15:59:26 | petertodd: | what you're actually seeing is centralization due to overhead costs |
| 16:02:10 | amiller: | austinhill, if you're worried about the future and centralization, i wonder if you're familiar with the nonoutsourceable and my lottery-affluence hypothesis? |
| 16:02:55 | petertodd: | amiller: +∞ |
| 16:04:11 | amiller: | the nonoutsourceable puzzle* |
| 16:04:26 | austinhill: | petertodd: US homes can't handle ac requirements & power requirements for more then 2 KNC Miners (Neptune) without rewiring - so there will be a necessary move to data centers |
| 16:04:43 | austinhill: | amiller: no, links please? |
| 16:04:55 | amiller: | https://bitcointalk.org/index.php?topic=305781.0 bitcoin as lottery and https://bitcointalk.org/index.php?topic=309073.0 nonoutsourceable puzzle to discourage hosted mining |
| 16:05:18 | austinhill: | amiller: thanks |
| 16:05:30 | petertodd: | austinhill: you're missing my point: runnng 1/2 of a KNC miner will earn >1/2 of the profit modulo overheads, so work to reduce those overheads |
| 16:06:32 | petertodd: | meanwhile internally if you take a KNC miner and divide it up the resulting hardware costs approximately the same at worst, cheaper at best (less effort at cooling) |
| 16:13:03 | jtimon: | I agree with those who think the heat as byproduct will end up being used industrially somehow |
| 16:14:35 | austinhill: | jtimon: I agree, I'm hoping to heat my companies office in the winter with ASIC hash powered heat :) |
| 16:14:36 | jtimon: | the peoples of the world mining while keeping their houses warm is nice, but I think industrial mining is more realistic |
| 16:15:21 | jtimon: | austinhill you may need another industrial use for the summer |
| 16:15:26 | petertodd: | jtimon: the uses for waste heat are *extremely* varied - that's solidly decentralized |
| 16:15:53 | petertodd: | the problem is that the overhead to *mine* rather than *hash* is high, scaling up the blocksize makes it worse, merge mining makes it worse |
| 16:16:18 | jtimon: | petertodd that's good, my point is mining will be an industrial thing |
| 16:16:27 | petertodd: | meanwhile amiller's non-outsourcable puzzle stuf is about the only thing I know of that acts against those incentives |
| 16:16:51 | petertodd: | jtimon: if by "industry" you mean tens of thousands of facilities, that's a huge improvement from the status quo |
| 16:16:52 | jtimon: | I get what you mean by oberheads now: non-hashing mining costs |
| 16:17:12 | jtimon: | s/overheads |
| 16:17:12 | petertodd: | jtimon: exactly - all this talk about hashing being decentralized is irrelevant if mining isn't |
| 16:17:13 | austinhill: | jtimon: industrial & eventually nation states, don't expect governments to start issuing national math based currencies without having large investments in hash rate |
| 16:17:34 | petertodd: | austinhill: please, no government is going to issue PoW based currency |
| 16:17:57 | jtimon: | I agree, private chains make much more sense to them |
| 16:18:12 | austinhill: | petertodd: I disagree - but we'll see how it plays out in the future. |
| 16:18:45 | petertodd: | austinhill: why on earth would they do so vs. adopting a signed blockchain? |
| 16:18:58 | jtimon: | although they could issue in a public chain and then I guess they would want hash rate |
| 16:19:35 | petertodd: | jtimon: yes, they could piggy back and create an embedded consensus system, but the incentive to do so is lacking |
| 16:20:37 | jtimon: | mhmm, private to private 2 way peg... |
| 16:20:40 | jtimon: | let me explain |
| 16:21:11 | jtimon: | an issuer could issue on a public chain and then have 2 way peg with a private chain that'ss not under his control |
| 16:21:23 | austinhill: | Canada is already looking at moving mint chip project to a public blockchain tech - they won't be the first, or last : confidence in national currencies & monetary policy if you assume over time (+7-20yrs) adopting of efficiencies of math based currencies will be based on public blockchains instead of private servers…..if you want to be seen as a stable reserve currency public chains (with private side chains) will be needed |
| 16:21:47 | jtimon: | that way the private chain operator cannot freeze the coins |
| 16:22:12 | petertodd: | austinhill: again, you have failed to explain what's the advantage of PoW consensus vs. trusted signer consensus for these systems |
| 16:22:46 | jtimon: | now I'm thinking that maybe you could have private2private 2way peg if, for example, states, really prefer to issue on their own chain instead of a glbal one |
| 16:22:53 | austinhill: | a discussion for another time Peter :) gotta run to a meeting |
| 16:23:03 | petertodd: | jtimon: a curious iteration of such a system would be one that is designed such that a central bank an easily issue new coins if they wish too |
| 16:23:32 | jtimon: | that's very simple |
| 16:24:12 | jtimon: | in freimarkets you define "issuance tokens" on the asset coinbase that are transferrable and allow new issuance |
| 16:24:25 | maaku: | petertodd: private chain != embedded consensus |
| 16:24:26 | jtimon: | they can do that on a public chain too |
| 16:24:54 | jtimon: | maaku, I think he knows "PoW consensus vs. trusted signer consensus " |
| 16:25:38 | maaku: | jtimon: yes, they could piggy back and create an embedded consensus system... <-- you were talking about trusted signers not mastercoin-like embedded, right? |
| 16:27:14 | jtimon: | well, I'm not sure anymore, by private chains I mean chains where you replace pow with signatures from a trusted party or group |
| 16:27:46 | jtimon: | well, anything that fits in a pubkeyScript |
| 16:28:09 | petertodd: | maaku: w/ an embedded consensus system said government could give up their control to blacklist/freeze funds without giving up their ability to issue more on demand |
| 16:28:42 | petertodd: | jtimon: that's why I specifically referred to "how consensus was achieved" when distinguishing PoW vs trusted signing |
| 16:28:56 | jtimon: | petertodd they can do the same by issuing in a public chain that supports asset issuance |
| 16:29:24 | petertodd: | jtimon: right, a system that supports colored coin validation |
| 16:29:30 | petertodd: | jtimon: e.g. ethereum |
| 16:29:45 | jtimon: | yes, or freimarkets |
| 16:35:18 | jtimon: | mhmm, thinking more about it...I doubt priv2priv 2way peg can work, so it actually may make sense for them to issue on a public chain |
| 16:36:38 | jtimon: | back to the hashing vs validating discussions, yes, I agree, the higher the validation costs the more centralization preassure |
| 16:36:54 | gmaxwell: | I'm bummed to hear mintchip was working on blockchain tech. I wanted it released as it was. :P would have been a major boon to bitcoin until it was cracked (and maybe even after) |
| 16:37:24 | maaku: | is there a citation for that mint chip news? |
| 16:37:52 | gmaxwell: | I'd expect austinhill to know all the good back room rumors. |
| 16:39:32 | petertodd: | jtimon: why wouldn't priv2priv 2way peg work? it's basically a trust arrangement in that case |
| 16:39:47 | antephialtic: | why would a government actually need to use block-chain based tech? If they wanted digital cash, they could just use chaumian ecash |
| 16:39:59 | petertodd: | gmaxwell: "blockchain" could mean a lot of things - just signing a chain is enough |
| 16:40:14 | antephialtic: | if you have a trusted central issuer, what's the point? |
| 16:40:17 | petertodd: | antephialtic: forcing everything to be public, transparency |
| 16:40:37 | petertodd: | antephialtic: what's worse is there's all kinds of underhanded stuff you could do there where the public nature of it is an illusion |
| 16:42:09 | gmaxwell: | well part of the mintchip security model, as I understood it, is that if there were compromises but on a small scale they'd just eat them in the form of inflation. (perhaps they'd be counterbalanced by chips lost) |
| 16:42:35 | petertodd: | yup, if it's a blockchain it's easier and more transparent to see that happening |
| 16:42:57 | petertodd: | and answeres critics re: money laundering possibilities "Look! it's not anonymous at all!" |
| 16:43:21 | gmaxwell: | but that makes it lame: can't use it offline, isn't private like cash. |
| 16:43:29 | maaku: | petertodd: I think the issue is more with unconditional unwinding of pegging mechanisms |
| 16:43:46 | antephialtic: | so, signed blocks (w/o PoW), addresses registered to identity... what's the point. I'd rather use paper money |
| 16:44:00 | petertodd: | gmaxwell: governments like lame, and anyway, you still could use it offline an sync the tx's with the chain later |
| 16:44:08 | antephialtic: | might as well call it BigBrotherCoin |
| 16:44:23 | petertodd: | antephialtic: indeed! but it'll be efficient and fit in the model that governments want |
| 16:44:31 | petertodd: | maaku: ? |
| 16:45:47 | maaku: | petertodd: i'm guessing that's the problem jtimon was thinking of w.r.t. priv2priv pegs |
| 16:50:47 | jtimon: | antephialtic an advantage would be to seamleslly interface with lots of other cryptoassets, p2p or issued |
| 16:51:46 | jtimon: | antephialtic also they don't need to make it KYC (bigbrothercoin), although they could as well |
| 16:52:30 | jtimon: | chaumian cash cannot be traded atomically for anything, not even other chaumian cashes |
| 16:54:24 | jtimon: | petertodd yes, they can have trust arrangements, but not trustless 2way peg like you can have with public2private 2way peg |
| 16:55:21 | petertodd: | can't be traded atomically? why do you think that? |
| 16:55:40 | jtimon: | or put another way, they could have it, but you always need to trust the operator of the original private chain, so it's not very 2way-peg-ish |
| 16:56:12 | petertodd: | fair enough |
| 16:56:49 | petertodd: | anyway, I'm very unconvinced about this 2-way peg stuff given it appears to rely on merge mining in the way people envision it |
| 16:56:55 | jtimon: | petertodd: because you can't, how do you trade 1 A chaumian token for 1 B token? |
| 16:57:35 | jtimon: | petertodd, again it does NOT rely on merged mining you could do 2 way pegging from BTC to litecoin or quark |
| 16:57:53 | jtimon: | it's just that merged mining is the most interesting use case |
| 16:58:32 | petertodd: | jtimon: well you trade a chaumian token by redeeming it, and then doign the redemption in a transaction that's atomic with respect to tokens being exchanged |
| 16:59:36 | jtimon: | but chaumian "cash" transfers cannot be conditional so how do you make one of the transfers conditional to the other? |
| 17:00:03 | jtimon: | OT's answer: you deposit both in the same OT server and trade the credit |
| 17:00:31 | petertodd: | jtimon: sorry, I have three conversations going on at once, I may be missing something, or making an assumption that you aren't |
| 17:01:41 | jtimon: | don't worry, I've saying that about chaumian cash since I studied OT as a potential plattform for implementing distributed ripple |
| 17:02:47 | jtimon: | well in OT is lucre instead of chaum, but similar properties |
| 17:04:44 | antephialtic: | i don't see an obvious way to do it atomically, but you could obviously delegate the transfer to the issuer. both parties encrypt unblinded tokens with issuers pubkey along with transfer instructions signed with their identity keys |
| 17:05:42 | jtimon: | mhmm, are you counting 2 different issuers? |
| 17:05:45 | jedunnigan: | jedunnigan has left #bitcoin-wizards |
| 17:06:23 | antephialtic: | fair point. But with a federated OT or Ripple style system it would work |
| 17:06:36 | jtimon: | anyway, transitive transactions (ripple) require generalization to N issuers and n currencies in the same atomic trade |
| 17:08:46 | jtimon: | I'm not sure, maybe, I doubt it, chaum seems to be alergic to atomic trades ;) |
| 17:09:06 | jtimon: | you mean ripple-consensus by Ripple I guess |
| 17:10:24 | jtimon: | anyway if you find a solution for 2 different assets in the same OT server, probably #opentransactions are all hears |
| 17:10:45 | antephialtic: | cool, I need to read up on the details of OT |
| 17:13:19 | jtimon: | http://opentransactions.org/wiki/index.php?title=FAQ leads you to http://anoncvs.aldigital.co.uk/lucre/ which leads to http://anoncvs.aldigital.co.uk/lucre/theory2.pdf |
| 17:15:26 | gmaxwell: | jtimon: I think the only real advantage of lucre was that it avoided the non-expired chaum patents and it had a flaw that it enabled really easy watermarking by the bank. (I think there is a way to solve that but it was complicated) |
| 17:15:37 | gmaxwell: | er s/non-expired/now-expired/ |
| 17:20:05 | jtimon: | gmaxwell, yes, and chaum is probably easier to understand, but I think OT still uses lucre |
| 17:20:53 | gmaxwell: | well, I think lucre can be easily applied to EC groups, so perhaps it can be made more efficient easily. |
| 17:23:48 | Elriel: | how about the EC Math based blind signature system? I think I saw a paper about such some time ago. |
| 19:49:56 | BCB: | If anyone is concerned about the Fungibility of bitcoin this should be an interesting read. http://digitalcommons.osgoode.yorku.ca/cgi/viewcontent.cgi?article=1847&context=ohlj |
| 20:27:14 | gmaxwell: | hah: http://dilbert.com/2014-04-02/ |
| 20:35:40 | Ademan: | gmaxwell: hrm, someone ought to make dogbertcoin for dumb crypto enthusiasts |
| 20:36:00 | [\\\]: | [\\\] is now known as NARC |
| 20:36:08 | NARC: | NARC is now known as [\\\] |
| 20:38:55 | Emcy: | fungibility really is a silly word isnt it |
| 21:09:20 | Matt_von_Mises: | Sorry, should have posted this here: Have people heard about the KGW "exploit"? It's an exploit similar to the time warp "attack" in that the difficulty can be manipulated downwards. Though at the end of the day no one can fork the chain without doing more calculated "work", so I don't see how it is a fork exploit. It could be used to make 51% attacks worse or for miners to collaborate in bringing the difficulty down and the number of blocks ov |
| 21:09:55 | gmaxwell: | Matt_von_Mises: https://bitcointalk.org/index.php?topic=499767.msg5535636#msg5535636 but also see my prior finger wagging about technobabble. All "KGW" is is an exponential moving average, unfortunately the altcoiners have obfscuated it with a pile of BS and hidden the technical details. |
| 21:10:31 | gmaxwell: | The tradeoff inherent in any moving average filter (which is generally worse the faster the filter is) has been pointed out on bct every time it's come up. |
| 21:17:34 | kanzure: | austinhill: are there any security concerns to having that many core devs in the same location at the same time? e.g. bus factors |
| 21:18:19 | kanzure: | bus factor increases with the square of the average proximity of the contributors... or something. |
| 21:18:22 | Matt_von_Mises: | gmaxwell: Do you think this is a significant issue for altcoins, or under normal network conditions where the majority of the network is behaving is using EMA or EMA like adjustments safe? |
| 21:19:11 | Luke-Jr: | … |
| 21:19:28 | Luke-Jr: | Matt_von_Mises: under normal conditions, YOU DON'T NEED MINERS AT ALL |
| 21:19:55 | kanzure: | oh yeah, that should definitely be in bold in asic-faq.pdf or something like it |
| 21:20:12 | Matt_von_Mises: | Luke-Jr: What do you mean? |
| 21:20:22 | Luke-Jr: | Matt_von_Mises: I mean the ENTIRE PURPOSE of miners is to handle ATTACKS. |
| 21:20:50 | Luke-Jr: | if you pretend there's no attacks, then you don't need them |
| 21:21:46 | midnightmagic: | obfuscating names @!@$!@&# |
| 21:21:55 | gmaxwell: | Matt_von_Mises: basically the tradeoff with the continuious difficulty adjustment reduces security against isolation and partitioning but makes the block rate more stable when the coin is worthless. |
| 21:25:45 | Matt_von_Mises: | Luke-Jr: What I'm trying to say is that "normal conditions" is dependant on miners. If you have 51% of the mining power being used in collusion to effect the network then that isn't normal. Maybe I still don't get what you mean. |
| 21:26:00 | Luke-Jr: | "normal conditions" is NOT dependant on miners |
| 21:26:30 | Luke-Jr: | without attacks, nobody tries to double spend, thus a blockchain is a waste |
| 21:26:42 | gmaxwell: | Matt_von_Mises: luke is pointing out that the structure of bitcoin is all about defending against attacks. 'normally' there are no attacks, but the reason for this is because the attacks don't work. :) |
| 21:27:01 | Matt_von_Mises: | But that wasn't what I meant, but nevermind. |
| 21:27:16 | midnightmagic: | Magic's Window Washing -- what if we take the last 11 blocks of reward and modify the 10-minute block target! |
| 21:27:19 | midnightmagic: | I'm a genius. |
| 21:27:24 | midnightmagic: | * midnightmagic is off to patent the algo |
| 21:28:01 | Matt_von_Mises: | Anyway I better be off. Thanks. |
| 21:28:06 | Matt_von_Mises: | Matt_von_Mises has left #bitcoin-wizards |
| 21:28:06 | gmaxwell: | Matt_von_Mises: it's a tradeoff. it's still a tradeoff even if the majority of miners is honest, because it reduces security against isolation and partitioning (e.g. when a network attacker divides up part of the network; or isolates part and mines at a low rate) |
| 21:28:32 | midnightmagic: | you're welcome |
| 21:30:00 | andytoshi: | kanzure: mining stuff ought to be in alts.pdf, not asic-faq.pdf (which is specifically about modifying the POW). but in either case i don't have the time, cycles or energy to add it now :) |
| 21:30:32 | midnightmagic: | andytoshi: Are you still working on that "what alts have tried and failed at" doc? |
| 21:31:29 | andytoshi: | midnightmagic: for some definition of "still working on", yeah. it is on the back-burner, but at least once a week i'll open it up and imagine typing into it |
| 21:31:59 | kanzure: | wasn't aware of alts.pdf, but i'll promptly steal that file |
| 21:32:28 | andytoshi: | kanzure: https://download.wpsoftware.net/bitcoin/alts.pdf |
| 21:32:51 | andytoshi: | also midnightmagic ^ that's supposed to be the list, but for now it's just patter |
| 21:33:19 | kanzure: | it's curious that double spending gets to be classified as an attack (i certainly agree that it is one) |
| 21:33:25 | kanzure: | but basic use of the system can be easily classified as an attack heh |
| 21:33:31 | kanzure: | s/the system/other systems |
| 21:33:48 | midnightmagic: | andytoshi: A cooperative effort might be an idea. Would a copy&paste into the wiki now that the wiki is marginally more safe from total destruction be out of the question? |
| 21:34:17 | warren: | gmaxwell: apparently "KGW" coins were attacked recently just as expected |
| 21:34:53 | gmaxwell: | warren: no shock, did the attackers do anything interesting? |
| 21:35:11 | warren: | gmaxwell: expected results are expected |
| 21:35:40 | andytoshi: | midnightmagic: if any regular here PM's me i'll give them git push access ... but agreed, wiki would be better |
| 21:35:53 | andytoshi: | i'm happy if some one wants to copy/paste it into there, i don't have access |
| 21:36:11 | midnightmagic: | in either event, just wanted to say thanks for what you've done so far |
| 21:37:44 | andytoshi: | no worries, it's let me cut out tons of repetitive #bitcoin discussions while still giving me a way to procrastinate :) |
| 21:42:44 | Luke-Jr: | andytoshi: any reason not to copy these to the wiki? :P |
| 21:43:25 | andytoshi: | Luke-Jr: nope, i just hadn't thought to do it. anyone is welcome to :) |
| 21:45:40 | Luke-Jr: | andytoshi: do you even have an account? O.o |
| 21:46:17 | shinybro: | shinybro is now known as shinybro_ |
| 21:46:43 | andytoshi: | i don't think so. it's possible i made one in 2011, but i definitely haven't used it since then.. |
| 21:46:53 | Luke-Jr: | XD |
| 21:47:06 | andytoshi: | i wasn't gonna pay 30 damn cents for the priviledge of teaching people! ;) |
| 21:47:19 | Luke-Jr: | so don't pay, just tell us the username :P |
| 21:47:48 | andytoshi: | sure, one sec.. |
| 21:47:50 | gmaxwell: | andytoshi: other people will pay to have the benefit of your contributions. :) |
| 21:49:59 | andytoshi: | :} how flattering. i registered, i'm andytoshi |
| 21:50:34 | Luke-Jr: | nanotube: ping |
| 21:54:47 | nanotube: | Luke-Jr: pong |
| 21:55:06 | nanotube: | oh ok |
| 21:55:07 | nanotube: | just a sec |
| 21:55:32 | nanotube: | done |
| 21:55:37 | Luke-Jr: | thanks |
| 21:55:42 | nanotube: | :) |
| 22:02:58 | jps_: | jps_ is now known as jps |
| 22:08:56 | Luke-Jr: | "elements of the utxo set are called utxos or unsigned transaction outputs. The motivation for these terms will become clear." |
| 22:09:11 | Luke-Jr: | I always took it as unSPENT |
| 22:09:27 | gmaxwell: | where is that from? |
| 22:09:31 | gmaxwell: | yes, it means unspent. |
| 22:09:45 | Luke-Jr: | andytoshi's alt.pdf |
| 22:10:28 | sipa: | yeah, unspent |
| 22:13:10 | Luke-Jr: | andytoshi: after I'm done importing to wiki, do you want corrections by others? :P |
| 22:22:32 | Luke-Jr: | https://en.bitcoin.it/wiki/User:Andytoshi/A_Treatise_on_Altcoins |
| 22:47:01 | Ademan: | "If the output total is strictly greater than the input total, the difference is called a transaction fee and is recaptured by the network." I'm running on no sleep so I might just be off my rocker but isn't that backwards? |
| 22:47:32 | jrmithdobbs: | i believe so |
| 22:47:51 | jrmithdobbs: | should be 'if the input total is strictly greater than the output total' |
| 22:48:24 | jrmithdobbs: | (you're not as crazy as you thought ... this time) |
| 22:48:37 | Ademan: | haha |
| 22:48:38 | sipa: | Ademan: #bitcoin-dev please (and you are right) |
| 22:48:53 | Ademan: | sipa: was referring to Luke-Jr's link |
| 22:49:00 | Ademan: | (above) |
| 22:49:00 | sipa: | oh, nevermind |
| 22:49:04 | jrmithdobbs: | heh |
| 22:49:07 | [Tristan]: | [Tristan] is now known as Guest67709 |
| 23:28:10 | adam3us: | btw some more details on cryptonote (aka bytecoin, the original, not the clone; still unclear if it involves bytecoin the bitcointalk user/crypto guy) https://forum.cryptonote.org/viewtopic.php?f=2&t=18 and cryptonote.org ; the ring sigs end up doing something coinjoin like in effect but maybe more efficient and allowing mixing other peoples coins without their active involvement (you pick who to mix with) |
| 23:28:35 | adam3us: | (dup?) btw some more details on cryptonote (aka bytecoin, the original, not the clone; still unclear if it involves bytecoin the bitcointalk user/crypto guy) https://forum.cryptonote.org/viewtopic.php?f=2&t=18 and cryptonote.org ; the ring sigs end up doing something coinjoin like in effect but maybe more efficient and allowing mixing other peoples coins without their active involvement (you pick who to mix with) |