00:00:34 mappum has joined #bitcoin-wizards 00:01:48 orperelman has quit 00:02:59 justanotheruser has quit 00:06:26 rdymac has quit 00:07:04 orperelman has joined #bitcoin-wizards 00:09:37 rdymac has joined #bitcoin-wizards 00:18:56 eristisk has joined #bitcoin-wizards 00:26:48 eristisk has quit 00:29:01 OneFixt_ is now known as OneFixt 00:30:41 gmaxwell maaku_ nsh I think it's the chain-hoping algos and not the filters what need to improve most, provided that you have a responsive enough filter 00:31:06 they are really dumb 00:31:19 * nsh nods 00:32:14 they believe anything that's in some webs that calculate profitability simply from spot price without any look to market depth, volume or vollatility 00:32:40 http://www.coinwarz.com/cryptocurrency 00:33:31 It's very easy to put a small coin on top of that list with little money 00:35:06 and hop-miners jump into shitcoin just to find out later that they broke the price when dumping their mined coins into the market 00:36:56 a good algorithm just needs to target a time period, the market should make profitability tend to 0% 00:38:10 just not yet 00:38:59 RoboTedd_ has joined #bitcoin-wizards 00:40:13 I think the non-merged-mined SHA256 are in the worse position for chain-hoping 00:40:27 Ursium has quit 00:40:49 so I'm pretty happy with freicoin's filter, things will only get better when MM 00:41:55 RoboTeddy has quit 00:42:04 and other coins that don't use the block height for demurrage care less about not being always 10 min 00:43:51 even terracoin survives with its random-like filter 00:46:58 jtimon: I'm more worred about things like long term behavior with fees being compariable in magnitude to subsidy and miners mining near breakeven in power cost. 00:47:53 and then things like filter overshoot making huge chunks of hashpower go unprofitable and shut off automatically. such a system could very likely be quite unstable. 00:48:10 e.g. a small overshoot oscilation magnifies until all the hashrate is turning off. 00:48:53 for the filter it's the same, you need to adjust rapidly when big hashing comes and goes 00:49:57 "it's the same"? 00:50:16 I'm not saying it's not a difficult problem, I'm saying you can model the filter with against random curves without modeling any mining economics 00:51:02 No you can't. A filter with overshoot behaves very differently in a non-linear system than does one which is critically damped. 00:51:11 there could be an earthquake destroying 40% of the hashrate and you should be preapared as well 00:51:37 gmaxwell, is there a cap on how large the change in difficult can be for any one period? (either up or down) ? 00:51:38 What I'm pointing out is that some filters can actually cause system failure under some mining economics models. 00:51:47 phantomcircuit: yes, 4x. 00:51:54 oh 00:51:55 (in both directions) 00:52:03 so that's effectively only relevant for down 00:52:14 gmaxwell I think all filters could fail under certain conditions 00:52:19 the box filter is probably unconditionally safe. 00:52:27 you must chose the conditions you're not prepared for 00:52:46 jtimon: forget "prepared", I'm pointing out that some designs can fail when nothing changes or goes wrong. 00:54:05 orperelman has quit 00:54:18 In an enviroment where miners turn off when not profitable and turn on when profitable, a design that has overshoot can drive the system into instability. miners turn on, diff goes up, but it goes up too much and then even more miners turn off. then when it goes down it goes down by too much and more miners turn on, and each swing a great portion of the hashrate is being pulled into the oscillation. 00:54:42 I haven't studied any of the filters so I believe a box filter could be better and there's designs that can failt with a constant hashrate 00:54:46 keynesian beauty contest to the rescue? 00:54:57 :-) 00:54:59 but when's the point in chosing those? 00:55:36 jtimon: I think the design in freicoin is one that can fail with constant hashrate! 00:55:42 gmaxwell you can also manually change diff with a hardfork 00:55:50 (it has a pretty substantial overshoot) 00:56:05 oh, I see 00:56:10 I didn't know 00:56:11 jtimon: which is part of the reason that worrying about black swans is probably a waste of time, esp if the result is something thats riskier. 00:56:47 like most times, it's a tradeoff 00:57:11 RoboTedd_ has quit 00:57:43 RoboTeddy has joined #bitcoin-wizards 00:57:53 RoboTeddy has quit 00:58:34 RoboTeddy has joined #bitcoin-wizards 01:00:00 in any case, maybe you're right that a less "responsive" filter is better long term, with a mature market without so much subsidy 01:01:22 but in this case (allowing bitcoin asic miners to come and go, but not to mine both at the same time) we desperately needed something more prepared for wild swings 01:03:10 my complaint there is not about responsive. 01:05:20 gmaxwell: the overshoot is not that substantial 01:05:30 the prarameters themselves are slightly underdamped 01:05:40 and the overshoot comes from the 144-block window 01:06:10 maaku_: Hm. from the FIR filter I saw you using before it could be as high as 20%, IIRC though perhaps it got changed? 01:06:11 so with big square-wave changes, it takes a dozen or more blocks to react 01:06:36 no, it hasn't changed. 01:07:27 i just have a different opinion of those numbers - overshooting by 20% when someone is toggling an order of magnitude more hash power than your entire network is pretty good, imho 01:07:54 we were <1Th/s, and getting hit by 10Th/s chain hoppers 01:10:47 Ursium has joined #bitcoin-wizards 01:10:58 thats not what overshoot means, thats called group delay when it takes a long time to react at all. 01:11:17 Overshoot is when it does react that it can react more than the change. 01:12:19 yes, well you want a little bit of that 01:12:26 you want it to be underdamped, slightly 01:12:37 Ursium_ has joined #bitcoin-wizards 01:15:55 Ursium has quit 01:17:38 Ursium_ has quit 01:25:55 gavinandresen has quit 01:40:40 Ursium has joined #bitcoin-wizards 01:45:31 midnightmagic has quit 01:46:04 Ursium has quit 01:46:42 justanotheruser has joined #bitcoin-wizards 01:49:59 jtimon has quit 01:50:02 justanotheruser1 has quit 01:52:03 midnightmagic has joined #bitcoin-wizards 01:53:55 justanotheruser has quit 01:59:37 rdymac has quit 02:07:07 rdymac has joined #bitcoin-wizards 02:09:47 rdymac has quit 02:19:38 rdymac has joined #bitcoin-wizards 02:34:18 gavinandresen has joined #bitcoin-wizards 02:41:24 Ursium has joined #bitcoin-wizards 02:46:26 Ursium has quit 02:51:13 justanotheruser has joined #bitcoin-wizards 02:51:45 justanotheruser1 has joined #bitcoin-wizards 02:55:33 justanotheruser has quit 03:00:06 justanotheruser has joined #bitcoin-wizards 03:02:57 justanotheruser2 has joined #bitcoin-wizards 03:02:57 justanotheruser1 has quit 03:04:45 gavinandresen has quit 03:04:57 justanotheruser1 has joined #bitcoin-wizards 03:05:13 justanotheruser1 has quit 03:05:13 justanotheruser1 has joined #bitcoin-wizards 03:07:03 justanotheruser has quit 03:07:13 justanotheruser2 has quit 03:20:47 Shibe_tabsa has quit 03:37:28 How many inputs and how many outputs can be in a transaction? Is there a limit on this other than 1mb? 03:42:09 Ursium has joined #bitcoin-wizards 03:47:17 Ursium has quit 03:51:28 justanotheruser1 is now known as justanotheruser 03:59:44 <[\\\]> [\\\] has joined #bitcoin-wizards 04:16:19 justanotheruser1 has joined #bitcoin-wizards 04:17:04 justanotheruser has quit 04:20:29 justanotheruser1 has quit 04:30:48 jps has joined #bitcoin-wizards 04:31:46 justanotheruser has joined #bitcoin-wizards 04:32:29 jps_ has joined #bitcoin-wizards 04:35:27 jps has quit 04:35:27 jps_ is now known as jps 04:36:33 justanotheruser has quit 04:37:26 justanotheruser has joined #bitcoin-wizards 04:42:55 Ursium has joined #bitcoin-wizards 04:44:23 BlueMatt has quit 04:44:30 BlueMatt has joined #bitcoin-wizards 04:44:30 BlueMatt has quit 04:44:30 BlueMatt has joined #bitcoin-wizards 04:44:42 Ursium_ has joined #bitcoin-wizards 04:47:59 Ursium has quit 04:49:43 Ursium_ has quit 04:55:45 justanotheruser has quit 04:55:45 justanotheruser has joined #bitcoin-wizards 04:59:20 <_ingsoc> _ingsoc has joined #bitcoin-wizards 05:22:26 RoboTeddy has quit 05:41:30 RoboTeddy has joined #bitcoin-wizards 05:45:27 Ursium has joined #bitcoin-wizards 05:50:29 Ursium has quit 05:50:29 jps has quit 05:50:54 RoboTeddy has quit 05:52:03 <_ingsoc> _ingsoc has quit 05:52:14 RoboTeddy has joined #bitcoin-wizards 06:22:05 <[\\\]> [\\\] has quit 06:27:05 <[\\\]> [\\\] has joined #bitcoin-wizards 06:31:23 justanotheruser has quit 06:31:46 justanotheruser: 18,446,744,073,709,551,615 06:31:55 you hit the 1mb limit long before then, however 06:38:28 nessence has joined #bitcoin-wizards 06:43:57 RoboTeddy has quit 06:45:19 RoboTeddy has joined #bitcoin-wizards 06:45:57 zfaith has quit 06:46:12 Ursium has joined #bitcoin-wizards 06:49:08 zfaith has joined #bitcoin-wizards 06:50:58 Ursium has quit 06:50:58 mappum has quit 06:55:54 <_ingsoc> _ingsoc has joined #bitcoin-wizards 06:57:47 <_ingsoc> _ingsoc has quit 07:01:03 nOgAnOo has quit 07:16:23 justanotheruser has joined #bitcoin-wizards 07:19:05 nOgAnOo has joined #bitcoin-wizards 07:19:11 nOgAnOo has quit 07:22:35 nOgAnOo has joined #bitcoin-wizards 07:46:56 Ursium has joined #bitcoin-wizards 07:52:05 Ursium has quit 07:58:40 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:07:47 so i think i found a way to (network) efficiently and securely do SPV for single use addresses. now that i thought about it I dont see why i didnt see it before as it an application of NIFS which i described up as a problem statement of in 1996, and found a mechanism for in 1998 (novel use of IBE) and Boneh found a more efficient building block for in 2001 (the weil pairing) 08:08:17 NIFS http://www.cypherspace.org/adam/nifs/ 08:10:36 it was thought up to provide forward secrecy for email where there is no interactive communication. read that. its basically like a public derivation variant of HD wallet concept but where anyone can be after the fact given a private key 08:11:30 Sangheili has quit 08:17:49 hmm maybe not ... gotta think more about this (just woke up:) i am thinking weil pairing gives the extra flexibiliy so you can have someone derive a public encryption key for you from a reusable encryption pub key and the previous block number, then do a derivation from the reusable address with a random factor by sender, encrypt factor with the derived pub enc key, and then afterwards you can derive the corresponding private dec key and s 08:18:56 and therefore the query (the private key) could be unique to the block only, obviously very compact, useless for correlating with other blocks, and non-interactive 08:20:39 well, we can do what tor is looking to do with hidden services but its not blind to someone who knows your address. 08:21:59 hm. interesting yea okay 08:22:02 yes ok i think brain woke up, its not NIFS its a diff problem statement a variant without the forward-secrecy as you need random lookup in the tag space, and to be able to safely send people the private key 08:22:40 so how about this: take the reusable address scheme, but make the ECDH pubkey be pubkey + H(blocknumber)*G 08:23:02 the problem there is that it has the private key unzip attack that BIP32 has. 08:23:04 gmaxwell: basically each user is their own IBE server, they publish the IBE params as their reusable public address 08:23:30 yea, I don't think this is doable without pairing— the EC addition way to do it has the unzip attack. 08:23:58 gmaxwell: so with IBE your identity is your key, so encrypt with the pub key derived from the previous block hash as "identity" 08:24:51 gmaxwell: then do the normal sender choose rndom factor, encrypt factor with the derived pub key, ten to delegate a per block decrypt capability, you send the node the corresponding private key that you derive using your IBE private key. 08:24:55 gmaxwell: agreed 08:25:08 then again the pairing is only needed for recognition, so it could be employed here. it would allow you to produce unique per block recognition keys. Someone you gave your reconigition private keys to could only reconize your transactions that used those keys. 08:25:10 gmaxwell: unfortunately that lets weil-pairing crypto into the tent 08:25:26 But its only for privacy, I'm okay with that, but it's an implementation barrier. 08:25:30 gmaxwell: yes. 08:26:19 (IMO thats how we should be using pairing in cryptosystems: for lower value applications, and solving things that can't be solved any other way) 08:26:28 gmaxwell: well its a start, a proof of concept that its possible. petertodd started to think it maybe provably not, but that seemed wrong to me, and its a good thing he asked the q of can u prove it not, cos it triggered me to think in the other direction :) 08:27:45 gmaxwell: yeah, if it has a sane failure mode. there maybe ways to contain the failure a bit with normal mechansims eg a few IBE keys or such 08:28:23 gmaxwell: also i think IBE is technically overkill we dont really need a comm channel, that is a side effect of the previous mechanism. so we may be able to do better. 08:29:13 gmaxwell: we just want a per block discriminant private key, we dont actually need to allow the node to decrypt something, it can give it to the SPV node and it can decrypt it, itself 08:29:19 well really what we want is a BIP32 like derivation which doesn't have the unzip attack. 08:29:30 gmaxwell: exactly. 08:31:07 gmaxwell: i dont think u can do it like that tho, because thats what i was trying to do with NIFS and I made and broke a few mechanisms 1996 and concluded you cant do it with DL, hence the IBE connection to NIFS 1998, and then Boneh weil pairing 2001 made it secure/efficient (but esoteric) 08:31:50 Ursium has joined #bitcoin-wizards 08:33:34 ::nods:: 08:34:25 gmaxwell: but this seems something with lower requirements, more like a new problem statement, so maybe something below IBE can be found. anyway i was excited to have a proof of concept, even weil pairing using... have to think about that next step more :) 08:35:44 I'd thought about using the prior block as an identity parmeter but I didn't see how to get away from simulation by anyone who knew the address... the IBE approach indeed would work. 08:39:33 petertodd: to decode for you, since you may not be familar with IBE stuff: The idea is that the user has a master private key, which results in a master public key. Anyone can take a prior block hash and combine it with the master public key to get a session pubkey which could be used to encrypt a chaincode included in an OP_RETURN. Using the master private key the user can derrive the session private key, which can then be used to ... 08:39:39 ... reconize transactions using the same session key. 08:40:07 This all sounds a lot like type-2 derrivation, but it doesn't have the unzip problem: having the session private key doesn't help you derrive any other session private keys. 08:41:07 (In IBE (identity based encryption) this is all used a bit differently: the master keys are held by a CA, and the session ID is your email address, and now anyone can make a public key for you— but you need the CA's help to get your private key) 08:44:00 In fact, if we use this only to encrypt bait, then we can make it more denyable by leaving authentication out of the cryptosystem. 08:45:08 E.g. the includes an encryption of a random value with the least significant 8 bits set to zero. Incorrect decryptions will sometimes turn up fake matches. 08:46:24 Sangheili has joined #bitcoin-wizards 08:49:26 gmaxwell: ah nice. its absolute worst case failure mode is what peter was proposing... bloom bait/prefix 08:49:43 yea, if you break the cryptosystem you just get bloombait. 08:50:04 gmaxwell: yes i was thinking also you could send a few dud keys to confuse things, but this is better and could use your like 8 bloom baits, ie one could tune it 08:50:27 RoboTeddy has quit 08:51:04 downside vs bloombait is that its not indexable. 08:51:11 gmaxwell: i mean you could send the node your block priv key and a few random priv keys. but the extras will never match. by doing bait we get that ability 08:51:13 RoboTeddy has joined #bitcoin-wizards 08:51:42 yea, I was thinking about that when I got to the encrypted bait construction... the never matching makes it obvious which ones are real. 08:55:09 roidster has quit 08:55:24 RoboTeddy has quit 08:58:53 one interesting thing about the encrypted bait construction is that its attack resistant. 08:59:09 a normal bait can be attacked by some high transaction volume jerks choosing the same bait as you. 09:10:06 downside is that the it has moderately high overhead, I don't see how to get the overhead under two group elements. 09:10:21 but perhaps when I think some more I'll see a way to get it down to one. 09:18:36 gmaxwell: yes i thnk there maybe scope to go further or to non IBE potentially because the requirements are weaker than what it provides. lets see - having one stepwise clear improvement often helps unlock thinking about the next optimization 09:37:14 notthemessiah has quit 09:38:28 Ursium has quit 09:47:46 justanotheruser1 has joined #bitcoin-wizards 09:49:01 justanotheruser1 has quit 09:49:01 justanotheruser1 has joined #bitcoin-wizards 09:51:49 justanotheruser has quit 09:54:29 orperelman has joined #bitcoin-wizards 09:56:04 justanotheruser has joined #bitcoin-wizards 09:57:12 justanotheruser has quit 09:57:12 justanotheruser has joined #bitcoin-wizards 09:57:29 justanotheruser1 has quit 10:04:12 justanotheruser1 has joined #bitcoin-wizards 10:05:27 Ursium has joined #bitcoin-wizards 10:06:17 justanotheruser has quit 10:07:06 hnz has quit 10:10:15 rdymac has quit 10:10:37 rdymac has joined #bitcoin-wizards 10:12:31 hnz has joined #bitcoin-wizards 10:17:36 BigBitz has left #bitcoin-wizards 10:30:14 justanotheruser1 has quit 10:36:53 jtimon has joined #bitcoin-wizards 10:37:30 oh dear, http://bitcoin.stackexchange.com/questions/21036/are-namecoins-obsolete-with-the-upcoming-bitcoin-0-9 10:38:00 how do we explain this? 10:38:29 why so many people think "bitcoin 0.9, now with arbitrary data" 10:38:31 ? 10:41:36 justanotheruser has joined #bitcoin-wizards 10:49:37 Probably because of what Gavin said about Ethereum? 10:49:53 "we can adapt anything into bitcoin. 10:51:43 nsh has quit 11:00:37 can doesn't mean will, certainly not on such a short timeframe 11:02:08 <_ingsoc> That's just what you say to keep people happy. 11:03:43 <_ingsoc> Innovation can end up hurting value because it's change. 11:04:26 <_ingsoc> So you naturally tend to avoid what you perceive as dramatic change. 11:05:05 <_ingsoc> If Ethereum could do what Ethereum wants to do by contributing code here, there wouldn't be Ethereum, would there? 11:05:17 <_ingsoc> As an example. 11:07:23 Ursium has quit 11:20:22 nessence has quit 11:20:28 nessence_ has joined #bitcoin-wizards 11:39:48 <_ingsoc> _ingsoc has quit 11:40:20 nsh has joined #bitcoin-wizards 11:40:57 nsh has quit 11:40:58 nsh has joined #bitcoin-wizards 11:41:23 nsh has quit 11:45:53 nsh has joined #bitcoin-wizards 11:46:32 nsh has quit 11:46:32 nsh has joined #bitcoin-wizards 11:47:10 nsh has quit 11:47:41 nsh has joined #bitcoin-wizards 11:48:43 nsh has quit 11:49:21 nsh has joined #bitcoin-wizards 11:49:45 nsh has quit 11:49:45 nsh has joined #bitcoin-wizards 11:50:31 <_ingsoc> _ingsoc has joined #bitcoin-wizards 11:52:30 nsh has quit 11:53:54 nsh has joined #bitcoin-wizards 11:54:44 nsh has quit 11:55:42 nsh has joined #bitcoin-wizards 11:56:51 nsh has quit 11:57:43 nsh has joined #bitcoin-wizards 11:58:44 nsh has quit 11:59:54 nsh has joined #bitcoin-wizards 12:01:08 nsh has quit 12:01:52 nsh has joined #bitcoin-wizards 12:03:09 nsh has quit 12:03:56 nsh has joined #bitcoin-wizards 12:04:52 nsh has quit 12:13:21 dlidstrom has quit 12:23:25 nsh has joined #bitcoin-wizards 12:25:00 jtimon has quit 12:28:33 nsh has quit 12:38:49 skinnkavaj has quit 12:39:53 skinnkavaj has joined #bitcoin-wizards 12:43:49 orperelman has quit 12:44:59 Ursium has joined #bitcoin-wizards 12:46:32 Ursium has quit 12:52:20 skinnkavaj has quit 12:57:04 orperelman has joined #bitcoin-wizards 12:59:05 skinnkavaj has joined #bitcoin-wizards 13:00:13 Ursium has joined #bitcoin-wizards 13:02:28 Ursium has quit 13:08:59 orperelman has quit 13:23:29 skinnkavaj has quit 13:23:59 skinnkavaj has joined #bitcoin-wizards 13:38:30 orperelman has joined #bitcoin-wizards 13:54:52 <_ingsoc> _ingsoc has quit 14:10:34 nessence_ has quit 14:22:31 jps has joined #bitcoin-wizards 14:32:45 MoALTz has quit 14:34:33 skinnkavaj has quit 14:37:12 skinnkavaj has joined #bitcoin-wizards 14:39:29 jps has quit 14:45:32 justanotheruser has quit 15:00:46 justanotheruser has joined #bitcoin-wizards 15:07:38 briancrain has joined #bitcoin-wizards 15:10:03 nsh has joined #bitcoin-wizards 15:13:58 MoALTz has joined #bitcoin-wizards 15:19:08 jps has joined #bitcoin-wizards 15:31:12 gavinandresen has joined #bitcoin-wizards 15:41:34 <_ingsoc> _ingsoc has joined #bitcoin-wizards 16:02:27 tacotime_ is now known as tt_away_ 16:02:42 Oh whoa, Gavin is here. :) 16:02:52 Welcome 16:13:30 orperelman has quit 16:29:36 Shibe_tabsa has joined #bitcoin-wizards 16:36:53 can someone explain to me how the batching of an epoch of blocks works in bloom filtering? 16:37:30 TD said it works via query for 500 blocks in a batch to reduce network round trips. 16:41:39 I don't know that it matters, in that since all this would need new network messages you could just also send a list of 500 keys along with the 500 blocks. Though batching makes sense for another reason: since a txn isn't guarenteed to show up in the next block you need to use past keys too, and the matching has O(N*M) complexity. 16:42:36 so usinge fewer keys, say one for every 72 blocks, may make sense. 16:43:55 gmaxwell: i was wondering re the second problem if the sender could identify the block they were thinking of when they derived it. 16:44:23 gmaxwell: then they could be indexed by sender block and that bit could be deterministic and O(N) instead 16:46:04 gmaxwell: the other thing is (and i started writing a reply to TD on bct) that i am not sure you gain security by using different keys in a batch because its anyway implicit (*) if all the queries are in the same request that they're yours (or candidates if you smear it a bit with your extended bait idea) 16:46:41 gmaxwell: (*) the other possibility being to relay queries via a hop encrypted, then queries could be a mix of yours and other peoples 16:47:25 the batching doesn't hurt except in so far as it reduces your minimum connection granularity. 16:49:07 gmaxwell: well if i connect from IP-addr#1 and request query of block 1,2,3 with key k1,k2,k3 chances are those tx are all mine, so the node learns those 3 are probably owned by one person across 3 blocks 16:50:16 gmaxwell: whereas if i connect from ip-addr#1 and request query of block 1 with k1, then reconnect from ip#2 later, or connect to a diff node and ask for query of block2 with k2, then even if node 1 and 2 collude they dont know if thats one user... (and optional relaying of queries and responses could blur that together) 16:50:27 yes, right but say you make your batch 1000 blocks. Then for blocks 0-100 you're connected to one node ... and 200-300 another node .. and so on. If your batch had been smaller you would have leaked less. 16:52:29 gmaxwell: smaller batch = less leakage, a tradeoff, but here the query data is presumably much smaller than a bloom filter, so it would be nice to aggregate multiple users queries into a block via relaying (maybe). 16:53:02 gmaxwell: "batching doesn't hurt except in so far as it reduces your minimum connection granularity" i think you mean you optionall ramp it up, but by having epoch size 1 key derivation then you can go down to individual if you want later 16:53:10 briancrain has quit 16:58:48 oh i guess another security argument weil pairing is probably stronger than connecting to random internet nodes and delegating query to them re node-capture sybil attack. (ie the privacy security relies on avoiding node capture) 17:17:07 Emcy has quit 17:17:11 Emcy_ has joined #bitcoin-wizards 17:33:26 briancrain has joined #bitcoin-wizards 17:38:55 justanotheruser has quit 17:38:55 justanotheruser has joined #bitcoin-wizards 17:41:43 gmaxwell: you know the weil pairing itself is significantly amenable to multiplicative derivation tricks. you might be able to have each node multiply by its H(IPaddr#) or such querier known guid, or sent over comm channel on other connect time response, and then be able to make different query keys for the same data on different nodes, making it harder to observe redundant checks without needing to use encryption between nodes 17:45:40 adam3us1: related, if the bait scheme were similar to the one I suggested, you could intentionally make your bait searching radius half sized and connect to two severs and give each of them half your radius. so some of your transactions would learn via one, some via another... though they'd have the same query key. Probably not worth the complexity. 17:46:06 shesek has quit 17:49:28 gmaxwell: yes. overall seems quite exciting :) we could improve privacy & anon-set for SPV vs bloom, save bandwidth vs bloom query. Abandoning one-use addresses seems risky because of the reliance on weil-pairing for privacy otherwise that would be a nice simplifying assumption and mesh with hard to shake user comprehension problem (or UX issues that dont show that well). Damn pity there so far no way to do it with ECDL 18:01:29 shesek has joined #bitcoin-wizards 18:14:41 jps has quit 18:16:48 jps has joined #bitcoin-wizards 18:25:40 briancrain has quit 18:28:03 dlidstrom has joined #bitcoin-wizards 18:32:06 perrier_ has quit 18:32:48 perrier has joined #bitcoin-wizards 18:38:56 justanotheruser1 has joined #bitcoin-wizards 18:41:27 rdymac has quit 18:42:08 justanotheruser2 has joined #bitcoin-wizards 18:42:13 justanotheruser has quit 18:42:43 justanotheruser2 has quit 18:42:43 justanotheruser2 has joined #bitcoin-wizards 18:43:17 justanotheruser1 has quit 18:47:36 Shibe_tabsa has quit 19:06:55 justanotheruser2 is now known as justanotheruser 19:15:03 <_ingsoc> _ingsoc has quit 19:15:34 <_ingsoc> _ingsoc has joined #bitcoin-wizards 19:16:02 <_ingsoc> _ingsoc is now known as Guest35297 19:22:50 Guest35297 has quit 19:23:05 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 19:39:13 sneak has quit 19:43:20 shesek has quit 19:46:28 <_ingsoc_> _ingsoc_ is now known as _ingsoc 20:12:51 c0rw1n has joined #bitcoin-wizards 20:30:33 Ursium has joined #bitcoin-wizards 20:34:01 shesek has joined #bitcoin-wizards 20:46:46 orperelman has joined #bitcoin-wizards 20:56:49 mappum has joined #bitcoin-wizards 21:28:00 jps has quit 21:30:36 rdymac has joined #bitcoin-wizards 22:11:05 c0rw1n_ has joined #bitcoin-wizards 22:11:59 orperelman has quit 22:12:17 c0rw1n has quit 22:21:22 rdymac has quit 22:21:36 rdymac has joined #bitcoin-wizards 22:27:36 c0rw1n has joined #bitcoin-wizards 22:28:34 hey guys, I keep thinking about some p2p web of trust + some pagerank alike algorithm, also I keep wondering if it would be possible to be able to get score for somebody (based on my trust weights), without trust weights being public, maybe you have some random association terms, links or papers to throw at me? 22:29:20 random association term : freenet 22:29:43 they have a web-of-trust, no idea how public it is 22:30:29 c0rw1n_ has quit 22:31:24 comboy: I've thought about this sort of things before, and the best I can come up with is multiparty computation. 22:31:49 one problem is that you have information leak attacks if someone can constantly query the system. 22:32:00 c0rw1n_ has joined #bitcoin-wizards 22:32:15 orperelman has joined #bitcoin-wizards 22:32:43 c0rw1n: thx, good hint, but it seems just to fight spam and quite simplified compared to what I'm thinking of 22:32:47 E.g. say I want to know if you trust c0rw1n. Okay, so I make a new sybil account which only trusts you, and then I query the system and find out the sybs trust of c0rw1n. The result is that I know that either you trust him or at least that there is a transitive relationship. 22:32:50 c0rw1n_ has quit 22:33:09 c0rw1n_ has joined #bitcoin-wizards 22:34:23 comboy: there is some work being done on reputation in pseudonymous networks 22:34:38 with multiparty computation you could have N folks combine in order to answer queries on the transitive trust without disclosing the graph, and if you imposed some cost on queries (e.g. have to pay a fee to the bitcoin network per query) then you could prevent an attacker from constantly querying it to drag out the information. Downsides: multiparty computation isn't pratical today, and the participants would need to be online. 22:34:55 not sure if it's what you're after, but you might want to take a look: http://freehaven.net/doc/cfp02/cfp02.html 22:35:00 c0rw1n has quit 22:35:28 gmaxwell: yeah, that is a problem, but maybe you could send queries only to nodes who trust you for example.. I'm not even sure it would help... but if you would be not getting full info with some random noise.. 22:35:42 Personally, I think reputation is nearly worthless in anonymous systems. :P 22:36:04 could the graph not exist publicly (or queryably) in some heavily disjoint form that can be recovered using private correspondences (wallet-like identities) 22:36:04 ? 22:36:06 well it is without this kind of system 22:36:31 pseudonymous != anonymous :) 22:36:48 yeah identities equivalent to addresses in your wallet would also be some idea 22:36:52 in anonymous systems reputation is indeed worthless 22:37:05 yes 22:37:05 comboy: well, see for example some of the information theoretic PIR stuff that lets you have a database which can be privately queried and which is secret from the servers if some threshold of the servers do not collude. But I don't know how to create the initial database privately except via MPC, and I don't know how to reliably rate limit access. And trusting servers to not collude is prety lossy. 22:37:33 (reputation only becomes worthless asymptotically as the cost of newnym'ing goes to zero) 22:38:05 Alanius: even in pseudonymous systems. We see lots of cases in bitcoin-otc (one of few examples ofa pseudonymous wot system where there is actually something at stake) where scammers farm identities until they a trusted then rob people blind. 22:38:25 c0rw1n_ has quit 22:38:39 to be fair, that's also a pretty stubborn feature of the non-technological world 22:39:00 c0rw1n has joined #bitcoin-wizards 22:39:21 I mean as far as my quite dumb crypto mind was thinking it would require some p2p client running, I can't imagine it as just a static db somewhere 22:39:51 I think it's helpful to think about the benefit of 'reputation' systems in terms of "seperation" e.g. how powerful are they at separating good participants from bad ones. And I think a lot of ideas actually turn out to have _negative_ separation: they actually increase the density of bad people because they impose costs and good people just walk away since what they were going to do wasn't that profitable for them, whereas bad ... 22:39:57 ... people don't mind the costs because they're a minor cost of doing business (and because the learning how it works part is amortized against many identities) 22:40:12 gmaxwell: theoretically pagerank + your connections could prevent farming, once somebody goes rogue, ranks of whoever trusted him goes down 22:40:56 well, if you consider it as a separation/classification problem then the system has to be negentropic, which means some resource of order must be consumed 22:41:00 comboy: no, it doesn't because obviously your system needs to be welcoming to new people (or it will fail), and so they just simulate new people. 22:41:06