00:06:55petertodd:nsh, gmaxwell: oh, on debian just do apt-get install statue-of-limitations-calendar
00:07:01petertodd:really useful tool
00:08:23nsh:heh heh :)
01:06:50phantomcircuit:gmaxwell, http://www.bunniestudios.com/blog/?p=3657
01:07:08phantomcircuit:a while ago you pointed me towards someone who was working on a truly open hardware laptop
01:07:14phantomcircuit:was it this same guy?
01:08:48phantomcircuit:gmaxwell, that looks pretty neat
01:10:03phantomcircuit:gmaxwell, btw https://news.ycombinator.com/item?id=7517296
01:12:51phantomcircuit:gmaxwell, lol all the people who are complaining about how expensive it is
01:13:29petertodd:phantomcircuit: I'm buying one
01:19:27phantomcircuit:petertodd, any planned use case or just for fun :P
01:19:34phantomcircuit:(or just to support the endeavor)
01:23:59petertodd:phantomcircuit: both - be a good thing to do secure stuff on, e.g. signing software, pgp keys, etc.
01:25:07phantomcircuit:petertodd, yeah
01:25:15phantomcircuit:im interested to see how well the trezor works
01:25:26phantomcircuit:TD's initial review seemed very positive
01:35:59petertodd:after seeing that discussion about that BIP my opinion of the trezor guys has kinda dropped, but we'll see
01:36:27petertodd:at worst it'll at least be another orthogonal systems that I can store coins in to further divide up my risk
01:36:36petertodd:(I preordered a plastic one)
01:37:04gmaxwell:hopefully they get multisig support at some point. :-/
01:40:14petertodd:hopefully the units they ship can easily have their firmware reprogrammed - but not too easily
01:40:47phantomcircuit:gmaxwell, it feels like taking a cheap android cell phone and physically disabling the wifi would be roughly as effective
01:41:06phantomcircuit:of course you dont get the benefit of a tamper proof chip
01:41:20phantomcircuit:but something tells me the trezor doesn't really have that in any meaningful way
01:41:45copumpkin:any thoughts on http://hardwarewallet.com/?
01:42:30phantomcircuit:copumpkin, there doesn't appear to be any screen
01:42:39copumpkin:oh, must be useless then
01:42:39phantomcircuit:which makes it effectively useless
01:43:12shinybro:shinybro is now known as halflonghalfshor
01:43:26phantomcircuit:copumpkin, thus my thoughts on the android phone
01:43:45phantomcircuit:it has everything you need to make a hw wallet except the tamper proof chip
01:43:55halflonghalfshor:halflonghalfshor is now known as shinybro
01:45:03copumpkin:does trezor support multisig?
01:45:22copumpkin:hmm, doesn't appear to mention it
01:46:05phantomcircuit:copumpkin, no it doesn't but maybe the firmware can be changed to support it later
01:46:12phantomcircuit:it really depends on what the design is
01:46:48phantomcircuit:if they have a generic microcontroller or arm cpu with some small chip that does dump signing then probably yes
01:46:58phantomcircuit:if they implemented it with a bunch of logic on the chip then maybe not
01:47:07phantomcircuit:i would be surprised if it wasn't the first one though
01:47:11maaku: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:00maaku: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:04phantomcircuit:i suspect the trezor will get much cheaper after they have covered R&D
01:49:02phantomcircuit:maaku, the hard part with that is transmitting messages to the network
01:49:12phantomcircuit:you'd normally use a usb cord
01:49:14maaku:phantomcircuit: NFC & bluetooth
01:49:24phantomcircuit:but the usb stack isn't super secure
01:49:40phantomcircuit:maaku, the entire nfc stack is basically untested security wise
01:49:50phantomcircuit:i would strongly advise against having it enabled
01:50:16maaku:phantomcircuit: have it on a physical switch
01:50:38phantomcircuit:maaku, there needs to be two way communication
01:51:18phantomcircuit: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:35maaku:phantomcircuit: for PoS apps, you flick a switch and enable local comms and use either USB or bluetooth
01:51:43maaku:for user-to-user, that's what the camera is for
01:52:03maaku:(remember, smartphone)
01:52:12maaku:present a qr code, scan a qr code, etc.
01:52:36phantomcircuit:yeah i guess the bluetooth stack isn't so bad
01:52:41phantomcircuit:(lol not really)
01:52:59phantomcircuit: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:03phantomcircuit:and then use that
01:53:15phantomcircuit:or i guess nfc because it's all over the place already
01:53:39maaku:phantomcircuit: yes, but that shouldn't stop someone from deploying early beta versions of this
01:53:54phantomcircuit:maaku, hmm i guess that's fair
01:53:56maaku:you could do a preorder, ship an early product, and use revenue from that to clamp down the software stack
01:54:03phantomcircuit:it would be more secure than what everybody is doing now
01:54:24maaku:ideally a 2.0 would have hardware isolation separating the comms and the chips running the bitcoin wallet
01:54:55maaku:but perfect is the enemy of good
01:55:53maaku: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:57gmaxwell:maaku: trezor is based around a $2ish SOC (a pretty spiffy 200mhz arm core)
02:05:05Luke-Jr:maaku: I think BFL's BitSafe is supposed to have 2 CPUs
02:05:11gmaxwell: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:30Luke-Jr:if it ever gets released :x
02:06:07copumpkin:the iPhone SOC has some built-in crypto but it's not going to do ECDSA for you
02:06:20copumpkin:and you'll most likely need to jailbreak to even use it
02:06:57gmaxwell:an obvious thing to do is to use a traditional smartcard and the surrounding device is just providing the UI
02:19:04maaku:gmaxwell: I'm not convinced that's the right requirements
02:19:29maaku: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:58gmaxwell: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:22gmaxwell: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:33gmaxwell:and tamper resistant smart cards are an off the shelf part.
02:24:12gmaxwell:(also having a standardized tamper resistant part inside opens the doors to doing othercoin-style offline transactions)
02:28:03petertodd:gmaxwell: speaking of, othercoin sounds like it's progressing
02:29:44adam3us: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:51gmaxwell:ah, I hadn't seen any updates on it.
02:29:54gmaxwell:adam3us: yep.
02:30:29petertodd:adam3us: specifically a javacard, which is an open platform (kinda open)
02:30:39adam3us:gmaxwell: all fun and games until the camel gets its nose inside the tpm enforced walled garden :)
02:31:02petertodd:adam3us: camel's actually pretty tasty
02:31:41adam3us:petertodd: should be good for low/moderate value tx tho
02:32:03gmaxwell:yea, I see this as useful for low value stuff.
02:32:12gmaxwell:The coffee shop usecase sort of thing.
02:32:19gmaxwell:<$20 worth or so.
02:32:37petertodd:I mean, hell, I've happily trusted $20 to anonymous instawallets
02:32:42gmaxwell: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:58petertodd:gmaxwell: yeah, I think they do that
02:33:30petertodd: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:09gmaxwell:yea, the ability to create timelocked sweep transactions to secure the chips against loss sounded go to have too.
02:37:00adam3us: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:09adam3us:(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:11gmaxwell:I've never been able to get a clear answer on anything with open transactions from FellowTraveler. :-/
02:38:50adam3us: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:53gmaxwell:That would be an obvious thing to do for the contract stuff.
02:39:05gmaxwell:He's hung out in #bitcoin and #bitcoin-dev in the past.
02:41:47adam3us: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:28gmaxwell: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:55gmaxwell: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:58adam3us: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:29gmaxwell:adam3us: well if it's a two party exchange then there should always be an interested party who can disprove.
02:45:47gmaxwell: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:23adam3us: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:52kanzure: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:03gmaxwell: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:42adam3us:gmaxwell: do you think that game theory logic could work for committed tx?
02:47:57kanzure:FellowTraveler is in #opentransactions
02:48:01gmaxwell: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:43gmaxwell: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:01adam3us: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:36adam3us:gmaxwell: (so long as both parties have the opportunity to disprove it if they dont like the attested but unproven outcome)
02:54:01adam3us: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:59gmaxwell: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:49gmaxwell: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:08gmaxwell: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:36gmaxwell: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:25adam3us: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:49adam3us:gmaxwell: or are you saying something about being able to add more arbitrary contract rules into that picture?
03:00:23gmaxwell: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:21gmaxwell: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:03:56adam3us: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:11gmaxwell: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:19adam3us: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:56gmaxwell: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:01adam3us: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:31adam3us: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:05phantomcircuit:gmaxwell, i was assuming you were protecting against a device considered 100% lost and against malware
03:20:10phantomcircuit:not against a device being tampered with
03:20:20phantomcircuit:i would be surprised if the trezor was safe against that...
03:21:18phantomcircuit:gmaxwell, implementing a device that's secure against a maid-attack seems complicated/expensive
03:21:28gmaxwell:phantomcircuit: trezor is supposted to be resistant to extracting anything useful after stealing it. I doubt it is.
03:21:36phantomcircuit:gmaxwell, oh
03:21:45phantomcircuit:you can just do FDE w/ android
03:21:50phantomcircuit:only the bootloader is plaintext
03:23:44phantomcircuit:gmaxwell, i recall someone who i cant recall talking about the trezor protocol using some kind of memory mapping
03:23:55phantomcircuit:which isn't unusual with cheap usb controllers
03:24:01phantomcircuit:but i would be surprised if that was secure
03:58:52LaptopZZ_:LaptopZZ_ is now known as LaptopZZ
04:07:01super3:posted some details about storj today if anyone wants to take a look. https://bitcointalk.org/index.php?topic=555159.0
04:26:46CryptoPhox_:CryptoPhox_ has left #bitcoin-wizards
04:55:39maaku:so do we count BIP-42 as a hard fork? :P
04:56:43Luke-Jr:nothing hard about it
04:56:55maaku:ah right
04:57:33maaku:* maaku is not thinking clearly tonight
07:30:09austinhill:I'm surprised this wallet on Indiegogo didn't get same attention the Trezor did
07:34:06Ademan: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:10Ademan:especially for so cheap
07:34:27Ademan:inexpensive* target price was iirc $20-30
07:50:41austinhill:Aderman: Yeah, but would be nice. Also nice to get some TPM hardened devices into the BTC ecosystem
14:38:20austinhill: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:43austinhill:We would like help in suggestions on names, possible topics that we should throw on the agenda etc.
15:49:02petertodd:austinhill: $150k would easily be not enough money to implement the hardware for that wallet
15:49:46petertodd:austinhill: scaling and mining incentives
15:50:28petertodd:austinhill: p2pool
15:52:36austinhill:petertodd: I agree, I've priced out a larger budget for a good TPM wallet air-gapped solution
15:53:08petertodd:austinhill: ideally we want a remote attest general purpose thing, where it being a wallet is just one application
15:53:29austinhill: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:06petertodd: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:32petertodd:austinhill: get a model where bitcoin scales better and physics will naturally decentralize
15:56:46austinhill: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:32austinhill: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:18petertodd: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:26petertodd:what you're actually seeing is centralization due to overhead costs
16:02:10amiller: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:55petertodd:amiller: +∞
16:04:11amiller:the nonoutsourceable puzzle*
16:04:26austinhill: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:43austinhill:amiller: no, links please?
16:04:55amiller: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:18austinhill:amiller: thanks
16:05:30petertodd: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:32petertodd: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:03jtimon:I agree with those who think the heat as byproduct will end up being used industrially somehow
16:14:35austinhill:jtimon: I agree, I'm hoping to heat my companies office in the winter with ASIC hash powered heat :)
16:14:36jtimon:the peoples of the world mining while keeping their houses warm is nice, but I think industrial mining is more realistic
16:15:21jtimon:austinhill you may need another industrial use for the summer
16:15:26petertodd:jtimon: the uses for waste heat are *extremely* varied - that's solidly decentralized
16:15:53petertodd: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:18jtimon:petertodd that's good, my point is mining will be an industrial thing
16:16:27petertodd:meanwhile amiller's non-outsourcable puzzle stuf is about the only thing I know of that acts against those incentives
16:16:51petertodd:jtimon: if by "industry" you mean tens of thousands of facilities, that's a huge improvement from the status quo
16:16:52jtimon:I get what you mean by oberheads now: non-hashing mining costs
16:17:12petertodd:jtimon: exactly - all this talk about hashing being decentralized is irrelevant if mining isn't
16:17:13austinhill: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:34petertodd:austinhill: please, no government is going to issue PoW based currency
16:17:57jtimon:I agree, private chains make much more sense to them
16:18:12austinhill:petertodd: I disagree - but we'll see how it plays out in the future.
16:18:45petertodd:austinhill: why on earth would they do so vs. adopting a signed blockchain?
16:18:58jtimon:although they could issue in a public chain and then I guess they would want hash rate
16:19:35petertodd:jtimon: yes, they could piggy back and create an embedded consensus system, but the incentive to do so is lacking
16:20:37jtimon:mhmm, private to private 2 way peg...
16:20:40jtimon:let me explain
16:21:11jtimon: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:23austinhill: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:47jtimon:that way the private chain operator cannot freeze the coins
16:22:12petertodd:austinhill: again, you have failed to explain what's the advantage of PoW consensus vs. trusted signer consensus for these systems
16:22:46jtimon: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:53austinhill:a discussion for another time Peter :) gotta run to a meeting
16:23:03petertodd: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:32jtimon:that's very simple
16:24:12jtimon:in freimarkets you define "issuance tokens" on the asset coinbase that are transferrable and allow new issuance
16:24:25maaku:petertodd: private chain != embedded consensus
16:24:26jtimon:they can do that on a public chain too
16:24:54jtimon:maaku, I think he knows "PoW consensus vs. trusted signer consensus "
16:25:38maaku: 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:14jtimon: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:46jtimon:well, anything that fits in a pubkeyScript
16:28:09petertodd: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:42petertodd:jtimon: that's why I specifically referred to "how consensus was achieved" when distinguishing PoW vs trusted signing
16:28:56jtimon:petertodd they can do the same by issuing in a public chain that supports asset issuance
16:29:24petertodd:jtimon: right, a system that supports colored coin validation
16:29:30petertodd:jtimon: e.g. ethereum
16:29:45jtimon:yes, or freimarkets
16:35:18jtimon: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:38jtimon:back to the hashing vs validating discussions, yes, I agree, the higher the validation costs the more centralization preassure
16:36:54gmaxwell: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:24maaku:is there a citation for that mint chip news?
16:37:52gmaxwell:I'd expect austinhill to know all the good back room rumors.
16:39:32petertodd:jtimon: why wouldn't priv2priv 2way peg work? it's basically a trust arrangement in that case
16:39:47antephialtic: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:59petertodd:gmaxwell: "blockchain" could mean a lot of things - just signing a chain is enough
16:40:14antephialtic:if you have a trusted central issuer, what's the point?
16:40:17petertodd:antephialtic: forcing everything to be public, transparency
16:40:37petertodd: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:09gmaxwell: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:35petertodd:yup, if it's a blockchain it's easier and more transparent to see that happening
16:42:57petertodd:and answeres critics re: money laundering possibilities "Look! it's not anonymous at all!"
16:43:21gmaxwell:but that makes it lame: can't use it offline, isn't private like cash.
16:43:29maaku:petertodd: I think the issue is more with unconditional unwinding of pegging mechanisms
16:43:46antephialtic:so, signed blocks (w/o PoW), addresses registered to identity... what's the point. I'd rather use paper money
16:44:00petertodd:gmaxwell: governments like lame, and anyway, you still could use it offline an sync the tx's with the chain later
16:44:08antephialtic:might as well call it BigBrotherCoin
16:44:23petertodd:antephialtic: indeed! but it'll be efficient and fit in the model that governments want
16:44:31petertodd:maaku: ?
16:45:47maaku:petertodd: i'm guessing that's the problem jtimon was thinking of w.r.t. priv2priv pegs
16:50:47jtimon:antephialtic an advantage would be to seamleslly interface with lots of other cryptoassets, p2p or issued
16:51:46jtimon:antephialtic also they don't need to make it KYC (bigbrothercoin), although they could as well
16:52:30jtimon:chaumian cash cannot be traded atomically for anything, not even other chaumian cashes
16:54:24jtimon:petertodd yes, they can have trust arrangements, but not trustless 2way peg like you can have with public2private 2way peg
16:55:21petertodd:can't be traded atomically? why do you think that?
16:55:40jtimon: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:12petertodd:fair enough
16:56:49petertodd: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:55jtimon:petertodd: because you can't, how do you trade 1 A chaumian token for 1 B token?
16:57:35jtimon:petertodd, again it does NOT rely on merged mining you could do 2 way pegging from BTC to litecoin or quark
16:57:53jtimon:it's just that merged mining is the most interesting use case
16:58:32petertodd: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:36jtimon:but chaumian "cash" transfers cannot be conditional so how do you make one of the transfers conditional to the other?
17:00:03jtimon:OT's answer: you deposit both in the same OT server and trade the credit
17:00:31petertodd: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:41jtimon:don't worry, I've saying that about chaumian cash since I studied OT as a potential plattform for implementing distributed ripple
17:02:47jtimon:well in OT is lucre instead of chaum, but similar properties
17:04:44antephialtic: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:42jtimon:mhmm, are you counting 2 different issuers?
17:05:45jedunnigan:jedunnigan has left #bitcoin-wizards
17:06:23antephialtic:fair point. But with a federated OT or Ripple style system it would work
17:06:36jtimon:anyway, transitive transactions (ripple) require generalization to N issuers and n currencies in the same atomic trade
17:08:46jtimon:I'm not sure, maybe, I doubt it, chaum seems to be alergic to atomic trades ;)
17:09:06jtimon:you mean ripple-consensus by Ripple I guess
17:10:24jtimon:anyway if you find a solution for 2 different assets in the same OT server, probably #opentransactions are all hears
17:10:45antephialtic:cool, I need to read up on the details of OT
17:13:19jtimon: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:26gmaxwell: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:37gmaxwell:er s/non-expired/now-expired/
17:20:05jtimon:gmaxwell, yes, and chaum is probably easier to understand, but I think OT still uses lucre
17:20:53gmaxwell:well, I think lucre can be easily applied to EC groups, so perhaps it can be made more efficient easily.
17:23:48Elriel:how about the EC Math based blind signature system? I think I saw a paper about such some time ago.
19:49:56BCB: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:14gmaxwell:hah: http://dilbert.com/2014-04-02/
20:35:40Ademan:gmaxwell: hrm, someone ought to make dogbertcoin for dumb crypto enthusiasts
20:36:00[\\\]:[\\\] is now known as NARC
20:36:08NARC:NARC is now known as [\\\]
20:38:55Emcy:fungibility really is a silly word isnt it
21:09:20Matt_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:55gmaxwell: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:31gmaxwell: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:34kanzure: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:19kanzure:bus factor increases with the square of the average proximity of the contributors... or something.
21:18:22Matt_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:28Luke-Jr:Matt_von_Mises: under normal conditions, YOU DON'T NEED MINERS AT ALL
21:19:55kanzure:oh yeah, that should definitely be in bold in asic-faq.pdf or something like it
21:20:12Matt_von_Mises:Luke-Jr: What do you mean?
21:20:22Luke-Jr:Matt_von_Mises: I mean the ENTIRE PURPOSE of miners is to handle ATTACKS.
21:20:50Luke-Jr:if you pretend there's no attacks, then you don't need them
21:21:46midnightmagic:obfuscating names @!@$!@&#
21:21:55gmaxwell: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:45Matt_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:00Luke-Jr:"normal conditions" is NOT dependant on miners
21:26:30Luke-Jr:without attacks, nobody tries to double spend, thus a blockchain is a waste
21:26:42gmaxwell: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:01Matt_von_Mises:But that wasn't what I meant, but nevermind.
21:27:16midnightmagic:Magic's Window Washing -- what if we take the last 11 blocks of reward and modify the 10-minute block target!
21:27:19midnightmagic:I'm a genius.
21:27:24midnightmagic:* midnightmagic is off to patent the algo
21:28:01Matt_von_Mises:Anyway I better be off. Thanks.
21:28:06Matt_von_Mises:Matt_von_Mises has left #bitcoin-wizards
21:28:06gmaxwell: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:32midnightmagic:you're welcome
21:30:00andytoshi: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:32midnightmagic:andytoshi: Are you still working on that "what alts have tried and failed at" doc?
21:31:29andytoshi: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:59kanzure:wasn't aware of alts.pdf, but i'll promptly steal that file
21:32:28andytoshi:kanzure: https://download.wpsoftware.net/bitcoin/alts.pdf
21:32:51andytoshi:also midnightmagic ^ that's supposed to be the list, but for now it's just patter
21:33:19kanzure:it's curious that double spending gets to be classified as an attack (i certainly agree that it is one)
21:33:25kanzure:but basic use of the system can be easily classified as an attack heh
21:33:31kanzure:s/the system/other systems
21:33:48midnightmagic: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:17warren:gmaxwell: apparently "KGW" coins were attacked recently just as expected
21:34:53gmaxwell:warren: no shock, did the attackers do anything interesting?
21:35:11warren:gmaxwell: expected results are expected
21:35:40andytoshi:midnightmagic: if any regular here PM's me i'll give them git push access ... but agreed, wiki would be better
21:35:53andytoshi:i'm happy if some one wants to copy/paste it into there, i don't have access
21:36:11midnightmagic:in either event, just wanted to say thanks for what you've done so far
21:37:44andytoshi:no worries, it's let me cut out tons of repetitive #bitcoin discussions while still giving me a way to procrastinate :)
21:42:44Luke-Jr:andytoshi: any reason not to copy these to the wiki? :P
21:43:25andytoshi:Luke-Jr: nope, i just hadn't thought to do it. anyone is welcome to :)
21:45:40Luke-Jr:andytoshi: do you even have an account? O.o
21:46:17shinybro:shinybro is now known as shinybro_
21:46:43andytoshi:i don't think so. it's possible i made one in 2011, but i definitely haven't used it since then..
21:47:06andytoshi:i wasn't gonna pay 30 damn cents for the priviledge of teaching people! ;)
21:47:19Luke-Jr:so don't pay, just tell us the username :P
21:47:48andytoshi:sure, one sec..
21:47:50gmaxwell:andytoshi: other people will pay to have the benefit of your contributions. :)
21:49:59andytoshi::} how flattering. i registered, i'm andytoshi
21:50:34Luke-Jr:nanotube: ping
21:54:47nanotube:Luke-Jr: pong
21:55:06nanotube:oh ok
21:55:07nanotube:just a sec
22:02:58jps_:jps_ is now known as jps
22:08:56Luke-Jr:"elements of the utxo set are called utxos or unsigned transaction outputs. The motivation for these terms will become clear."
22:09:11Luke-Jr:I always took it as unSPENT
22:09:27gmaxwell:where is that from?
22:09:31gmaxwell:yes, it means unspent.
22:09:45Luke-Jr:andytoshi's alt.pdf
22:10:28sipa:yeah, unspent
22:13:10Luke-Jr:andytoshi: after I'm done importing to wiki, do you want corrections by others? :P
22:47:01Ademan:"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:32jrmithdobbs:i believe so
22:47:51jrmithdobbs:should be 'if the input total is strictly greater than the output total'
22:48:24jrmithdobbs:(you're not as crazy as you thought ... this time)
22:48:38sipa:Ademan: #bitcoin-dev please (and you are right)
22:48:53Ademan:sipa: was referring to Luke-Jr's link
22:49:00sipa:oh, nevermind
22:49:07[Tristan]:[Tristan] is now known as Guest67709
23:28:10adam3us: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:35adam3us:(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)