--- Log opened Thu Nov 07 00:00:33 2013
06:25 < midnightmagic> hrm.
06:26 < midnightmagic> petertodd: Did you see the FAQ entry in Sirer's blog? "Our attack does not rely on network position or well-connectedness. It does not require Sybils. It does not require a fast connection to other miners. Anyone who claims otherwise does not understand the attack."
06:47 < petertodd> midnightmagic: yes I did, and the way they describe their attack is its one where it's made better by all those things
06:50 < midnightmagic> Sneaky wording then. Doesn't *rely* on it, and works without it. I wonder if "minimal advantage" is thus how they consider the attack as a currency-destroying revelation.
06:51 < petertodd> They're assuming that miners will shift to the pool with the higher profit margin
06:52 < midnightmagic> i wonder if the math were done right now it would compare against just making a bunch of blank blocks
06:52 < midnightmagic> s/now/how/
06:53  * midnightmagic solicits headache cures
06:53 < petertodd> Look at it this way: their attack, without any low-latency insight into the network, devolves into my attack!
06:56 < petertodd> Or less charitably: I had a great bit of intuition months ago, was lazy and didn't develop it properly, and someone else re-invented it with the twist that if you also have low-latency you can exploit it at less than 30% hashing power.
06:57 < petertodd> or heck, maybe that's where they got the idea... they tell me that they don't understand how my attack works, but I don't exactly trust those guys :/
07:13 < midnightmagic> petertodd: I read -wizards as much as possible but I missed your attack. What's your attack?
07:14 < petertodd> It's something I posted ages ago to bitcoin-development - like last january - showing how contrary to popular belief miners had an incentive to publish their blocks to only a majority of hashing power rather than all hashing power if their goal was to get more blocks than other miners.
07:15 < petertodd> My original analysis was overely simplistic, and when I applied a bit of math to it I realized I was wrong and the threshold was actually only 30%
07:20 < midnightmagic> petertodd: ah cool thanks for the pointer
14:25 < maaku> I haven't studied SIN / identity protocol much at all
14:25 < maaku> So question for the other -wizards': are there hard-fork changes which would make identity management easier?
14:26 < maaku> s/hard-fork/hard or soft fork/
14:34 < gmaxwell> maaku: being able to prove an output was created in the chain with a smaller proof (which doesn't include a whole transaction) would be nice.
14:35 < maaku> so merkleized transactions, presumably?
14:39 < gmaxwell> yes. Then you'd probably also want lockable outputs.
14:40 < maaku> lockable meaning can't be spent for X blocks, or until block X?
15:18 < gmaxwell> Either would work for SINs, the latter is probably more generally useful... the former may be better for SINs.
16:54 < gavinandresen> High-quality thoughts on selfish mining happening here:  https://bitcointalk.org/index.php?topic=327064
17:34 < MC1984> i dont know. Weve already seen we cant wholly rely on positive incentives to maximise desireable behavior (like simply making sure your mining setup is bloody working properly and keeping it so)
17:34 < MC1984> whos to say we can wholly rely on negative incentives to minimise undesireable behavior.
17:35 < MC1984> ki mean, if that were true democracy would actually work right...
17:36 < MC1984> even wholly/substantially. Especially if a rumour or urban myth goes round amongst the plebs of a way to mine more coins for free or somthing even if its actaully killing bitcoin
17:37 < maaku> hrm. SIN and namecoin are very similar mechanisms, are they not?
17:38 < gmaxwell> maaku: namecoin expects the network can do lookups for you. sin expects the user to extract a proof and provide it.
17:38 < gmaxwell> You can verify sin without speaking the bitcoin protocol at all (with some security discussion because you're "blind SPV").
18:02 < michagogo|cloud> What goes on in this channel? (found it thanks to the mailing list)
18:03 < gmaxwell> A muggle1
18:03 < gmaxwell> !
18:03 < gmaxwell> burn him!
18:03  * amiller put on his robe and wizard hat
18:03 < gmaxwell> michagogo|cloud: we talk about far out technical stuff instead of pragmatic near term bitcoin things. It's kind of a cryptonerds bitcoin-dev-offtopic.
18:04 < michagogo|cloud> Hmm, sounds interesting
18:05 < sipa> amiller: http://bash.org/?104383 ?
18:05 < maaku> stuff that's longer-term than the next release cycle
18:05 < pigeons> maaku: are you mining the -wazards for feature ideas to solve problems to add to freimarkets?
18:05 < pigeons> ;)
18:05 < amiller> bloodninja yeah ;p
18:05 < maaku> hah sometimes. that's what my question bout SIN was for
18:07 < maaku> but it's relevant since we can actually experiment with this stuff on a live network there
18:07 < michagogo|cloud> SIN/
18:07 < michagogo|cloud> s|/|?|
18:08 < maaku> michagogo|cloud: https://en.bitcoin.it/wiki/Identity_protocol_v1
18:09 < sipa> someone should write an identity protcol v2
18:09 < sipa> so we can talk about the Original SIN
18:10  * michagogo|cloud wonders if he's missing something
18:11 < amiller> "A SIN ("System Identification Number") is the unique record identifier by which this identity will be known."
18:12 < michagogo|cloud> I saw that
18:12 < michagogo|cloud> sipa: Is that a reference to something?
18:13 < maaku> michagogo|cloud: an oppressive catholic education
18:13 < maaku> http://en.wikipedia.org/wiki/Original_sin
18:14  * michagogo|cloud glances at the nick list, between kinlo and maaku
18:32 < adam3us> why do we want identities again?
18:37 < adam3us> ok skimmed bitcoin.it/.. identity_proto..  for issuer signed attestations brands is the most flexible blind signature protocol
18:38 < adam3us> there are also some protocols for serial anonymous use, where if you get banned you lose your access token, but not your anonymity
18:50 < gmaxwell> adam3us: right, for anti-trolling/spamming/etc.
18:56 < adam3us> gmaxwell: yes, the interesting thing is it turns out to be possible to be serially anonymous (as distinct from pseudonymous) while reusing a single authorization
18:57 < gmaxwell> adam3us: yea, e.g. via chaining blind signatures. Are there other ways?
18:57 < adam3us> gmaxwell: at some earlier point people supposed you could not be anonymous and yet anti-trolled
18:57 < gmaxwell> e.g. present an identiying sync, get a chaum token.. chain it forward..
18:57 < adam3us> gmaxwell: yes the actual approach was something simple like that
18:58 < gmaxwell> s/sync/sin/
--- Log closed Fri Nov 08 00:00:41 2013