| 00:03:21 | adam3us: | very weird. people on reddit/r/bitcoin are making tons of sense on 2-way pegs. http://www.reddit.com/r/Bitcoin/comments/22m063/blockchain_20_let_a_thousand_chains_blossom |
| 00:03:59 | adam3us: | usually reddit is like bottom of the list for rational or non-idiotic discussion vs bitcointalk, slashdot etc |
| 00:04:11 | andytoshi: | top post right now is |
| 00:04:14 | andytoshi: | http://en.wikipedia.org/wiki/Pegging_(sexual_practice) |
| 00:04:16 | andytoshi: | ;) |
| 00:04:51 | sipa: | adam3us: herd behaviour :) |
| 00:05:13 | adam3us: | andytoshi: ah thats better |
| 00:05:44 | sipa: | i was not aware of that meaning of the word :) |
| 00:07:10 | gmaxwell: | I was. Kat pointed it out to me, and thats the reason I didn't use it in the little abstract I submitted to the princeton workshop. |
| 00:10:28 | adam3us: | gmaxwell andytoshi: yuck thanks for that. #bitcoin-wizards sinks below reddit/r/bitcoin :) |
| 00:10:42 | midnightmagic: | sigh. one more common term appropriated into innuendo-land. |
| 00:12:13 | nsh: | andytoshi-logbot, pointer? |
| 00:12:13 | nsh: | See http://download.wpsoftware.net/bitcoin/wizards/2014-04-10#T00-12-13 |
| 00:12:21 | nsh: | oh, nice. that was a total crapshoot |
| 00:12:51 | nsh: | (would be nicer if it wasn't 404, but hey..) |
| 00:13:01 | andytoshi: | oh, damn, i should fix that.. |
| 00:13:14 | nsh: | just needs .txt |
| 00:13:31 | nsh: | but the anchors would work better if you html formatted the logs. on the other hand, ugh, effort |
| 00:17:53 | rajaniemi.freenode.net: | topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 00:17:53 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot davispuh rdymac Luke-Jr nsh roconnor tromp wallet42 ghtdak Emcy_ gavinandresen fanquake tacotime eristisk rdponticelli emsid lnovy justanot1eruser tjopper vetch Apocalyptic oooooo airbreather TheSeven comboy DougieBot5000 MoALTz_ roidster roconnor__ shinybro_ bobke spinza andytoshi Krellan_ dexX7 sploush2 copumpkin jrmithdobbs justanotheruser otoburb Elriel draino_ Logicwax dansmith_btc postpre num1 LarsLarsen |
| 00:17:54 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: justusranvier Krellan imjonathan mkarrer ewust Graet nikitab LaptopZZ mhanne Ryan52 BCB amiller adam3us tucenaber stqism gmaxwell mmozeiko phantomcircuit Alanius wumpus nezZario EasyAt mr_burdell HM2 trn d34th kaptah quackgyver zacm michagogo|cloud coryfields [\\\] Sorcier_FXK realazthat Coin4ce shadders pajarillo gribble nanotube optimator Hunger- kanzure stonecoldpat lechuga_ maaku azariah4 Mikalv Snowleaksange hno johntramp ryan-c |
| 00:17:54 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: ageis forrestv jcorgan mumu tromp__ Dyaheon poggy Guest38638 iddo espes__ helo edulix samson_ mike4 rs0 Sangheili midnightmagic petertodd weex cajg keus asoltys heakins @ChanServ Anduck Fistful_of_Coins lianj Muis kinlo sipa sbp epscy ascent_ a5m0 waxwing UukGoblin sl01 paperbot artifexd pigeons OneFixt BlueMatt jchp K1773R CodeShark typex Guest58923 harrow roasbeef flammit |
| 00:18:54 | maaku: | phantomcircuit: yeah, well some PR points need to be pushed |
| 00:22:04 | maaku: | also, /me needs a new name for freicoin-like currencies which have economic differences from bitcoin |
| 00:22:17 | maaku: | since alts are dirty and are gonna die |
| 00:23:39 | gmaxwell: | You should figure out how to merge freicoin and dogecoin. (I'm only half kidding. I think the economic model you have is compatible with what they're doing) |
| 00:24:28 | andytoshi: | to that point, i wonder if a marketing push into the tumblr/occupy world would be worthwhile |
| 00:25:09 | nsh: | tumblr/occupy? |
| 00:25:19 | andytoshi: | i was going to suggest that independently of gmaxwell's comment. but there is not a lot of deep thought there it seems, maybe you will lose the message |
| 00:25:36 | nsh: | maybe Maine and Texas have nothing to communicate |
| 00:27:05 | adam3us: | maaku: hypothetically you migrate freicoins onto a demurrage + return friction side-chain at current market price to pegged bitcoins... maybe. its a curious thing, each coin has a backed in explicit or implicit social contract. look at the litecoin splinter discussion - litecoin (scrypt) vs litecoin (new non-asic PoW) |
| 00:27:54 | adam3us: | maaku: cant really change. tho managed splintering might be possible (both litecoin variants can co-exist with different market rates afterwards) |
| 00:30:21 | phantomcircuit: | maaku, so you're working on that project? |
| 00:30:48 | phantomcircuit: | i assume you cant actually implement the logic for that entirely with existing script operators |
| 00:30:54 | phantomcircuit: | any idea what would need to change? |
| 00:31:41 | maaku: | phantomcircuit: yes |
| 00:32:25 | maaku: | pegging requires a small number of soft-fork script opcodes (two, at my last count, but it depends on how you choose to implement it) |
| 00:32:56 | gmaxwell: | phantomcircuit: depends on how general its done. It could just be an additional opcode OP_DOTHINGVERIFY plus an additional opcode for a more flexible kind of locktiming. |
| 00:33:06 | maaku: | however you very quickly run against hard limits on script size, which might end up being a problem |
| 00:33:22 | gmaxwell: | alternatively it could be implemented in a more flexible way. |
| 00:33:57 | sipa: | OP_X86 |
| 00:34:02 | phantomcircuit: | gmaxwell, lol @ OP |
| 00:34:14 | maaku: | phantomcircuit: pegging requires putting side-chain block headers inside the script, which gets quite large very fast |
| 00:34:46 | maaku: | there's a trick to make this scale O(log N), but it'll be a challenge to keep it within the 500-ish byte limit of OP_PUSH |
| 00:35:01 | sipa: | no need why it needs to be single push |
| 00:35:14 | phantomcircuit: | maaku, so basically the scriptpubkey part has a header and the input script has the rest of them to do an spv proof of somekind |
| 00:35:23 | maaku: | sipa: correct, but there's also whole script limits.. and you c |
| 00:35:34 | maaku: | ould split it over multiple txouts, but now we're starting to get messy... |
| 00:35:35 | phantomcircuit: | (i really have no idea so excuse my likely nonsensical questions) |
| 00:35:35 | gmaxwell: | phantomcircuit: personally I want to refresh bitcoin script in any case, but other people who have been focusing more exclusively on the peg almost certantly prefer a more focused change. |
| 00:36:01 | sipa: | phantomcircuit: you send bitcoins to a special script which can be unlocked using a spending SPV proof from the side chain |
| 00:36:17 | sipa: | phantomcircuit: the actual act of having such an output in bitcoin instantiates a coin in the side chain |
| 00:36:19 | maaku: | I'm with gmaxwell on script extensions, but I'm not speaking for the rest of adam3us' group in that |
| 00:36:54 | phantomcircuit: | sipa, "spending SPV proof" ie proof that you have destroyed them in the sidechain? |
| 00:36:59 | sipa: | phantomcircuit: yup |
| 00:36:59 | maaku: | phantomcircuit: yes |
| 00:37:06 | gmaxwell: | The problem with a script refresh is that it's very easy to go down a severe feature creep rathole. |
| 00:37:22 | phantomcircuit: | gmaxwell, everybody is going to want their own opcode |
| 00:37:40 | phantomcircuit: | i say we add an OP_PHANTOMCIRCUIT that pushes PHANTOMCIRCUIT to the stack |
| 00:37:48 | phantomcircuit: | all who oppose shall perish |
| 00:38:09 | maaku: | OP_PHANTOMCIRCUIT OP_DUP |
| 00:38:13 | kanzure: | is this an existential perishing, or is this the more real kind? |
| 00:38:33 | phantomcircuit: | eh real perishing sounds like real work |
| 00:38:33 | sipa: | we need OP_KIMOTOGRAVITYWELL, OP_QUARK, OP_QUANTUMCOMPUTER, ... |
| 00:38:47 | maaku: | imho we should be looking at a simplified, pure langage. and just add opcodes for the expensive crypto ops |
| 00:39:05 | gmaxwell: | maaku: I generally agree, though as you saw from my list that the expensive crypto ops is a long list. |
| 00:39:54 | maaku: | adam3us: the trouble with demurrage returning fee tokens (beyond the simple implementation issues) is that it is very different economic model than freicoin |
| 00:40:00 | maaku: | i don't think you would achieve 0% interest rates |
| 00:40:06 | phantomcircuit: | gmaxwell, is adding script ops really a soft fork? |
| 00:40:13 | maaku: | if there is any surplus of fee tokens that is |
| 00:40:16 | sipa: | phantomcircuit: OP_EVAL was a softfork |
| 00:40:23 | maaku: | phantomcircuit: if they are of a certain form |
| 00:40:24 | phantomcircuit: | oh right |
| 00:40:25 | gmaxwell: | phantomcircuit: yes. We can actually replace script entirely in a soft fork. (thats what P2SH did) |
| 00:40:26 | sipa: | phantomcircuit: with OP_EVAL you can create a new script language |
| 00:40:53 | gmaxwell: | (p2sh replaced script with ... nested script, so not the most creative of a change. :P ) |
| 00:41:05 | sipa: | hey hey |
| 00:41:13 | sipa: | it introduced more accurate sigop counting!!! |
| 00:42:12 | gmaxwell: | So I have a personal script 2.0 wishlist, but I've hesitated to make it public for some petty fear that it shows up as the advertised (but never to be implemeted) feature list for some altcoin. .. well also I'm hesitant to list features that other, wiser people, might someday convince me are better omited. |
| 00:44:50 | phantomcircuit: | oh right the pay to anybody fun |
| 00:44:58 | phantomcircuit: | i had forgotten how that was pulled off |
| 01:25:30 | [\\\\]: | [\\\\] is now known as [\\\] |
| 01:26:27 | phantomcircuit: | phantomcircuit is now known as Guest27267 |
| 02:43:57 | nsh_: | nsh_ is now known as nsh |
| 02:45:44 | artifexd_: | artifexd_ is now known as artifexd |
| 02:51:19 | amiller_: | amiller_ is now known as amiller |
| 02:51:49 | amiller: | amiller is now known as Guest89113 |
| 02:56:48 | midnightmagic: | gmaxwell: gimme gimme gimme, I want to read the list! :-) |
| 03:15:03 | Guest89113: | Guest89113 is now known as amiller_ |
| 03:23:40 | andytoshi: | i wonder if there is a mirror version of OWAS "aggregatable encryption", so gmaxwell could encrypt his list, and then everytime somebody asks he adds another decryptor to the set |
| 03:25:15 | amiller_: | if you have your own list of features you want in the scripting language, you should be able to do a private set intersection protocol with him to learn what you have in common |
| 03:25:38 | amiller_: | this would be another really good feature for CoinGen :3 |
| 03:28:04 | gmaxwell: | andytoshi: sounds like you're describing broadcast encryption. |
| 03:31:10 | andytoshi: | gmaxwell: oh, i am indeed, thx for the pointer |
| 03:54:45 | amiller_: | amiller_ is now known as amiller |
| 04:03:30 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 04:47:24 | amiller: | i came up with a catchy phrase, "law, log, and ledger: an abstraction of bitcoin as a platform" |
| 04:47:33 | amiller: | i am a fan of title-driven development |
| 04:49:18 | gmaxwell: | log and ledger may be redundantly redundant. |
| 04:50:32 | amiller: | ledger = index, log = blockchain |
| 04:50:40 | amiller: | i might use ledger wrong |
| 04:50:55 | amiller: | fuck, i think i am |
| 04:51:47 | amiller: | yeah ledgers have history and not just last balance |
| 04:53:01 | amiller: | i've been using that wrong for a really long time |
| 05:06:20 | gmaxwell: | amiller: another idea for storage centric pows. how about a pow where your data randomly selects a "query transaction", the query transaction has a public key and and an encrypted query. You use the public key and query to doe a PIR query of the storage database, you can commit to the encrypted database entries as you go to prove you did the work via NI cut and choose as your POW. |
| 05:06:39 | gmaxwell: | so you get a storage hard POW that pays you to go out and make ultra fast PIR query hardware for your database. |
| 05:07:52 | amiller: | ah so a noninteractive pir not just an ordinary fetch |
| 05:08:07 | amiller: | sounds.... really good to me actually |
| 05:08:37 | amiller: | whoever pays fees to get their public keys stored in the index would also be paying for proportional inclusion in this PIR subsidy |
| 05:08:41 | gmaxwell: | yea, I think computational PIR could be quite interesting with the right specialized hardware— basically dram with embedded encryption engines. |
| 05:09:24 | amiller: | i wonder if you could prove that the data is encrypted properly and the relevant public keys are valid |
| 05:10:19 | amiller: | i'm still kind of stuck on what sarah meiklejohn told me about my own storage thing, that for it to be a good scratch puzzle i really need to assume the data is always full or nearly full entropy |
| 05:10:44 | gmaxwell: | I think you can, the way that the CPIR I've played with works is that it encrypts the each record and does some homorphic sum in order to do polynomial interpolation over it. So if you just build a hashtree of the incremental products then you can sample from the tree (cut and choose wise) to convince people that the work was done faithfully. |
| 05:11:20 | amiller: | ok, well, good job inventing Pircoin |
| 05:11:32 | gmaxwell: | at least the PIR thing has the advantage (?) of moving the cost to the PIR encryption operations, which wouldn't I think have the problem with PRNG data. :P |
| 05:11:36 | amiller: | pronounced 'peercoin' i guess just to piss people off |
| 05:12:23 | gmaxwell: | ISTM that fast CPIR is like timelock crypto... something that isn't likely to exist without some crazy external motivation to make it happen. |
| 05:13:29 | amiller: | you'd have the problem too that either a) everyone has the same database, or b) there's sharding, in which case people might just steer away from storing *your* data |
| 05:14:00 | amiller: | the problem iwth a) is that then it has to be pretty small for solo miners to feasibly do it |
| 05:14:46 | amiller: | the design around this in permacoin is to massively erasure-code everything |
| 05:16:08 | gmaxwell: | right, but degrees of freedom are degrees of freedom if some fraction of the data you're supposted to be storing is at all combined with PRNG data you know, you can reduce your storage. |
| 05:20:47 | amiller: | those are two unrelated concerns - even if 99% of the data is high entropy and you can't herd your random assigned subset to get an advantage solving the puzzle, you could still have a case where people avoid storing the segment of data thought to contain contraband data + wikileaks files |
| 05:22:57 | gmaxwell: | some related thoughts you might have some thinking about— I was discussing this with petertodd a bit ago. |
| 05:23:47 | gmaxwell: | So imagine a future where there are relatively full fully validating nodes, but a lot of nodes that randomly sample blocks and validate a bit— and if they find bad data they flood fraud proofs, compact extracts showing where the badness is (see the long writeup on my features page). |
| 05:24:27 | amiller: | relatively few fully validating nodes* right? clear so far |
| 05:24:38 | gmaxwell: | One problem is that if you assume that normally these nodes are only sampling, you could have conspiring dishonest nodes always disconnect peers if they happen to sample the one bit of the block where the fraud exists. Of course, you'd personally ban the peer who didn't respond, but you couldn't produce a fraud proof. |
| 05:25:59 | gmaxwell: | So a thought I had was that if all the nodes were required to erasure code their blocks with a locally decodable infinite rate code, then you could make it so that once you'd transmitted a blocks worth of data to peers it was very likely that the peers (if they were really one party or shared data) could recover the whole block, and you couldn't prevent them except by never serving much data at all. |
| 05:27:03 | gmaxwell: | sort of like an information theoretic PIR, except for censorship prevention instead of hiding the data being queried.. |
| 05:27:14 | amiller: | hmm. |
| 05:28:04 | amiller: | that's really interesting, it means at least that a node requesting block data is actually requesting coded data that might benefit another peer |
| 05:28:52 | gmaxwell: | Right, plus this notion that if Alice requests data that can decode A and bob requests data that can decode B ... if they pool their data they can jointly decode A, B, C C being the censored data. |
| 05:29:18 | gmaxwell: | (as they're all requesting a bit more than the information theoretic minimum, as is required by the coding scheme anyways) |
| 05:29:43 | amiller: | is there any way to argue there's a local incentive to want the coded data rather than plain |
| 05:29:45 | gmaxwell: | and basically there is no way to prevent C from being recovered without extremely constraining the values you allow parties to read. |
| 05:30:19 | gmaxwell: | well there are some interesting incentives. For example if the data is always coded demands to censor it are kind of moot.. it makes the whole system more all or nothing. |
| 05:30:28 | gmaxwell: | it also enables peer-parallelism. |
| 05:30:47 | amiller: | if i have a list of a peers, maybe i have a local incentive to ask Peer 0 for the coded data |
| 05:30:55 | gmaxwell: | e.g. I can request fractions of a block from many peers. if I ultimately want the whole block. |
| 05:31:10 | amiller: | because if i can show my other peers that i was asking for data that's partially coded for them, then they'll know i'm helping them |
| 05:31:14 | amiller: | and likewise all around |
| 05:31:38 | amiller: | and, i should still be getting the full bandwidth if i get it equally from all of them |
| 05:35:21 | gmaxwell: | amiller: yea, I wrote about the bandwidth/latency potentials of coded blocks earlier today: https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding |
| 05:36:07 | gmaxwell: | in particular I use it to address the "How do you take advantage of the fact that your peers know 95% of the transactions in a block already, but you don't know which for sure without additional round trips?" |
| 05:36:35 | gmaxwell: | but this notion of setting it up to achieve a kind of all or nothing anti-censorship property is kinda different. |
| 05:37:48 | amiller: | right, that idea is coding along transactions rather than along per-peer requests |
| 05:38:05 | gmaxwell: | right. |
| 05:39:46 | gmaxwell: | I suggest a somewhat clever(?) thing to help nodes figure out the locations in the block for their known transactions which is more efficient than just sending the whole tx list. (the smart-ish part is making it attack resistant by using the block hash as a challenge to randomize the txids) |
| 05:40:38 | gmaxwell: | e.g. if you only send the first 32 bits of every transaction to map the transactions to their positions some wiseass can start grinding transactions to collide and giving you some exponential complexity in your decoder. |
| 05:58:00 | [\\\]: | [\\\] is now known as `0 |
| 06:02:18 | `0: | `0 is now known as [\\\] |
| 06:54:14 | wump: | wump is now known as wumpus |
| 10:35:35 | airbreather_1: | airbreather_1 is now known as airbreather |
| 12:12:49 | rodarmor: | gmaxwell: Regarding the sidechain proposal, might it be possible that the best way to go about it would be to make the current bitcoin mainnet itself a sidechain in the new “pegged chains” world? That way the new “main” chain could be optimized for the purpose. (For example by lowering the block size to reduce centralization, or any number of hardfork wishlist items that are risky.) The new “main” chain could be developed |
| 12:12:50 | rodarmor: | until everyone was confident in it, with the last step being to introduce convertability to the current mainnet, making it a convertible sidechain of the new main chain. |
| 12:15:35 | Luke-Jr: | rodarmor: wouldn't work as a softfork at least |
| 12:16:13 | rodarmor: | Luke-Jr: Right, it would be an eventual hard fork to mainnet. |
| 12:16:41 | Luke-Jr: | currently the plan is to deploy this as a softfork |
| 12:17:27 | rodarmor: | Oh? I was under the impression that it would require a hard fork. |
| 12:18:13 | sipa: | s/plan/hope/ |
| 12:18:36 | sipa: | it doesn't technically require a hard fork, though there may be some benefits to doing it as one |
| 12:19:20 | sipa: | also, yes, it can perfectly well be used to bootstrap a new chain that is intended to replace the main one as basic currency one |
| 12:19:29 | sipa: | if it fails, you can still move back :) |
| 12:19:35 | sipa: | without losses for anyone involved |
| 12:20:20 | rodarmor: | Is there a writeup or a mailing list discussion which goes into more depth about different possible implementation approaches? I’ve only read the non-technical stuff so far. (LTB writeup, etc) |
| 12:20:28 | Luke-Jr: | sipa: I think he was proposing making the *current* main chain into one of the side chains ;) |
| 12:21:49 | Luke-Jr: | rodarmor: AFAIK most of the technical discussion was meatspace |
| 12:22:04 | Luke-Jr: | .. or lizardspace if you prefer :P |
| 12:22:16 | rodarmor: | That’s okay, I’ll just get the recordings from the NSA. |
| 12:22:38 | Luke-Jr: | can I have a copy? |
| 12:23:39 | rodarmor: | I’ll give them to my friend Snowden and he can make copies for everyone. |
| 12:45:04 | mike4: | mike4 is now known as money |
| 13:57:23 | pyramid: | pyramid has left #bitcoin-wizards |
| 14:49:08 | austinhill: | Picture of the #bitcoin-lizards enjoying the sun while working on the concept of side chains & two-way pegs http://instagram.com/p/lk3-u_Aari/ |
| 14:53:02 | Luke-Jr: | pfft, you leaked our secret channel |
| 14:54:57 | austinhill: | sorry folks type - surely I meant #bticoin-wizards |
| 15:00:17 | Alanius_: | Alanius_ is now known as Alanius |
| 15:34:36 | licnep_: | licnep_ is now known as licnep |
| 15:56:41 | maaku: | and the rumors start about that mysterious man in red ;) |
| 15:59:05 | arubi: | hmm? background please? |
| 16:02:59 | gmaxwell: | yes, he was indeed in the background. |
| 16:03:39 | arubi: | I meant context :( |
| 16:05:07 | gmaxwell: | it was wrt this picture: http://instagram.com/p/lk3-u_Aari/ |
| 16:05:34 | sipa: | I am incognito! |
| 16:05:36 | sipa: | *oops* |
| 16:05:43 | arubi: | obviously it's satoshi |
| 16:53:18 | Guest27267: | Guest27267 is now known as phantomcircuit |
| 18:53:53 | amiller: | you might like this paper gmaxwell http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=939E3ACA71E48347754682F07D58EEAC?doi=10.1.1.19.178&rep=rep1&type=pdf but i'm stil trying to figure out what it means |
| 18:54:23 | amiller: | "We then introduce approximation reconciliation trees, a more computationally efficient solution that combines techniques from Patri-cia tries, Merkle trees, and Bloom Flters" |
| 18:55:43 | BlueMatt: | amiller: E_BADLINK |
| 18:55:55 | amiller: | fk |
| 18:56:21 | amiller: | http://open-test.bu.edu/xmlui/bitstream/handle/2144/1469/2002-019-approx-reconciliation.pdf?sequence=1 |
| 18:56:46 | BlueMatt: | better :) |
| 19:38:20 | maaku: | thanks amiller, interesting paper |
| 20:15:42 | SrPx: | Would it be possible to create a system where random users deposit money in a wallet, that wallet is not accessible by anyone for 2 months, then those users vote in other wallets for that money to be distributed in? |
| 20:16:15 | SrPx: | In top of bitcoin, or as an altcoin, or as a sidecoin, or with ethereum, I don't know, I'm a newbie. How would that just be possible? |
| 20:17:01 | maaku: | SrPx: first read the developer guide and learn the difference between wallet (doesn't exist at the protocol level) and addresses and outputs |
| 20:17:46 | SrPx: | I will, you just distracted me with your information hammer ... sorry |
| 20:18:40 | maaku: | you also need to figure out what sort of voting mechanism meets your needs, and how to keep it secure against sybil attacks |
| 20:20:12 | sipa: | SrPx: don't try to do intergalactic space travel before learning how to walk |
| 20:20:32 | sipa: | answers will come |
| 20:31:32 | hanncx: | hanncx has left #bitcoin-wizards |
| 20:34:53 | BCB: | Alan Reiner's naming names....http://vid.ly/7h6w6m <-- dev panel from PrincetonBTC |
| 20:53:17 | amiller: | naming names? |
| 20:57:02 | hearn: | superb |
| 20:57:03 | hearn: | https://bitcointalk.org/index.php?topic=173220.msg6160307#msg6160307 |
| 20:57:12 | hearn: | sounds like they finally cracked SSL auditing |
| 20:57:24 | hearn: | only catch this time is, doesn’t work with tls 1.2. but servers will fall back |
| 20:58:51 | hearn: | i think we have every component we need now for a truly decentralised exchange |
| 21:01:45 | nsh: | so you can prove the bank sent you some html that looks kinda like a deposit happened because the html is signed by the bank? therefore people can send you bitcoin and not worry that you'll renege |
| 21:01:48 | nsh: | ? |
| 21:02:08 | hearn: | yes |
| 21:02:13 | hearn: | that’s the theory |
| 21:02:21 | nsh: | * nsh expects complications :) |
| 21:02:25 | hearn: | of course the devil is in the details (i.e. some banks let you submit a wire transfer then cancel it before it commits) |
| 21:02:30 | nsh: | * nsh nods |
| 21:02:40 | hearn: | but in theory, you should be able to reveal your account statement to an auditor but ONLY if there’s a dispute |
| 21:03:03 | nsh: | that's desirable |
| 21:04:33 | nsh: | also not entirely unlikely that bankco inc. will run this past their legal team resulting in a big bucket of nope! |
| 21:05:05 | nsh: | (because of inferred legal liability or insurance or audit or other repercussions) |
| 21:08:47 | hearn: | they can’t detect it’s happening |
| 21:08:54 | hearn: | what they can see is an account which suddenly does lots of wire transfers |
| 21:09:01 | hearn: | obviously. but they can’t know you’re being audited |
| 21:14:48 | nsh: | right |
| 21:51:46 | c0rw|away: | c0rw|away is now known as c0rw1n |
| 22:12:56 | gmaxwell: | amiller: thats a pretty funky datastructure... though it's one round of communication and I want zero. :) |
| 22:13:46 | maaku: | gmaxwell: zero? don't you need to communicate your filter? |
| 22:14:30 | amiller: | not with swanky network coding you don't |
| 22:20:03 | gmaxwell: | maaku: I describe a zero round approach here: https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding which should allow you send just s small amount more than the missing data, without knowing precisely whats missing. |
| 22:20:46 | gmaxwell: | So you can make a moderately conservative guess based on past inv/getdata messages "I think this peer has 90% of the block already", and be successful a high percent of the time. |
| 22:21:46 | amiller: | gmaxwell, if you can make a weighted/probabilistic guess about which actual transactions they already have, can you improve that? |
| 22:22:30 | gmaxwell: | yes sure, the better the guess the closer you can come to sending the actual amount of missing data without hurting your success rate. |
| 22:23:05 | gmaxwell: | Though I think in practice you'll always be conservative to avoid the latency... and still get a huge amount of savings since the peer will have something like 95% of the block already. |
| 22:25:34 | amiller: | it's baiscally for free right, like you might/probably will get the block on the first pass, and if not then they'll ask for it and indicate which txs they need? |
| 22:25:43 | amiller: | so guaranteed it takes no longer than it does right now |
| 22:26:03 | amiller: | right now it's inv(block), getdata(wholeblock), then block(all the texs) |
| 22:26:19 | amiller: | now it would be inv(best guess of what you need), getdata(exactly what's missing), then block(just what's missing) |
| 22:35:57 | phantomcircuit: | gmaxwell, conservative -> send them everything just in the order you think is most likely to result in rapid processing? |
| 22:37:04 | gmaxwell: | phantomcircuit: there really is no need to, you can be very confident that they at least have the most recent transactions they inved to you. you really don't have to send them all. |
| 22:37:41 | phantomcircuit: | gmaxwell, sure... but im probably still going to |
| 22:37:41 | gmaxwell: | surely someone who didn't care about bandwidth could signal to you "I don't care about bandwidth, send me extra just to be sure". |
| 22:38:22 | phantomcircuit: | actually i should probably stop pushing blocks to bitcoinj peers... |
| 22:38:28 | gmaxwell: | but thats not really a good solution network wide, right now the current behavior doubles the nodes bandwidth usage... and also makes it hard for lower bandwidth nodes to participate in effective block relaying at all. |
| 22:39:41 | gmaxwell: | phantomcircuit: somewhere I have an old patch that uses move to front coding to adjust the order you send blocks to peers to... any time a peer is the first to announce a block to you, you move them to the front of the send list. |
| 22:40:13 | gmaxwell: | so that results in naturally moving all those bitcoinj nodes to the end of the line. |
| 22:40:18 | phantomcircuit: | gmaxwell, that would probably be good for normal peers |
| 22:40:47 | phantomcircuit: | this is a simple server that just sends anything it receives from a whitelist to every peer it's connected to |
| 22:41:22 | gmaxwell: | really if you're not going send blocks to the non-fullnodes you should probably hang up on them to avoid wasiting their connections. |
| 22:41:46 | phantomcircuit: | gmaxwell, well right now it sends the full unfiltered block to them |
| 22:41:55 | phantomcircuit: | fortunately it only has like 3 bitcoinj peers |
| 22:44:30 | phantomcircuit: | shit |
| 23:06:18 | maaku: | maaku is now known as Guest9917 |
| 23:07:05 | Guest9917: | Guest9917 is now known as maaku |
| 23:31:44 | emsid: | emsid is now known as MOONPLS |