00:03:21adam3us: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:59adam3us:usually reddit is like bottom of the list for rational or non-idiotic discussion vs bitcointalk, slashdot etc
00:04:11andytoshi:top post right now is
00:04:51sipa:adam3us: herd behaviour :)
00:05:13adam3us:andytoshi: ah thats better
00:05:44sipa:i was not aware of that meaning of the word :)
00:07:10gmaxwell: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:28adam3us:gmaxwell andytoshi: yuck thanks for that. #bitcoin-wizards sinks below reddit/r/bitcoin :)
00:10:42midnightmagic:sigh. one more common term appropriated into innuendo-land.
00:12:13nsh:andytoshi-logbot, pointer?
00:12:13nsh:See http://download.wpsoftware.net/bitcoin/wizards/2014-04-10#T00-12-13
00:12:21nsh:oh, nice. that was a total crapshoot
00:12:51nsh:(would be nicer if it wasn't 404, but hey..)
00:13:01andytoshi:oh, damn, i should fix that..
00:13:14nsh:just needs .txt
00:13:31nsh:but the anchors would work better if you html formatted the logs. on the other hand, ugh, effort
00:17:53rajaniemi.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:53rajaniemi.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:54rajaniemi.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:54rajaniemi.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:54maaku:phantomcircuit: yeah, well some PR points need to be pushed
00:22:04maaku:also, /me needs a new name for freicoin-like currencies which have economic differences from bitcoin
00:22:17maaku:since alts are dirty and are gonna die
00:23:39gmaxwell: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:28andytoshi:to that point, i wonder if a marketing push into the tumblr/occupy world would be worthwhile
00:25:19andytoshi: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:36nsh:maybe Maine and Texas have nothing to communicate
00:27:05adam3us: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:54adam3us:maaku: cant really change. tho managed splintering might be possible (both litecoin variants can co-exist with different market rates afterwards)
00:30:21phantomcircuit:maaku, so you're working on that project?
00:30:48phantomcircuit:i assume you cant actually implement the logic for that entirely with existing script operators
00:30:54phantomcircuit:any idea what would need to change?
00:31:41maaku:phantomcircuit: yes
00:32:25maaku: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:56gmaxwell: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:06maaku:however you very quickly run against hard limits on script size, which might end up being a problem
00:33:22gmaxwell:alternatively it could be implemented in a more flexible way.
00:34:02phantomcircuit:gmaxwell, lol @ OP
00:34:14maaku:phantomcircuit: pegging requires putting side-chain block headers inside the script, which gets quite large very fast
00:34:46maaku: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:01sipa:no need why it needs to be single push
00:35:14phantomcircuit: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:23maaku:sipa: correct, but there's also whole script limits.. and you c
00:35:34maaku:ould split it over multiple txouts, but now we're starting to get messy...
00:35:35phantomcircuit:(i really have no idea so excuse my likely nonsensical questions)
00:35:35gmaxwell: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:01sipa:phantomcircuit: you send bitcoins to a special script which can be unlocked using a spending SPV proof from the side chain
00:36:17sipa:phantomcircuit: the actual act of having such an output in bitcoin instantiates a coin in the side chain
00:36:19maaku:I'm with gmaxwell on script extensions, but I'm not speaking for the rest of adam3us' group in that
00:36:54phantomcircuit:sipa, "spending SPV proof" ie proof that you have destroyed them in the sidechain?
00:36:59sipa:phantomcircuit: yup
00:36:59maaku:phantomcircuit: yes
00:37:06gmaxwell:The problem with a script refresh is that it's very easy to go down a severe feature creep rathole.
00:37:22phantomcircuit:gmaxwell, everybody is going to want their own opcode
00:37:40phantomcircuit:i say we add an OP_PHANTOMCIRCUIT that pushes PHANTOMCIRCUIT to the stack
00:37:48phantomcircuit:all who oppose shall perish
00:38:13kanzure:is this an existential perishing, or is this the more real kind?
00:38:33phantomcircuit:eh real perishing sounds like real work
00:38:47maaku:imho we should be looking at a simplified, pure langage. and just add opcodes for the expensive crypto ops
00:39:05gmaxwell:maaku: I generally agree, though as you saw from my list that the expensive crypto ops is a long list.
00:39:54maaku: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:00maaku:i don't think you would achieve 0% interest rates
00:40:06phantomcircuit:gmaxwell, is adding script ops really a soft fork?
00:40:13maaku:if there is any surplus of fee tokens that is
00:40:16sipa:phantomcircuit: OP_EVAL was a softfork
00:40:23maaku:phantomcircuit: if they are of a certain form
00:40:24phantomcircuit:oh right
00:40:25gmaxwell:phantomcircuit: yes. We can actually replace script entirely in a soft fork. (thats what P2SH did)
00:40:26sipa:phantomcircuit: with OP_EVAL you can create a new script language
00:40:53gmaxwell:(p2sh replaced script with ... nested script, so not the most creative of a change. :P )
00:41:05sipa:hey hey
00:41:13sipa:it introduced more accurate sigop counting!!!
00:42:12gmaxwell: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:50phantomcircuit:oh right the pay to anybody fun
00:44:58phantomcircuit:i had forgotten how that was pulled off
01:25:30[\\\\]:[\\\\] is now known as [\\\]
01:26:27phantomcircuit:phantomcircuit is now known as Guest27267
02:43:57nsh_:nsh_ is now known as nsh
02:45:44artifexd_:artifexd_ is now known as artifexd
02:51:19amiller_:amiller_ is now known as amiller
02:51:49amiller:amiller is now known as Guest89113
02:56:48midnightmagic:gmaxwell: gimme gimme gimme, I want to read the list! :-)
03:15:03Guest89113:Guest89113 is now known as amiller_
03:23:40andytoshi: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:15amiller_: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:38amiller_:this would be another really good feature for CoinGen :3
03:28:04gmaxwell:andytoshi: sounds like you're describing broadcast encryption.
03:31:10andytoshi:gmaxwell: oh, i am indeed, thx for the pointer
03:54:45amiller_:amiller_ is now known as amiller
04:03:30ghtdak:ghtdak has left #bitcoin-wizards
04:47:24amiller:i came up with a catchy phrase, "law, log, and ledger: an abstraction of bitcoin as a platform"
04:47:33amiller:i am a fan of title-driven development
04:49:18gmaxwell:log and ledger may be redundantly redundant.
04:50:32amiller:ledger = index, log = blockchain
04:50:40amiller:i might use ledger wrong
04:50:55amiller:fuck, i think i am
04:51:47amiller:yeah ledgers have history and not just last balance
04:53:01amiller:i've been using that wrong for a really long time
05:06:20gmaxwell: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:39gmaxwell: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:52amiller:ah so a noninteractive pir not just an ordinary fetch
05:08:07amiller:sounds.... really good to me actually
05:08:37amiller: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:41gmaxwell:yea, I think computational PIR could be quite interesting with the right specialized hardware— basically dram with embedded encryption engines.
05:09:24amiller:i wonder if you could prove that the data is encrypted properly and the relevant public keys are valid
05:10:19amiller: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:44gmaxwell: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:20amiller:ok, well, good job inventing Pircoin
05:11:32gmaxwell: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:36amiller:pronounced 'peercoin' i guess just to piss people off
05:12:23gmaxwell: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:29amiller: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:00amiller:the problem iwth a) is that then it has to be pretty small for solo miners to feasibly do it
05:14:46amiller:the design around this in permacoin is to massively erasure-code everything
05:16:08gmaxwell: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:47amiller: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:57gmaxwell:some related thoughts you might have some thinking about— I was discussing this with petertodd a bit ago.
05:23:47gmaxwell: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:27amiller:relatively few fully validating nodes* right? clear so far
05:24:38gmaxwell: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:59gmaxwell: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:03gmaxwell:sort of like an information theoretic PIR, except for censorship prevention instead of hiding the data being queried..
05:28:04amiller: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:52gmaxwell: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:18gmaxwell:(as they're all requesting a bit more than the information theoretic minimum, as is required by the coding scheme anyways)
05:29:43amiller:is there any way to argue there's a local incentive to want the coded data rather than plain
05:29:45gmaxwell:and basically there is no way to prevent C from being recovered without extremely constraining the values you allow parties to read.
05:30:19gmaxwell: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:28gmaxwell:it also enables peer-parallelism.
05:30:47amiller:if i have a list of a peers, maybe i have a local incentive to ask Peer 0 for the coded data
05:30:55gmaxwell:e.g. I can request fractions of a block from many peers. if I ultimately want the whole block.
05:31:10amiller: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:14amiller:and likewise all around
05:31:38amiller:and, i should still be getting the full bandwidth if i get it equally from all of them
05:35:21gmaxwell: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:07gmaxwell: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:35gmaxwell:but this notion of setting it up to achieve a kind of all or nothing anti-censorship property is kinda different.
05:37:48amiller:right, that idea is coding along transactions rather than along per-peer requests
05:39:46gmaxwell: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:38gmaxwell: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:14wump:wump is now known as wumpus
10:35:35airbreather_1:airbreather_1 is now known as airbreather
12:12:49rodarmor: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:50rodarmor: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:35Luke-Jr:rodarmor: wouldn't work as a softfork at least
12:16:13rodarmor:Luke-Jr: Right, it would be an eventual hard fork to mainnet.
12:16:41Luke-Jr:currently the plan is to deploy this as a softfork
12:17:27rodarmor:Oh? I was under the impression that it would require a hard fork.
12:18:36sipa:it doesn't technically require a hard fork, though there may be some benefits to doing it as one
12:19:20sipa: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:29sipa:if it fails, you can still move back :)
12:19:35sipa:without losses for anyone involved
12:20:20rodarmor: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:28Luke-Jr:sipa: I think he was proposing making the *current* main chain into one of the side chains ;)
12:21:49Luke-Jr:rodarmor: AFAIK most of the technical discussion was meatspace
12:22:04Luke-Jr:.. or lizardspace if you prefer :P
12:22:16rodarmor:That’s okay, I’ll just get the recordings from the NSA.
12:22:38Luke-Jr:can I have a copy?
12:23:39rodarmor:I’ll give them to my friend Snowden and he can make copies for everyone.
12:45:04mike4:mike4 is now known as money
13:57:23pyramid:pyramid has left #bitcoin-wizards
14:49:08austinhill: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:02Luke-Jr:pfft, you leaked our secret channel
14:54:57austinhill:sorry folks type - surely I meant #bticoin-wizards
15:00:17Alanius_:Alanius_ is now known as Alanius
15:34:36licnep_:licnep_ is now known as licnep
15:56:41maaku:and the rumors start about that mysterious man in red ;)
15:59:05arubi:hmm? background please?
16:02:59gmaxwell:yes, he was indeed in the background.
16:03:39arubi:I meant context :(
16:05:07gmaxwell:it was wrt this picture: http://instagram.com/p/lk3-u_Aari/
16:05:34sipa:I am incognito!
16:05:43arubi:obviously it's satoshi
16:53:18Guest27267:Guest27267 is now known as phantomcircuit
18:53:53amiller:you might like this paper gmaxwell http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=939E3ACA71E48347754682F07D58EEAC?doi= but i'm stil trying to figure out what it means
18:54:23amiller:"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:43BlueMatt:amiller: E_BADLINK
18:56:46BlueMatt:better :)
19:38:20maaku:thanks amiller, interesting paper
20:15:42SrPx: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:15SrPx: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:01maaku: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:46SrPx:I will, you just distracted me with your information hammer ... sorry
20:18:40maaku: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:12sipa:SrPx: don't try to do intergalactic space travel before learning how to walk
20:20:32sipa:answers will come
20:31:32hanncx:hanncx has left #bitcoin-wizards
20:34:53BCB:Alan Reiner's naming names....http://vid.ly/7h6w6m <-- dev panel from PrincetonBTC
20:53:17amiller:naming names?
20:57:12hearn:sounds like they finally cracked SSL auditing
20:57:24hearn:only catch this time is, doesn’t work with tls 1.2. but servers will fall back
20:58:51hearn:i think we have every component we need now for a truly decentralised exchange
21:01:45nsh: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:02:13hearn:that’s the theory
21:02:21nsh:* nsh expects complications :)
21:02:25hearn: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:30nsh:* nsh nods
21:02:40hearn:but in theory, you should be able to reveal your account statement to an auditor but ONLY if there’s a dispute
21:03:03nsh:that's desirable
21:04:33nsh:also not entirely unlikely that bankco inc. will run this past their legal team resulting in a big bucket of nope!
21:05:05nsh:(because of inferred legal liability or insurance or audit or other repercussions)
21:08:47hearn:they can’t detect it’s happening
21:08:54hearn:what they can see is an account which suddenly does lots of wire transfers
21:09:01hearn:obviously. but they can’t know you’re being audited
21:51:46c0rw|away:c0rw|away is now known as c0rw1n
22:12:56gmaxwell:amiller: thats a pretty funky datastructure... though it's one round of communication and I want zero. :)
22:13:46maaku:gmaxwell: zero? don't you need to communicate your filter?
22:14:30amiller:not with swanky network coding you don't
22:20:03gmaxwell: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:46gmaxwell: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:46amiller:gmaxwell, if you can make a weighted/probabilistic guess about which actual transactions they already have, can you improve that?
22:22:30gmaxwell: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:05gmaxwell: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:34amiller: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:43amiller:so guaranteed it takes no longer than it does right now
22:26:03amiller:right now it's inv(block), getdata(wholeblock), then block(all the texs)
22:26:19amiller:now it would be inv(best guess of what you need), getdata(exactly what's missing), then block(just what's missing)
22:35:57phantomcircuit:gmaxwell, conservative -> send them everything just in the order you think is most likely to result in rapid processing?
22:37:04gmaxwell: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:41phantomcircuit:gmaxwell, sure... but im probably still going to
22:37:41gmaxwell: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:22phantomcircuit:actually i should probably stop pushing blocks to bitcoinj peers...
22:38:28gmaxwell: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:41gmaxwell: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:13gmaxwell:so that results in naturally moving all those bitcoinj nodes to the end of the line.
22:40:18phantomcircuit:gmaxwell, that would probably be good for normal peers
22:40:47phantomcircuit:this is a simple server that just sends anything it receives from a whitelist to every peer it's connected to
22:41:22gmaxwell: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:46phantomcircuit:gmaxwell, well right now it sends the full unfiltered block to them
22:41:55phantomcircuit:fortunately it only has like 3 bitcoinj peers
23:06:18maaku:maaku is now known as Guest9917
23:07:05Guest9917:Guest9917 is now known as maaku
23:31:44emsid:emsid is now known as MOONPLS