--- Log opened Fri Aug 04 00:00:39 2017
00:02 -!- rmwb [~rmwb@2001:df0:ce:1601:6d41:9b36:2287:23c] has quit []
00:10 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
00:28 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 276 seconds]
00:30 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-vbfdimrtmlguqboy] has joined #bitcoin-wizards
00:39 -!- http_GK1wmSU [~deep-book@61-68.furanet.com] has joined #bitcoin-wizards
00:40 -!- http_GK1wmSU [~deep-book@61-68.furanet.com] has left #bitcoin-wizards []
01:01 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-wizards
01:01 -!- Giszmo1 [~leo@ppp-88-217-108-210.dynamic.mnet-online.de] has quit [Quit: Leaving.]
01:03 -!- Giszmo [~leo@ppp-88-217-108-210.dynamic.mnet-online.de] has joined #bitcoin-wizards
01:14 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
01:19 -!- daszorz [~daszorz@188.94.18.118] has joined #bitcoin-wizards
01:20 -!- Lamby_ [~Lamby_@unaffiliated/lamby/x-3301603] has joined #bitcoin-wizards
01:24 -!- harrow [~harrow@68.ip-149-56-14.net] has quit [Quit: Leaving]
01:24 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire]
01:27 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-wizards
01:33 -!- harrow [~harrow@68.ip-149-56-14.net] has joined #bitcoin-wizards
01:42 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
01:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
01:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit]
01:48 -!- daszorz [~daszorz@188.94.18.118] has quit [Ping timeout: 255 seconds]
01:49 -!- daszorz [~daszorz@remote.birchwoodpark.co.uk] has joined #bitcoin-wizards
02:03 -!- yRDIUTgn [~YRxcrYTVB@2a02:2f0a:b0a0:857:ff57:a224:17bd:a712] has quit [Ping timeout: 255 seconds]
02:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
02:12 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .]
02:14 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-wizards
02:16 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Remote host closed the connection]
02:16 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-wizards
02:26 -!- onabreak [55e4c13c@gateway/web/freenode/ip.85.228.193.60] has joined #bitcoin-wizards
02:26 -!- brg444 [sid207215@gateway/web/irccloud.com/x-pbrwlibkjykanuzw] has quit []
02:26 -!- brg444 [sid207215@gateway/web/irccloud.com/x-olpvbyyyfivkvllx] has joined #bitcoin-wizards
02:47 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 260 seconds]
02:48 -!- daszorz [~daszorz@remote.birchwoodpark.co.uk] has quit [Read error: Connection reset by peer]
02:59 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
03:03 -!- daszorz [~daszorz@188.94.18.118] has joined #bitcoin-wizards
03:14 -!- Uglux [~uglux@unaffiliated/uglux] has joined #bitcoin-wizards
03:19 -!- Giszmo [~leo@ppp-88-217-108-210.dynamic.mnet-online.de] has quit [Quit: Leaving.]
03:21 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 276 seconds]
03:25 -!- Giszmo [~leo@ppp-88-217-108-210.dynamic.mnet-online.de] has joined #bitcoin-wizards
03:33 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
03:59 -!- Guest31089 [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has quit [Read error: Connection reset by peer]
04:00 -!- prime_ [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
04:13 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has joined #bitcoin-wizards
04:14 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
04:16 -!- Giszmo [~leo@ppp-88-217-108-210.dynamic.mnet-online.de] has quit [Quit: Leaving.]
04:19 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 240 seconds]
04:19 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
04:19 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-wizards
04:31 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
04:32 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
04:33 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Remote host closed the connection]
04:35 -!- http_GK1wmSU [~deep-book@2e.80.01a8.ip4.static.sl-reverse.com] has joined #bitcoin-wizards
04:35 -!- http_GK1wmSU [~deep-book@2e.80.01a8.ip4.static.sl-reverse.com] has left #bitcoin-wizards []
04:41 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards
04:57 -!- Nightw0lf [~Nightwolf@v2201412760721964.yourvserver.net] has joined #bitcoin-wizards
04:57 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards
05:00 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
05:00 -!- Guyver2_ is now known as Guyver2
05:04 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
05:20 -!- Uglux [~uglux@unaffiliated/uglux] has quit [Quit: Leaving]
05:20 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]
05:29 -!- deusexbeer [~deusexbee@093-092-180-191-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 276 seconds]
05:33 -!- deusexbeer [~deusexbee@093-092-180-140-dynamic-pool-adsl.wbt.ru] has joined #bitcoin-wizards
05:43 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
05:43 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has quit [Ping timeout: 240 seconds]
05:47 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
06:23 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-wizards
06:25 -!- brothchide [~brothchid@109.202.102.88] has joined #bitcoin-wizards
06:26 < brothchide> hi, why does every new node have to validate every transaction from the last 9 years in order to sync?   if all they are doing is generating UTXO set, then there has to be a way to just deliver a trusted UTXO to the client instead of making them derive it all?
06:26 < andytoshi> because bitcoin is trustless
06:28 < nsh> well, that's a tiny bit glib. there's no a priori reason why historical transactions past a certain time can't be elided but it does require a more complexity
06:29 < nsh> s/a more/more/
06:30 < brothchide> why couldnt there be something IN the blocks that makes is you could somehow trustlessly get UTXO signature or something (im not very technical, pardon me).
06:31 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]
06:32 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has joined #bitcoin-wizards
06:32 < andytoshi> brothchide: that's a very hard research question. you might want to look into mimblewimble which improves on this situation at great cost in flexibility
06:33 < brothchide> andytoshi is is true that moving in a direction towards UTXO reliance is bad for side chains and stuff?
06:33 < brothchide> is it
06:33 < andytoshi> basically because you need to prove that the UTXO set was obtained by a series of valid transactions, and proving that transactions are valid is cryptographically hard except by just providing the transaction and having people validate the whole thing
06:33 < brothchide> could that be a reason why it hasnt much movement?
06:33 < andytoshi> brothchide: no, that sounds confused, i'm not sure what it means even
06:34 -!- harrymm [~wayne@60-249-14-203.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds]
06:34 < brothchide> "It is clear how UTXOs do not mesh well with stateful smart contracts: if there is a need to create a contract with multiple phases, eg. where multiple parties must provide some form of input, then after some period of time those parties must perform some additional operation, and then finally the "
06:35 < brothchide> "2. UTXOs are stateless, and so are not well-suited to applications more complex than asset issuance and transfer that are generally stateful, such as various kinds of smart contracts.
06:35 < brothchide> "
06:35 < andytoshi> that sounds like confused ethereum talk, there is no need for contract state to ever interact with a blockchain except to be committed sometimes
06:35 < brothchide> well i know blockstream was big about sidechains, you have to think they want smart contracts?
06:36 < andytoshi> did i suggest otherwise?
06:36 < brothchide> im just wondering if there is any other ulterior motive why we aren't syncing with UTXO better
06:36 < andytoshi> lol no
06:36 < brothchide> ok
06:36 < brothchide> thanks bro
06:37 < andytoshi> brothchide: i have a mimblewimble talk https://www.youtube.com/watch?v=aHTRlbCaUyM which describes a little bit why fast UTXO-validation is hard and what mimblewimble sacrifices to get around the difficulty
06:37 -!- jcluck is now known as cluckj
06:38 < brothchide> andytoshi thanks, you're probably a few levels over my head, like i said im not very technical.  but i have a big imagination.
06:41 -!- harrymm [~wayne@125-227-200-197.HINET-IP.hinet.net] has joined #bitcoin-wizards
06:42 -!- brothchide is now known as EarlyBroth
06:45 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
06:48 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
06:55 < stevenroose> andytoshi: what is the reason holding back consensus enforced UTXO set commitments? like in coinbases?
06:56 < stevenroose> it could be a very segwit-alike softfork I guess
06:58 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has left #bitcoin-wizards []
06:58 < andytoshi> stevenroose: i -think- it's just that there isn't a consensus on the exact details or a BIP or anything. these commitments are potentially expensive to verify or update so you want to get the maximum value at minimum cost
07:00 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]
07:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:03 < gmaxwell> stevenroose: the fact that they are phenominally expensive, and have narrow utility, and that there are several incompatible proposals.
07:04 < gmaxwell> (and are an actively developing area of science)
07:04 < gmaxwell> The naieve proposals like my original were DOA because increasing validation IO costs 10 fold or more is a non-starter. :)
07:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:05 < gmaxwell> And also because those schemes are incompatible with proposals which eliminate the need for any node to store a utxo set at all.
07:06 < EarlyBroth> gmaxwell, defender of sidechains, to the resuce!   morn bro.
07:06 < EarlyBroth> *rescue.
07:06 < EarlyBroth> *hugs* even if you dont agree.
07:06 < EarlyBroth> *we
07:06 < stevenroose> "proposals which eliminate the need for any node to store a utxo set at all" care to elaborate?
07:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds]
07:06 -!- trippysalmon [~trippysal@cyberdynesys.org] has joined #bitcoin-wizards
07:07 < stevenroose> also, I'm amazed it's so expensive. I mean both Ripple and Ethereum have state trees all over the place.
07:07 < stevenroose> I would think there has to be an efficient tree storage algorithm that could be used to store and update a UTXO set
07:07 < stevenroose> I'm no expert though
07:08 < gmaxwell> stevenroose: yes and ethereum is scalablity is trash, https://anduck.net/bitcoincore_vs_geth_full_node_stats.png  e.g. anduck's graph shows that an actual full validation on his system will probably never finish.
07:08 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
07:08 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
07:09 < gmaxwell> basically hundreds of times worse than bitcoin.
07:09 < EarlyBroth> greg, movings towards some kind of UTXO thing would have no impact on your ability to do whatever you want with sidechains?
07:09 -!- Emcy [~MC@unaffiliated/emcy] has quit [Remote host closed the connection]
07:09 < gmaxwell> and ripple's scalablity is so poor that no one outside of ripple labs runs a node, so much so that when ripple's node had corruption they actually lost and cannot recover the early history of it.
07:10 < stevenroose> well, ripple doesnt have reorgs or anything, so they don't need history. but that's a big mistake on its own ofc
07:10 < stevenroose> and true, I heard numbers of what ripple was paying to keep their validator nodes online
07:10 < stevenroose> it's insane
07:11 -!- mode/#bitcoin-wizards [+o gmaxwell] by ChanServ
07:11 -!- mode/#bitcoin-wizards [-o gmaxwell] by gmaxwell
07:12 < gmaxwell> (and anduck's graph has a sync with bitcoin core for conparison)
07:12 < stevenroose> well, I did assume that the state tree system required more resources. didn't know it was this bad
07:14 < gmaxwell> stevenroose: ethereum's problems are many layered.
07:14 < gmaxwell> not just the fact that they commit to a zillion things, though that results in big slowdowns that are unfixable without major hardforks that change the protocol.
07:18 -!- EarlyBroth [~brothchid@109.202.102.88] has left #bitcoin-wizards []
07:18 -!- EarlyCrabs [~brothchid@109.202.102.88] has joined #bitcoin-wizards
07:19 < stevenroose> gmaxwell: the thing is that those commitment allow for a different security model. like looking only at the last X blocks and ignoring all the rest if there is enough work
07:19 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards
07:20 < gmaxwell> You know I was the first person to propose these things, right?
07:20 < stevenroose> not saying I like that though, I just think that's their idea, it's significantly different that bitcoin's though
07:20 < gmaxwell> like you don't need to tell me what they are useful for.
07:20 < stevenroose> I don't
07:20 < stevenroose> I know you understand them, don't worry :) didn't know you proposed them
07:21 < stevenroose> if you ask Gavin, he'd gladly steal your thunder :)
07:21 < stevenroose> gmaxwell: did you take a look at parity's Bitcoin implementation?
07:21 < stevenroose> They made it look like Gavin just wanted to proof that implementing Bitcoin is no biggy
07:22 < betawaffle> of course gavin would steal credit ;)
07:22 < stevenroose> When I briefly mentioned segwit, he immediately returned that "segwit is not part of the bitcoin protocol yet!"
07:22 < gmaxwell> stevenroose: it was also obviously consensus incorrect, failing the first check I did.  Ever try using it?
07:22 < stevenroose> betawaffle: we all know that
07:23 < stevenroose> gmaxwell: nope, I didn't
07:23 < stevenroose> gmaxwell: what was the first check you did? you made me curious
07:24 < gmaxwell> Not saying, then they'll fix it and I'll lose the easy test if it has had any competent review or not. :)
07:24 < gmaxwell> (perhaps they subsiquently fixed it, haven't looked.)
07:24 -!- Lamby_ [~Lamby_@unaffiliated/lamby/x-3301603] has quit [Quit: Leaving]
07:24 < gmaxwell> on utxo commitments https://bitcointalk.org/index.php?topic=21995.0
07:25 < betawaffle> is the fatal flaw included in that discussion?
07:25 < gmaxwell> no, it's related to the earlier thread of discussion.
07:26 < betawaffle> no, i mean the problem with your commitment proposal
07:26 < betawaffle> (you said it was broken)
07:26 < gmaxwell> no it doesn't talk about the limits, logs here from 2012ish are probably pretty good.
07:27 < gmaxwell> The first set of flaws was that even rather clever fast ways of handling it are just rather slow. This wasn't obvious until people went and made optimized implementations.
07:27 < betawaffle> oh i see
07:28 < gmaxwell> The next set of flaws was that several of the things we thought they were needed for, like fraud proofs turned out to be better achievable other ways. (e.g. through source-offset witness data in transactions)
07:28 < betawaffle> are fraud proofs eventually going to be possible?
07:28 < gmaxwell> The next set of issues was that petertodd proposed schemes (and later other people too) to eliminate a node's need for a utxo set entirely, (with considerable tradeoffs) which are obviously incompatible with these proposals.
07:29 < stevenroose> gmaxwell: "Since full nodes must already keep track of all open transactions for validation, maintaining such a tree would be relatively cheap (log2(n) for single updates, fewer per update if more than one txn changes at a time)." well, I might have made the same assumption :p
07:29 < gmaxwell> betawaffle: not a technical question, tech issues are all solved for making htem possible; meaningful is another question since their utility is an open question.
07:29 < betawaffle> wow, you can make fraud proofs for all kinds of fraud already?
07:30 < gmaxwell> betawaffle: with softforks, yes.
07:30 < betawaffle> i figured some would still be too expensive
07:30 < gmaxwell> no we know how to have efficient proofs for every protocol rule.
07:31 < betawaffle> kind of amazing
07:31 < gmaxwell> but the open question about partitioning/censorship makes it value prop unclear.
07:31 < betawaffle> ah, right
07:32 < gmaxwell> There are proposed optimizations for some of these set commitment ideas that make them much more viable, but they each kill some of the gains.
07:32 < betawaffle> to avoid those problems, you'd lose some of the benefits, right?
07:32 < gmaxwell> For example you can delay and batch them, but that basically kills anything they liteclients would use them for, any use of them in fraud proofs, etc.
07:33 < gmaxwell> And we have our rolling hash proposal, but again, kills many of the proposed applications. (but no IO overhead, hurray, but non-trivial CPU overhead, boo)
07:33 < betawaffle> has a rolling hash been picked yet?
07:35 < betawaffle> is the idea that it would be committed to in blocks?
07:38 -!- JackH [~laptop@46.231.18.66] has quit [Quit: Leaving]
07:45 -!- Emcy [~MC@cpc124516-swan5-2-0-cust78.7-3.cable.virginm.net] has joined #bitcoin-wizards
07:45 -!- Emcy [~MC@cpc124516-swan5-2-0-cust78.7-3.cable.virginm.net] has quit [Changing host]
07:45 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
07:53 -!- EarlyCrabs [~brothchid@109.202.102.88] has quit [Quit: BitchX: made with real honey.]
07:56 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
07:57 < kanzure> hmm there are no remaining consensus rules that have unsolved fraud proofs?
07:58 -!- Emcy [~MC@unaffiliated/emcy] has quit [Quit: Leaving]
07:58 -!- Emcy [~MC@cpc124516-swan5-2-0-cust78.7-3.cable.virginm.net] has joined #bitcoin-wizards
07:58 -!- Emcy [~MC@cpc124516-swan5-2-0-cust78.7-3.cable.virginm.net] has quit [Changing host]
07:58 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
08:00 -!- Emcy [~MC@unaffiliated/emcy] has quit [Client Quit]
08:00 -!- Nightw0lf [~Nightwolf@v2201412760721964.yourvserver.net] has quit [Quit: Lost terminal]
08:00 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
08:00 -!- Emcy [~MC@unaffiliated/emcy] has quit [Remote host closed the connection]
08:01 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
08:05 -!- Murch [~murch@96.82.80.28] has joined #bitcoin-wizards
08:08 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards
08:09 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
08:09 < gmaxwell> there weren't in 2012.
08:10 < gmaxwell> (IIRC)
08:10 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]
08:10 < kanzure> was block size the last holdout until luke-jr did that recently?
08:10 < kanzure> (block weight, now.)
08:12 < gmaxwell> luke's thing worked without extra commitments but it was always easy with extra commitments.
08:12 -!- Murch [~murch@96.82.80.28] has quit [Quit: Plugging out.]
08:12 -!- q4 [~q4@user-94-254-234-128.play-internet.pl] has joined #bitcoin-wizards
08:13 < gmaxwell> add to the block a commitment to a running sum of size/weight whatever.  if a block is too large, just show the last value.  If the commitment is wrong, show the first point where it disagrees. (either two adj running sum values, or a two and a tranaction)
08:13 < gmaxwell> any sum of whatever, sigops etc. can be done the same way.
08:14 < gmaxwell> see also: 'sum tree' though you don't need to sum up a tree to get an efficient proof for the fraud proofs. Though a tree works too.
08:18 -!- danrobinson [~danrobins@65.209.60.146] has joined #bitcoin-wizards
08:18 < luke-jr> what?
08:19 < luke-jr> no amount of commitments can fix fraud proofs being broken
08:19 < luke-jr> someone mining an invalid block can just fake any such commitment
08:19 < luke-jr> the block size proof only works against a very specific case
08:20 < gmaxwell> ...
08:21 < gmaxwell> luke-jr: you are simply wrong.
08:21 < luke-jr> …
08:21 < gmaxwell> unless you mean the censorship problem.
08:21 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards
08:22 < gmaxwell> where someone can just refuse to give anyone the whole block, so they can't tell that it's invalid.
08:22 < kanzure> was your earlier statement exclusively about "since 2012 we have definitely known how to design commitments that could allow for fraud proofs of all the rules"?
08:23 < kanzure> gmaxwell: i think that PoW verification should require the full transaction data. otherwise you're paying for possibly invalid data.  this solves fraud proof censorship because you can't measure PoW strength claim without having all the data.
08:24 < kanzure> (this would be solved by including the full transaction data next to the transaction merkle root)
08:25 < gmaxwell> well then you don't need the fraud proof really, just verify it.
08:25 < gmaxwell> if you're stuck always transfering it!
08:26 < kanzure> say you add a block weight commitment to the header. it doesn't solve the problem of "just refuse to give anyone the whole block". so the fraud proof can't use the block weight commitment.
08:27 < betawaffle> umm, doesn't refusing count as invalid?
08:28 < kanzure> no, miners can mine literally anything.
08:28 < gmaxwell> kanzure: I did propose how to solve that.
08:28 < betawaffle> yeah, but how would that ever be considered valid if they don't give it out?
08:28 < gmaxwell> But I don't think anyone else understands it.
08:28 < kanzure> betawaffle: "you have a raspberry pi"
08:28 < gmaxwell> betawaffle: imagine a world where almost everyone has lite clients.
08:29 < gmaxwell> betawaffle: and they will give out spv proofs to them, but hide the naughty stuff until later.
08:29 < kanzure> which proposal are you referencing?
08:29 < betawaffle> well obviously that's not sufficient
08:30 < betawaffle> is the goal to make light clients safer or to make full nodes cheaper?
08:31 < gmaxwell> kanzure: using locally decodable codes.  You make the protocol so the block is coded with an error correcting code that expands it.  Then when a client wants to read part 5 for his spv proof he does so by picking some random subsets that when combined let him decode part 5.  He will not accept the block unless he can get exactly the random segments he wants.
08:31 < gmaxwell> The effect of the code is that if all the users do this, the sender cannot serve more than a finite number of clients, before the clients know enough to either be able to reconstruct the whole block, or prove that the sender was giving out inconsistent chunks.
08:32 < kanzure> is there a minimum number of fragments to pick to make this work/not work?
08:33 < gmaxwell> haven't done the engineering to find concrete parameters, it works asymtoptically at least.
08:33 < kanzure> whole-reconstruction is the important property.  you need the collusion around whole block transfer to include at least one defector that will opt to transfer the full contents to others.
08:33 < betawaffle> is that a similar concept to fountain codes?
08:33 < gmaxwell> but it has weird constraints, like a block would have to have a designated server list in its header which are guarenteed to have the whole block, or something like that.
08:34 < gmaxwell> betawaffle: you would use something like a fountain code but with special constraints so that parts were decodable.
08:34 -!- MaxSan [~one@91.214.169.69] has joined #bitcoin-wizards
08:35 < kanzure> don't you run into the same "ha ha ha now 80% of the network shall be considered below even raspberry pis" problem? they will simply claim you cannot construct the full block due to your low bandwidth.
08:36 < kanzure> i guess you have to stripe the random selection requests across a trusted set of peers (but each user can setup this set on their own) so that in aggregate among your trusted peers you know there has been a complete copy.....?
08:37 < kanzure> as the total data size grows, you need to also grow your trusted peer set size, for striping requests across more available bandwidth..
08:41 -!- q4 [~q4@user-94-254-234-128.play-internet.pl] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:41 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:41 < gmaxwell> well the idea is that each peer can select randomly... but they're sticky in their suggestion. You could also have a peer have a proxy request "hey bob, I wanted 1,2,4 from the last server but can't seem to get it, can you get it?"  and if bob can't bob can start rejecting the block too.
08:41 < gmaxwell> I don't know if this idea is _reasonable_ but it's not nothing.
08:42 < gmaxwell> it has a lot of open problems in it.
08:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
08:42 < gmaxwell> for one, it might turn out that efficient parameter sets only exist for uninteresting sizes.
08:42 < kanzure> so one of the problems in the "undetected fraud" stuff is that if you do not detect fraud quickly, the network continues on and builds on top of the fraud, which makes the whole system worthless of course.   so the validity needs to be absolutely knowable within ~minutes or less.
08:42 -!- daszorz [~daszorz@188.94.18.118] has quit [Read error: Connection reset by peer]
08:43 < kanzure> if it turns out that way then i would argue just tack on the transaction data as part of verifying PoW strength.  that way you can be sure you have al the data and can check it.
08:43 < betawaffle> but...
08:43 < betawaffle> that defeats the purpose entirely
08:44 < gmaxwell> well one thing to help with that is you can seperate admisisson with consensus... which is what preconsensus techniques do... e.g. blocks commit to new transactions to add. but they're not really promising that they're all valid yet..  they also commit to an earlier point in history, which they promise is certantly valid honest to goodness.
08:44 < kanzure> the benefit of transfering the proof with the PoW itself is that you can only verify the PoW if the data is small enough for it to actually transfer the data in the first place.    you could imagine "super lite" clients that just accept any PoW claim but that's obviously stupid and nobody seems to do this. so....
08:44 < kanzure> betawaffle: you're basically claiming that the current bitcoin protocol is self-defeating.
08:44 < gmaxwell> I'm not all that convinced that pow that you can't verify at all without the data is actually possible, fwiw.
08:45 < betawaffle> well, SPV by itself is
08:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
08:45 < betawaffle> (perhaps i'm confused about what the conversation is)
08:45 < kanzure> oh that would be interesting. so like h=H(block data) but properties of h can be determined without the full block data ?
08:45 < gmaxwell> something having a freeloading problem doesn't make it automatically self defeating.
08:46 < gmaxwell> kanzure: yea, like if H is sha256, you can give a midstate and the end and still verify that you know <something><ends with this> with a given hash
08:46 < kanzure> hmph well that's problematic. hmm.
08:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]
08:48 < gmaxwell> also, even ignoring special cases like that, you run a generic ZK prover over your expensive verification to get a cheap one.
08:49 < betawaffle> gmaxwell, perhaps this is slightly tangent, but if someone were to defraud an SPV client, would they be able to provide proof for all txs without revealing the fraud?
08:49 < kanzure> wouldn't zk prover be slow and mining keep going anyway?  this is the same thing as hiding fraud  in distant past, if you can't check immediately then miners will just say "we're too far ahead on this branch already" or something.
08:51 -!- tgorham84 [~tgorham84@93.190.142.46] has joined #bitcoin-wizards
08:52 < kanzure> i think your block error correction code scheme is strictly no worse (and very possibly better) than the current ways that fraud can be hidden in untransmitted block contents.   and as you have pointed out, my alternative (include transaction data as requirement to compute PoW) does not improve the situation.
08:55 < gmaxwell> engineering complexity is not free.
08:58 < nsh> +1
09:00 < kanzure> with block error correction encoding scheme,  global publication channel feature is sort of lost, right? and anti-replay is only lost to the extent that none of your peers are able to quickly report inconsistencies between (conflicting?) results received from miners or other full data 'relayers'.
09:03 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has quit [Quit: Lost terminal]
09:05 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 255 seconds]
09:15 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
09:19 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
09:28 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-wizards
09:43 -!- bildramer [~bildramer@p200300ED83C030008CE0A069215BB789.dip0.t-ipconnect.de] has quit [Quit: alway rember happy day]
09:47 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has quit [Ping timeout: 260 seconds]
09:49 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]
09:51 -!- tgorham84 [~tgorham84@93.190.142.46] has quit [Remote host closed the connection]
09:51 -!- tgorham84 [~tgorham84@93.190.142.46] has joined #bitcoin-wizards
10:05 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
10:06 -!- bildramer [~bildramer@p200300ED83C03000A909A5CBF5D43609.dip0.t-ipconnect.de] has joined #bitcoin-wizards
10:15 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has joined #bitcoin-wizards
10:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
10:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
10:22 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
10:31 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]
10:31 -!- tgorham84 [~tgorham84@93.190.142.46] has quit [Quit: pizza]
10:39 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
10:43 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
10:45 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
10:52 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
11:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]
11:11 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 240 seconds]
11:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
11:17 -!- tgorham84 [~tgorham84@93.190.142.46] has joined #bitcoin-wizards
11:17 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-wizards
11:28 -!- str4d_ [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has joined #bitcoin-wizards
11:29 -!- str4d__ [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has joined #bitcoin-wizards
11:32 -!- str4d [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has quit [Ping timeout: 276 seconds]
11:32 -!- str4d_ [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has quit [Ping timeout: 240 seconds]
11:44 -!- tiagotrs [~tiago@p5DC47985.dip0.t-ipconnect.de] has joined #bitcoin-wizards
11:45 -!- tiagotrs [~tiago@p5DC47985.dip0.t-ipconnect.de] has quit [Changing host]
11:45 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-wizards
11:52 < sipa> betawaffle: there are some benefits to them being committed, but not so much... in a first step i wouldn't argue for a consensus rule
11:53 < betawaffle> k
11:53 < betawaffle> can they be used to reduce the trust necessary in using a utxo set snapshot?
11:58 < sipa> eh, under what assumptions?
11:59 < sipa> if you have a trusted UTXO set hash, you can always verify a UTXO snapshot you're getting
11:59 < sipa> all rolling hashes do is make it much cheaper to always have a hash
11:59 < betawaffle> like, imagine you can download the UTXO set (and hash) from one node, then ask other nodes too
12:00 < sipa> lol, don't do that
12:00 < betawaffle> but only because of the sybil risk, right?
12:00 < sipa> you shouldn't assume that a majority of your peers are honest
12:01 < betawaffle> correct
12:01 < tgorham84> but why would you have have to get the hash for the UTXO from the node instead of the blockchain?
12:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azhrsncrtpntobef] has joined #bitcoin-wizards
12:01 < betawaffle> tgorham84: if it isn't committed
12:01 < sipa> tgorham84: perhaps from an earlier run (if you're reindexing), or from another system you're operating
12:01 < sipa> or perhaps it can be shipped with software
12:01 < tgorham84> i see
12:02 < betawaffle> is there a way to fetch the UTXO set from other nodes currently?
12:02 < sipa> no
12:02 < sipa> if it is committed, you allow a new security level where you trust the majority of hashrate up to some point in the future, and then fully sync from there
12:04 < sipa> rolling utxo hashes imho also have more engineering-related advantages... you can use them as a simple local checksum
12:05 < sipa> (compute one from chain history, and one from the utxo set... they should be identical)
12:05 < betawaffle> is it based on a window of history?
12:06 < sipa> no
12:06 < sipa> you can't compute a hash of the utxo set by only looking at a part of history :)
12:06 < betawaffle> darn
12:06 < sipa> ?
12:07 < betawaffle> well, some rolling hashes will match up as long as you know where to start
12:07 < sipa> heh?
12:07 < tgorham84> wow that guy earlybroth started a convo about UTXO and then got banned now everyone talking all day :)
12:07 < betawaffle> not cryptographic ones ;)
12:07 < sipa> this is a cryptographic hash, it won't accidentally match with anything everything
12:07 < sipa> *ever
12:08 < sipa> betawaffle: to be clear, the idea is that a node would continuously update its cached rolling utxo hash of the last block
12:09 < betawaffle> so what makes this one easy to recompute?
12:09 < sipa> not recompute - update
12:09 < betawaffle> right...
12:09 < sipa> you can start from the previous hash, "subtract" the spent utxo's from it, "add" the created utxo's to it, and have the new hash of the set
12:10 < betawaffle> ohhhh. ok so what do those operations look like then?
12:10 < sipa> either elliptic curve addition/subtraction
12:10 < sipa> or finite field multiplication/division
12:11 < betawaffle> got it!
12:11 < sipa> the finite field one is probably easiest to understand
12:11 < sipa> your hash is just a big number (3000ish bits), and for every utxo you add - you hash the utxo, and multiply it into the hash
12:12 < sipa> for every utxo you spend, you divide the hash by it
12:12 < sipa> clearly, a create and a spend will cancel out, in whatever order they occur, regardless of what other operations happened in between
12:13 < betawaffle> and what data do you hash about the tx? same as the tx id?
12:13 < sipa> the txid, the output position in the txid, the amount, the scriptPubKey, the height, whether it's a coinbase or not
12:13 < sipa> (= exactly the data maintained in the utxo set)
12:15 < betawaffle> so, what use-cases do you already have for this?
12:15 < sipa> read the last 15 minutes in this channel :p
12:15 < betawaffle> :D
12:18 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
12:41 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
12:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
12:58 -!- tgorham84 is now known as EarlyHam84
13:08 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
13:08 < kanzure> .tw https://twitter.com/plutomonkey/status/893466957630103553
13:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
13:29 -!- EmmyNoether [~EmmyNoeth@xn--ht-1ia18f.nonceword.org] has joined #bitcoin-wizards
13:29 < nsh> .tw 893466957630103553
13:29 < EmmyNoether> All zk-SNARK proofs so far on Zcash have been independently verified using an alternative zk-SNARK verifier: https://github.com/plutomonkey/zcash-sprout-verifier (@plutomonkey)
13:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
13:53 -!- danrobinson [~danrobins@65.209.60.146] has quit [Quit: danrobinson]
13:56 < irc_bot> <nicola> that’s amazing ^
14:10 -!- str4d__ [~str4d@host86-137-249-193.range86-137.btcentralplus.com] has quit [Ping timeout: 260 seconds]
14:18 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 276 seconds]
14:20 -!- xulf [040ff533@gateway/web/freenode/ip.4.15.245.51] has joined #bitcoin-wizards
14:27 < xulf> a broadcast medium makes sense as a way to distribute blocks
14:28 < xulf> wireless or satellite
14:28 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
14:29 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
14:34 < xulf> but is there a trust problem with many users receiving from the same source for blocks?
14:34 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
14:36 < sipa> xulf: if they rely on that source being available, yes
14:36 < sipa> as an addition means to prevent partition, no
14:38 < sipa> *additional
14:44 -!- danrobinson [~danrobins@2604:2000:e080:d400:d12c:51c0:e94c:3d7a] has joined #bitcoin-wizards
14:45 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]
14:47 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:48 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards
14:52 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
15:04 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
15:04 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-wizards
15:05 -!- yoleaux [~yoleaux@xn--ht-1ia18f.nonceword.org] has joined #bitcoin-wizards
15:14 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
15:21 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
15:26 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
15:28 < xulf> https://www.youtube.com/watch?v=H0DKRl8XIcU human inaudible sound transmission example, if you can pay a satellite radio station to broadcast at 23 khz for example it wouldn't affect people listening to the station
15:28 < xulf> that are also listening to music
15:38 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 246 seconds]
15:39 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
15:40 -!- Belkaar [~Belkaar@xdsl-89-0-108-86.netcologne.de] has joined #bitcoin-wizards
15:40 -!- Belkaar [~Belkaar@xdsl-89-0-108-86.netcologne.de] has quit [Changing host]
15:40 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards
15:45 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
15:49 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
15:49 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Read error: Connection reset by peer]
15:53 -!- Dizzle [~Dizzle@2605:6000:1019:41a7:751d:124b:da87:b260] has joined #bitcoin-wizards
16:10 -!- Murch [~murch@216.9.110.5] has joined #bitcoin-wizards
16:26 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]
16:35 -!- Murch [~murch@216.9.110.5] has quit [Quit: Snoozing.]
16:40 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
16:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
16:50 -!- danrobinson [~danrobins@2604:2000:e080:d400:d12c:51c0:e94c:3d7a] has quit [Quit: danrobinson]
16:52 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
16:53 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Quit: leaving]
17:03 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-wizards
17:06 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]
17:06 -!- LeMiner2 is now known as LeMiner
17:09 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.9]
17:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
17:10 -!- CheckDavid [uid14990@gateway/web/irccloud.com/x-vbfdimrtmlguqboy] has quit [Quit: Connection closed for inactivity]
17:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
17:13 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
17:14 -!- chjj [~chjj@unaffiliated/chjj] has quit [Remote host closed the connection]
17:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
17:19 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
17:27 -!- Dizzle [~Dizzle@2605:6000:1019:41a7:751d:124b:da87:b260] has quit [Remote host closed the connection]
17:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
17:42 -!- EarlyHam84 [~tgorham84@93.190.142.46] has quit [Ping timeout: 240 seconds]
17:45 -!- darpvader [~darpvader@95.141.37.164] has joined #bitcoin-wizards
17:53 -!- adiabat [~adiabat@45.63.20.152] has quit [Remote host closed the connection]
18:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
18:02 -!- adiabat [~adiabat@45.63.20.152] has joined #bitcoin-wizards
18:10 -!- sn0wmonster [~yeti@taskhive/lead/sn0wmonster] has quit [Read error: Connection reset by peer]
18:12 -!- Dizzle [~Dizzle@2605:6000:1019:41a7:3907:41f6:633e:634a] has joined #bitcoin-wizards
18:12 -!- sn0wmonster [~yeti@taskhive/lead/sn0wmonster] has joined #bitcoin-wizards
18:18 -!- rdarpvade [~darpvader@95.141.37.229] has joined #bitcoin-wizards
18:19 -!- darpvader [~darpvader@95.141.37.164] has quit [Ping timeout: 268 seconds]
18:19 -!- rdarpvade is now known as darpvader
18:20 -!- xulf [040ff533@gateway/web/freenode/ip.4.15.245.51] has left #bitcoin-wizards []
18:21 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
18:21 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Client Quit]
18:28 < fluffypony> I have this vague recollection of someone putting up a radio tower and broadcasting blocks
18:29 -!- prime_ [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has quit [Ping timeout: 260 seconds]
18:29 -!- prime_ [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
18:31 < Eliel> fluffypony: more like renting some bandwidth from a radio tower, but yes, it happened. I know the person whose project it was.
18:32 < fluffypony> ah cool, so I'm not losing my mind
18:32 < Eliel> http://kryptoradio.koodilehto.fi/
18:35 < kanzure> fluffypony: could it be possible that you are losing your mind for entirely different and unrelated reasons?
18:36 < fluffypony> I was hoping nobody had noticed
18:36 < fluffypony> I'm suffering from ICOplasia
18:53 < grubles> "Kryptoradio project ended in December, 2014 "
18:53 < grubles> aw
18:53 < grubles> that was a cool project
18:57 -!- danrobinson [~danrobins@2604:2000:e080:d400:d12c:51c0:e94c:3d7a] has joined #bitcoin-wizards
18:57 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]
19:01 -!- prime_ [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has quit [Ping timeout: 255 seconds]
19:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
19:05 -!- prime_ [~quassel@ip-178-203-232-21.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
19:17 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
19:31 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
19:34 -!- chjj [~chjj@c-24-130-173-170.hsd1.ca.comcast.net] has joined #bitcoin-wizards
19:36 -!- chjj [~chjj@c-24-130-173-170.hsd1.ca.comcast.net] has quit [Changing host]
19:36 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
19:50 -!- onabreak [55e4c13c@gateway/web/freenode/ip.85.228.193.60] has quit [Ping timeout: 260 seconds]
19:54 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds]
20:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azhrsncrtpntobef] has quit [Quit: Connection closed for inactivity]
20:05 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
20:18 -!- danrobinson [~danrobins@2604:2000:e080:d400:d12c:51c0:e94c:3d7a] has quit [Quit: danrobinson]
20:26 -!- Emcy_ [~MC@unaffiliated/emcy] has joined #bitcoin-wizards
20:28 -!- Emcy [~MC@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]
20:29 -!- uiuc-slack [~uiuc-slac@li175-104.members.linode.com] has quit [Remote host closed the connection]
20:29 -!- uiuc-slack4 [~uiuc-slac@li175-104.members.linode.com] has joined #bitcoin-wizards
20:41 -!- onabreak [55e4c13c@gateway/web/freenode/ip.85.228.193.60] has joined #bitcoin-wizards
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:00 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:19 -!- sn0wmonster [~yeti@taskhive/lead/sn0wmonster] has quit [Ping timeout: 258 seconds]
21:29 -!- marcoagner [~user@177.41.193.82] has quit [Ping timeout: 276 seconds]
21:36 -!- darpvader [~darpvader@95.141.37.229] has quit [Ping timeout: 258 seconds]
21:44 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 240 seconds]
21:44 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
22:01 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
22:37 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
22:58 -!- anon616 [anon616@gateway/shell/sameroom/x-kbcxrtyfujjlbdjm] has quit [Remote host closed the connection]
23:08 -!- anon616 [anon616@gateway/shell/sameroom/x-pxsojjalfcrfuzfs] has joined #bitcoin-wizards
23:49 -!- Dizzle [~Dizzle@2605:6000:1019:41a7:3907:41f6:633e:634a] has quit [Quit: Leaving...]
--- Log closed Sat Aug 05 00:00:40 2017