sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
fabianfabian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dizzle has joined #bitcoin-wizards
Zenton has quit [Ping timeout: 272 seconds]
fabianfabian has joined #bitcoin-wizards
thomasanderson has joined #bitcoin-wizards
thomasanderson has quit [Ping timeout: 244 seconds]
sipa has quit [Remote host closed the connection]
sipa has joined #bitcoin-wizards
thomasanderson has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
thomasanderson has quit [Remote host closed the connection]
alferz has quit [Ping timeout: 240 seconds]
thomasanderson has joined #bitcoin-wizards
e4xit has quit [Ping timeout: 250 seconds]
thomasanderson has quit [Remote host closed the connection]
thomasanderson has joined #bitcoin-wizards
fabianfabian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
morcos has quit [Ping timeout: 256 seconds]
morcos has joined #bitcoin-wizards
ghost43 has quit [Ping timeout: 256 seconds]
ghost43 has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 240 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
fabianfabian has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
booyah has quit [Ping timeout: 246 seconds]
booyah has joined #bitcoin-wizards
thomasanderson has quit [Remote host closed the connection]
rh0nj has quit [Remote host closed the connection]
rh0nj has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
alferz has quit [Ping timeout: 240 seconds]
thomasanderson has joined #bitcoin-wizards
thomasanderson has quit [Ping timeout: 240 seconds]
thomasanderson has quit [Ping timeout: 250 seconds]
thomasanderson has joined #bitcoin-wizards
ruby32 has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
Dizzle has quit [Quit: Leaving...]
thomasanderson has quit [Ping timeout: 250 seconds]
harrymm has quit [Ping timeout: 244 seconds]
harrymm has joined #bitcoin-wizards
nephyrin has quit [Ping timeout: 260 seconds]
harrymm has quit [Ping timeout: 246 seconds]
nephyrin has joined #bitcoin-wizards
harrymm has joined #bitcoin-wizards
elichai2 has joined #bitcoin-wizards
<elichai2>
Hey, Question, why are people more afraid of rangeproofs/bulletproofs being broken than ECC? is it because the math is more complicated? because it is way newer math? or is it completely illogical?
<sipa>
their security assumptions are exactly the same
<sipa>
so not sure what you mean
<elichai2>
sipa: yeah I know that the security assumptions are the same, but at least I feel on twitter and social media that people are more afraid of "hidden inflation" due to range proofs being broken than they are afraid of someone stealing bitcoins by breaking ECC
<sipa>
oh, sure
<elichai2>
maybe it's the same reason as why satoshi used ECDSA instead of Schnorr? because it was older and had more time for bugs to be discovered?
<sipa>
forged signatures are detectable
<sipa>
hidden inflation is not
<elichai2>
So i'm just trying to understand if this fear is logical at all
<elichai2>
but still, if it's possible to forge ECDSA sigs all your bitcoins are worth nothing now
<sipa>
that's far less scary than someone inflating the currency for years without being detected
<sipa>
if forged signatures are detected you can create a new chain with post quantum crypto in theory, with a snaoshot of the utxo set before the forgery
<elichai2>
hmm maybe, idk, I personally not afraid of DLP breaking soon
<elichai2>
but how could you know which signatures are forged and which are real?
<elichai2>
I mean only the owner of the key can know
<sipa>
sure
<sipa>
but in case of inflation nobody will know
<sipa>
ever
gakonst has joined #bitcoin-wizards
<elichai2>
So as a dev that does HF how do you know at which block all the money is legitimate? an attack like this undermines the whole monetary
<sipa>
devs don't do HFs, a community does :)
<elichai2>
yeah but I'm not sure the fact that you don't know is any more devastating than if you do know
<elichai2>
haha yeah but some dev will need to make the change so the community can run the new software, he'll probably need to hard code the last trusted block before when he thinks the forgery happenned
<sipa>
ok, another one: an ECC break we see coming we can prepare for by introducing quantum secure signature slowly ahead of time
<sipa>
as a softfork, even
<elichai2>
but if you see it coming than you can try to introduce some quantom security to the rangeproofs too
<cjd>
also consider the fact that even if ECDSA is broken, that's only usable against keys which have received *and* spent money, keys which are just holding money are safe because nobody actually knows the key, only the hash of the key
<sipa>
cjd: i think that's a bogus argument :)
<sipa>
key reuse is so rampant that a very significant portion of the monetary base is at risk, enough to destroy trust in the remainder
<cjd>
You have a point, but for a reclusive millionaire who is obsessed with quantum computers, that is a sort of answer
<sipa>
it also relies on making a weird assumotion about a theoretival device that does not exist
<sipa>
namely that it somehow can be used to break keys in the timeframe of >days, but not in <=hours
<cjd>
The answer which our obsessive millionaire would use is that their cold wallet keys are secret and if there is a break, people will know it pretty quickly and they will then hold tight until a proper fork was made
<sipa>
i think that as bitcoin is used right now, if a sufficiently powerful QC (for some value of sufficiently powerful) appears, bitcoin has a problem
<cjd>
agreed
<sipa>
it's not quite as bad as the possibly-hidden-inflation-for-years... but still it would be very dramatic
<cjd>
but QC is important later, optics and warm-and-fuzzies are important now :)
<sipa>
maybe
<sipa>
the solution to QC and bitcoin imho is taking the time to research possible solutions properly
<cjd>
That said, what I hear from the quantum space is that hashes are not necessarily safe, we just don't know them to be broken, so PQ algorithms are not necessarily PQ
<cjd>
My intuition is that they will be at risk because the amount of entropy is not as much as it appears to be and for a hash to function properly, it needs to destroy some, but that's just an intuition
<sipa>
elichai2: properly allowing amount commitments to be upgradable to be unconditionally sound requires having the scheme worked out fron the start; you can't switch later to a secure schene you don't know yet as a SF
<sipa>
elielialso, such schemes have inevitably another downside; either the QC can forge the amounts, or it can break privacy of past transactions
<elichai2>
btw, I didn't talk specifically about a quantum computer, I talked about generally abusing ECC, being broken in one of these ways: 1. Breaking DLP. 2. Finding a way to break ECC without breaking DLP. 3. Quantum Computer
<elichai2>
cjd: for a reclusive millionaire this isn't a solution, as long as most of the monetary base is at risk his coins will be worthless
<sipa>
elichai2: all the same
<sipa>
elichai2: any such system will either permit an ECC break to perform hidden inflation, or to break privacy of past transactions
<elichai2>
sipa: maybe it will be possible to reveal the amounts and "burn" the coins into a new commitment?
<cjd>
I think re anonymity, the ideal model is to allow people to transfer their money into and out of a black box, the black box has a balance and if ever the math which makes the black box work fails, the box fails but other money is still safe
<sipa>
cjd: there is an argument to be made that if an ECC break is the end of bitcoin (not a position i necessarily agree with, but it's a reasonable thing to say), that it's better to have it break comoletely going forward, but protect privacy of the past
<sipa>
as the alternative is that the box remains secure but nonprivate... and now things that were supposed to be private get revealed, and eventually the system breaks anyway
<cjd>
Agreed, but I think this is why the NSA is so hot for making QC work
<cjd>
anonymous capital is going to be problematic for states in the medium term
<sipa>
so it's a choice between an insecure future and private past, or a mostly insecure future and a revealed past
<elichai2>
cjd: is that even technically possible? to monitor the balance of the box as a whole?
<sipa>
elichai2: extension block
<elichai2>
I mean you can easily monitor what goes inside the box and what comes back from it and make sure that there are no inflation that way
<sipa>
i think it's the only somewhat feasible way to deploy hidden amounts in bitcoin
<elichai2>
sipa: yeah, but I'm saying does CT math let you somehow check a "balance"?
<sipa>
of course not
<sipa>
by definition
<cjd>
you check the balance of the whole box, not everyone whose in it
<cjd>
*who is
<sipa>
that wouldn't be zero knowledge
* cjd
-> coffee, brb
<elichai2>
yeah that's why I askede
Zenton has joined #bitcoin-wizards
<elichai2>
cjd is suggesting to check the balance of the whole box. how can this be possible? (e.g. in Liquid if you inflate lbtc's you won't be able to withdraw more than is pegged but it will still be hidden lbtc inflation )
<cjd>
right, so if the box fails then the last person to withdraw from it loses
<elichai2>
yes
<sipa>
elichai2: you solve it by having a different currency on each side
<cjd>
but that's a contained failure
<sipa>
and the exchange rate between the two reflects the trust the public has that the cryptography is not broken
<cjd>
I would just allow people to withdraw 1:1 until the balance reaches zero
<elichai2>
sipa: it's completely invalid to say that we're afraid of range proofs because it was studied less and hence more possible that we're missing some weaker assumption?
<cjd>
if the balance reaches zero and there are more valid withdrawals, the math broke
nephyrin has quit [Ping timeout: 252 seconds]
<sipa>
elichai2: there is engineering complexity of course
<elichai2>
yeah
<elichai2>
cjd: yeah, but that's assumes it will ever be zero
<sipa>
which brings attack vectors and risks
<cjd>
kind of like a Swiss Bank, it protects your privacy but it might go bankrupt
<elichai2>
sipa: I'm not saying imeplemention faults, only pure math
<sipa>
elichai2: no, they're provably sexure as long as ECC isn't broken
<cjd>
in any case, it allows people to make a choice, which I think is the right thing to do
<sipa>
*secure
nephyrin has joined #bitcoin-wizards
<elichai2>
hmm ok, I'm still not convinced that breaking ECC any less devestating than breaking range-proofs but I get the psychology
<sipa>
elichai2: there is also a very pragmatic argument... rangeproofs in-chain (without a separate extension area) requires a HF inevitably
<elichai2>
sipa: yeah that's talking about bitcoin, I had grin in mind but you're right
<sipa>
doesn't grin already have CT and more?
<sipa>
it's mimblewimble which is based on CT
<sipa>
(i know very little about grin)
<elichai2>
grin is pretty straight forward MW
<elichai2>
but with bulletproofs, and some graph search PoW
<sipa>
then i don't understand the question
<cjd>
I think it would be nice to have ECDSA + NTRU signatures on everything, since the address is hash(key) it doesn't require longer addresses, just more data in a tx
<cjd>
or (again) give people a choice
<sipa>
cjd: can't do any of the cool things that nake it practical though :(
<sipa>
no public derivation of keys
<elichai2>
People out there trust the math of grin less than of bitcoin and I wasn't sure if it's logical or psychological
<sipa>
no taproot
<sipa>
elichai2: i think it's engineering :)
<sipa>
not math
<cjd>
oh you mean the stuff with point addition to get keys and plain addition to get private keys ?
<sipa>
they have 10 years of experience that the bitcoin ecosystem went through to battle harden against various important and less important attacks to reinvent
<elichai2>
sipa: grin is Rust which makes some specific bugs less likely
<sipa>
elichai2: and others more likely
<elichai2>
but I agree that bitcoin have way more refinment and edge cases handling than any other coin out there
<sipa>
but i'm more talking about DoS attacks
<sipa>
and about practices of develooment that reduce risks
<sipa>
not so much the code itself
<elichai2>
yeah I agree with you on that
<elichai2>
I like grin because it's the first not commercial DLP only coin
<sipa>
i'm biased of course, here
<sipa>
huh?
<elichai2>
yeah haha
<mryandao>
why is a DLP only coin a good thing?
<mryandao>
when the QC threat is very real.
<sipa>
what about bitcoin?
<elichai2>
because other ZKP's are weaker assumptions (CRH)
<sipa>
mryandao: QC is trading expoentntial runtime for exponential engineering time :)
e4xit has joined #bitcoin-wizards
<mryandao>
that might be the case today, give it a couple of years there might be breakthroughs in QC. (shrugs)
<sipa>
cjd: i also don't agree that giving people a choice between ec and ntru (or whatever) is a good idea; it's a gratuitous loss of fungibility when people need to expose their preferences about the security needed for coins
<mryandao>
w.r.t DLP problems, bitcoin also needs hash collisions to be fully compromised.
<sipa>
mryandao: no
<cjd>
hm, interesting point
<sipa>
cjd: plus if it's mixed within the same 'domain', and you personally believe that some TLA is going to have a WC in the near future, you don't want anyone to still use ecdsa even, because it threatens your monetary base as well
<sipa>
s/WC/QC/
<mryandao>
sipa: no? if i dont know the preimage of the hash, how'd can i reliably be able to reproduce a witness to spend a targeted output.
<sipa>
mryandao: plenty of coins have their public keys known
<sipa>
that's enough
<sipa>
even if yours don't
<mryandao>
oh well.
<mryandao>
everyone should just use scripthash
<sipa>
i don't think so
<sipa>
i think we should research PQ solutions, to deploy when necessary
<cjd>
My understanding of it is that it used to be a physics problem, now it's considered an engineering problem.. when QC exists we will have a lot of new ways to encrypt things which we don't today, but also it's going to be a mess for a lot of different types of encryption and Shor attack is not likely to be the end of it
* sipa
is slightly skeptical and beliefs researchers who say that sort of thing might have an easier time finding funding :)
<sipa>
that said, i'm not an expert at all
<cjd>
That's a good point, it might be a big ruse and a lot of smoke-blowing in order to get funding, because from a state perspective it is a Fountain of Youth
<cjd>
I've spent a fair amount of time behind the curtain in the research world, but unfortunately not behind that particular curtain
<mryandao>
sipa: regarding the choices you mentioned earlier, isnt script hash v. exposing public key the same thing?
<sipa>
mryandao: i just don't think that hashes can be counted on to protect against anything in a PQ world
<sipa>
they may, or they may not
<cjd>
^^ this is agreeing with what I've heard
<sipa>
but who knows what kind fo characterisics such a hypothetical device has
<mryandao>
is there anything about QC making finding pre-images easier? o.O
<cjd>
yes
<sipa>
yes, it halves the security level
<sipa>
but also, who knows what the constant factors are?
<cjd>
Well, I know a guy who is writing theoretical programs for these type of machines and simulating them on a supercomputer, there is a fair amount known from them because in theory we're able to factor numbers like 15 (if you believe what the QC builder companies say)
<sipa>
maybe breaking an EC signature takes 10 years on a QC
<sipa>
in which case there is not much under threat
<sipa>
or maybe it takes 1 minute, and then hashes won't save you
spinza has quit [Quit: Coyote finally caught up with me...]
<cjd>
hm, I don't think that's really under question
<cjd>
My understanding is the complexity of keeping particals entangled grows with the number of particles
<cjd>
With an 8 qbit QC, you're only going to factor 8 bit numbers, so that's not much fun
<sipa>
yes the biggest question is whether a sufficiently large number of qbits can be kept consist for long enough iirc
<cjd>
We might find that states get 128 or 256 qbit machines in 10 years but it takes 30 years to get 1024 qbit machines, so all we really need to do is keep the same boring crypto but with longer keys
<sipa>
or otherwise whether it can be grown so much that error correction can be built in to keep the consistency around for longer
<cjd>
*nod*
<cjd>
maybe we find that RSA 2048 remains quite safe
<sipa>
iirc 256-bit EC requires 2000 ish qbits
<cjd>
ahh, cool
<cjd>
that I didn't know
nephyrin has quit [Ping timeout: 250 seconds]
nephyrin has joined #bitcoin-wizards
<elichai2>
cjd: I'm not a physicist, but as far as I know QC is a very hard engineering problem now, and they hope for a better physics solution to make the engineering easier
<cjd>
sounds about right
DeanGuss has quit [Remote host closed the connection]
DeanGuss has joined #bitcoin-wizards
DeanGuss has quit [Client Quit]
gakonst has quit [Quit: Page closed]
spinza has joined #bitcoin-wizards
harrymm has quit []
rh0nj has quit [Remote host closed the connection]
rh0nj has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
spinza has joined #bitcoin-wizards
ghost43 has quit [Quit: Leaving]
ghost43 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
* nsh
tips hat at cjd
<nsh>
"one-more-DLP" - as very much used/overloaded in bulletproofs - is a very nominally slightly different security computational hardness assumption than ecDLP in ECDSA in bitcoin but no published results make it quantitatively easier or harder in terms of proven bounds afaik
<nsh>
but the security proof reductions are not trivial either and some claims reductive proofs are less obviously correct than as written: https://eprint.iacr.org/2007/442.pdf
<nsh>
*claimed
<sipa>
nsh: sure yiu're not confusing with the first musig paper draft?
<nsh>
(also in a zero-knowledge system there's a choice of failure mode - the hiding or the blinding - and bulletproofs fails open in the sense that a break wouldn't allow the unmasking of historical transactions -- but would stop the system being usable anymore)
<nsh>
i'm pretty sure bulletproofs falls under 1MDLP
<sipa>
bulletproofs afaik rely one just DLP
<nsh>
well, it's a non-trivial DLP relation that would have to be found
<nsh>
but it's not the preimage of a single exponentiation
<nsh>
but the distinction isn't very meaningful in terms of known security consequences
<cjd>
howdy nsh
<nsh>
hope you're well and season's &c. :)
<cjd>
I am thanks, and same to you
<cjd>
I've been working on CPU-hard mining algorithms and I happened upon a low clock speed high parallelism processor arch which I think ruins any hope of long term asic resistance
<cjd>
Replace "GPU core" with "bunch of little ALUs with no registers nor caches" and you can do it in hardware
<nsh>
sipa, i think you're right actually. must have been confusing something but as written bootle's work relies on just DLP via pederson multicommitments to an inner-product relation and a polynomial in vectors evaluated at a point but i feel like it's a bit of a gloss still to trivialise the geometric structure that is reduced to the zk proof of the openability of the inner-product pederson commitment
<nsh>
but there's no accepted terms of art for how the DLP assumption is being overloaded and more research is indicated, is my opinion at least
<nsh>
cjd, maybe try and estimate how that arch would perform against e.g. new monero mining algorithm [CryptoNight Variant 2 i think it is now]
<cjd>
should "keep all available circuits busy" if it was made as an ASIC
<nsh>
i think the game at the moment is saturating PC cpu cache line performance as well as having serial reads of the large scatch space
<nsh>
i haven't got my head around where the optimality comes from yet
<cjd>
of my design ?
<nsh>
of cryptonightv2 being PC CPU-easy via memory bandwidth
<cjd>
ahh
<nsh>
'Is 4 times more demanding for memory bandwidth. This means that older GPUs might experience a hashrate reduction of up to 20%.
<nsh>
'
<cjd>
I think the idea was that CPUs pull a 64 byte cache line every time you touch 1 bit, so better just use the whole thing
<nsh>
right
<cjd>
tune to the hardware you have, that model still works for the most part.. but if one transistor on your proc is idle then someone will make an ASIC without that transistor
<nsh>
the battle is lead time really vs the expected time to even returns for taping out an ASIC
<nsh>
if the PoW can be tweaked in a 6 month release cycle
<cjd>
My finding is that general purpose problems like "compile linux" are not really safe against ASICs as long as they can be parallelized, and unless verification is highly expensive, they can
<cjd>
Also my design is a general purpose processor, so tweaking the algorithm will stop working
AaronvanW has quit [Remote host closed the connection]
<cjd>
This is basically a 10mhz processor running a million threads, or something like that
<nsh>
hmm, i wonder if you can do recursive PoW (ie any parallelism has to chase the tip of a hash tree in the same way that individual miners do on the bitcoin network [abandon hashing, reverify and recommence hashing over new valid tip]
<nsh>
)
<cjd>
hm, you mean create a dataset which you can use for a while but then you have to switch ?
<nsh>
yeah, whenever a thread wins some hash difficulty on the scratch data
<cjd>
how do you verify ?
<cjd>
I think if verification is cheap, the whole thing devolves into simple guess-and-check
<nsh>
maybe hmm
<nsh>
the problem is that if one ASIC/GPU+CPU is running all the threads they they can compare notes on what nonces they're tried already
<nsh>
which we assume isn't happening with diverse miners
<cjd>
well, if it's an advantage, a pool can give out nonce ranges
* nsh
nods
<cjd>
You might try to reuse some of the verification expense from verifying the transactions themselves as expense for verifying the PoW
<cjd>
If it takes 1MB to verify, you can mine DRAM_SIZE / 1MB parallel threads
<nsh>
oh yeah you can use the @satoshi trick to kinda rotate all the transaction sigs
<nsh>
and then they all have to be reverified again
<nsh>
(ECDSA property where you can modify a real signature over a message to be another valid signature over a new uncontrollable message)
<cjd>
on neat
<nsh>
or message determined by the extension of a valid msg+sig pair
<nsh>
so if everything that must be validated is rotated in an inherently serial way (through iterated hashing) then it at least replicates the verification load each time
<nsh>
then you add a hash lottery and individual threads can win and it resets the validation and obviates the work done by other threads
<cjd>
yup, but nobody can verify a block in parallel anymore :)
<nsh>
well you can add this difficulty within mining but not for actual network level block validation i think
<cjd>
IMO no
<nsh>
hm, need to think harder about it
<cjd>
because otherwise the mining is reduced to guess and check using the verification algorithm
thomasanderson has joined #bitcoin-wizards
<cjd>
neat thing is that a lot of things in the world are reasonably parallelizable, if you have thousands of threads available, stuff like verifying transactions in a block is worth a revisit
bsm117532 has quit [Quit: Leaving.]
bsm117532 has joined #bitcoin-wizards
<cjd>
and intuitively, I expect that with Ghz hardware clock speed, this arch can probably achieve as much as 100 MIPS with programs where each instruction is dependent on the output of the last
thomasanderson has quit [Ping timeout: 240 seconds]
<nsh>
would be good to simulate your arch over GPU (or something like the epiphany coproc on the parallela board, of which i have one but might be too bad/slow at coding on it to knock up a sketch of your proposal)
<cjd>
yes, I'm definitely going to try it on a GPU in the next few months/years
<cjd>
I plan to go forward with the hardest CPU-bound work I can think of, with the hope that my PoW will help encourage this processor to be created
<nsh>
cool :)
<cjd>
It's also encouraging to see where languages (e.g. Rust) are going, because this type of language lends itself to parallel execution
* nsh
nods
nephyrin has quit [Ping timeout: 250 seconds]
nephyrin has joined #bitcoin-wizards
e4xit has quit [Quit: quit]
e4xit has joined #bitcoin-wizards
nephyrin has quit [Ping timeout: 250 seconds]
nephyrin has joined #bitcoin-wizards
belcher has quit [Ping timeout: 250 seconds]
fabianfabian has joined #bitcoin-wizards
rh0nj has quit [Remote host closed the connection]
thomasanderson has quit [Ping timeout: 250 seconds]
thomasanderson has joined #bitcoin-wizards
<gmaxwell>
elichai2: Schnorr is much older than ECDSA and at least academically was much better studied.
thomasan_ has quit [Ping timeout: 245 seconds]
<elichai2>
gmaxwell: really? So why didn't Satoshi used schnorr?
thomasan_ has joined #bitcoin-wizards
<sipa>
elichai2: likely because he didn't know about it
<sipa>
at the time there were no schnorr-based standardized signature schemes
thomasanderson has quit [Ping timeout: 246 seconds]
<gmaxwell>
elichai2: AFAIK there were no industrial grade implementations available, at least not in open source software... due to it having been patented until not long before bitcoin existed.
<gmaxwell>
(ECDSA was created specifically to dodge the schnorr patent.)
thomasan_ has quit [Read error: Connection reset by peer]
thomasanderson has joined #bitcoin-wizards
<sipa>
or rather, DSA was
<sipa>
ECDzsA is just an adaptation of DSA for elliptic curves
<sipa>
*ECDSA
Murch has joined #bitcoin-wizards
thomasan_ has joined #bitcoin-wizards
thomasanderson has quit [Ping timeout: 240 seconds]
thomasanderson has joined #bitcoin-wizards
thomasan_ has quit [Ping timeout: 246 seconds]
thomasanderson has quit [Read error: Connection reset by peer]
thomasanderson has joined #bitcoin-wizards
thomasanderson has quit [Read error: Connection reset by peer]
thomasanderson has joined #bitcoin-wizards
koshii has quit [Read error: Connection reset by peer]
thomasan_ has joined #bitcoin-wizards
koshii has joined #bitcoin-wizards
thomasanderson has quit [Ping timeout: 244 seconds]
thomasan_ has quit [Read error: Connection reset by peer]
thomasanderson has joined #bitcoin-wizards
thomasanderson has quit [Read error: Connection reset by peer]
thomasanderson has joined #bitcoin-wizards
thomasanderson has quit [Ping timeout: 250 seconds]
grubles has quit [Remote host closed the connection]