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
skeuomorf has joined #bitcoin-wizards
AEM is now known as aem
CheckDavid has quit [Quit: Connection closed for inactivity]
Belkaar_ has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 272 seconds]
yoleaux has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
Oizopower has quit [Quit: Connection closed for inactivity]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
snatcher has quit [Quit: snatcher]
echonaut4 has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
pro has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
rphlx has quit [Quit: Leaving]
thrmo has quit [Ping timeout: 246 seconds]
sn0wmonster has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
RubenSomsen has joined #bitcoin-wizards
jannes has quit [Quit: Leaving]
alferz has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
alferz has quit [Ping timeout: 268 seconds]
sn0wmonster has quit [Quit: ¯\_(ツ)_/¯]
rusty has quit [Ping timeout: 240 seconds]
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
RubenSomsen has quit [Ping timeout: 245 seconds]
_whitelogger has joined #bitcoin-wizards
[7] has quit [Disconnected by services]
TheSeven has joined #bitcoin-wizards
RubenSomsen has joined #bitcoin-wizards
anon616 has quit [Remote host closed the connection]
tromp has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
anon616 has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
RubenSomsen has quit [Ping timeout: 240 seconds]
goatturner has joined #bitcoin-wizards
onabreak has quit [Ping timeout: 260 seconds]
juscamarena_ has joined #bitcoin-wizards
Guest55236 has quit [Ping timeout: 255 seconds]
_whitelogger has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
onabreak has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
rusty has joined #bitcoin-wizards
sn0wmonster has joined #bitcoin-wizards
sn0wmonster has quit [Max SendQ exceeded]
v20100 has quit [Ping timeout: 240 seconds]
moli is now known as mol
rusty has quit [Ping timeout: 240 seconds]
Alina-malina has quit [Ping timeout: 260 seconds]
Alina-malina has joined #bitcoin-wizards
Alina-malina has quit [Changing host]
Alina-malina has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Aaronvan_ has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 255 seconds]
Giszmo1 has quit [Quit: Leaving.]
v20100 has joined #bitcoin-wizards
execute has joined #bitcoin-wizards
str4d has quit [Ping timeout: 245 seconds]
v20100 has quit [Ping timeout: 246 seconds]
_whitelogger has joined #bitcoin-wizards
RubenSomsen has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
RubenSomsen has quit [Ping timeout: 240 seconds]
Storyteller has joined #bitcoin-wizards
sn0wmonster has joined #bitcoin-wizards
Storyteller has quit [Quit: Cheers...]
sn0wmonster has quit [Ping timeout: 246 seconds]
rusty has joined #bitcoin-wizards
Storyteller has joined #bitcoin-wizards
Storyteller has quit [Remote host closed the connection]
sn0wmonster has joined #bitcoin-wizards
sn0w has joined #bitcoin-wizards
sn0w has quit [Quit: ¯\_(ツ)_/¯]
Oizopower has joined #bitcoin-wizards
Storyteller has joined #bitcoin-wizards
Storyteller has quit [Quit: Cheers...]
Storyteller has joined #bitcoin-wizards
binaryatrocity has quit [Ping timeout: 272 seconds]
madacol_ has quit [Ping timeout: 245 seconds]
madacol_ has joined #bitcoin-wizards
n1ce has quit [Quit: Leaving]
madacol_ has quit [Ping timeout: 258 seconds]
madacol_ has joined #bitcoin-wizards
<waxwing>
so looking at the cryptonote ring sig again (after reading nickler 's article, thanks!), i'm sitting here wondering, would it break the algo. to use a NUMS point instead of Hash(pubkey point) as the basepoint for each of the key image equations?
Storyteller has quit [Quit: Cheers...]
deusexbeer has joined #bitcoin-wizards
Guest1887 is now known as teslax
Storyteller has joined #bitcoin-wizards
Storyteller has quit [Quit: Cheers...]
Guyver2 has quit [Quit: :)]
Storyteller has joined #bitcoin-wizards
Storyteller has quit [Remote host closed the connection]
<stevenroose>
bsm1175322, you here? I read Brahms, have a quick question: it heavily relies on limited push capabilities by peers. Apart from the BIP154 proposal, that's not how bitcoin works, so I guess it's not very useful now, right?
<stevenroose>
Also, I didn't fully grasp their concept of "push requests". At first, I thought a push was just a relay of a new node, so cfr an inadvertent addr of a new peer. But then it turns out their pushes only allows peers to push their own id. Since a "push request" is sent to a peer by it's id, I don't get how it adds any value
<stevenroose>
Apart from that, do you think the sampling part (so without the gossip protocol with limited pushes) would be useful on itself?
<bsm1175322>
stevenroose: I think you've read the paper more carefully than me now.
<bsm1175322>
It does seem reasonable though, if you accept (1) node ids and (2) this centralized "membership service"
<stevenroose>
what centralized membership service?
<bsm1175322>
Maybe I'm reading it wrong. Is it only per-node sampling?
<stevenroose>
btw, do you, or anyone else here, know how core does peer selection and/or know a reference to it?
<stevenroose>
bsm1175322, yes it's per-node. Every node maintains it's own small local view and a set of samplers that are used to create a uniform sample over the local view
<bsm1175322>
I know a little bit about peer selection, but it's constantly changing since it's not consensus critical and has other pressures, like finding fast relay nodes, compact block peers, or segwit peers.
<stevenroose>
bsm1175322, I suppose there have been studies to it's resilience to partitioning attacks, right?
<bsm1175322>
Oh yes, I remember now. I pasted this paper but stopped reading when I hit this statement: "Nodes are not allowed to use multiple ids, which rules out massive Sybil attacks [12]".
<bsm1175322>
stevenroose: yes, several. There's a recent one showing that segwit nodes accidentally partition themselves from non-segwit due to preferential peering with segwit nodes.
<stevenroose>
bsm1175322, yeah that's also a red flag that I struck. However if you have a good rate limiting system (i.e. PoW), I think that constraint is no longer needed
<bsm1175322>
That thought just occurred to me too. Perhaps I should give this paper a second chance...
<stevenroose>
Well, they heavily emphasize that they depend on the gossip protocol to have a system for limiting pushes
<stevenroose>
but since a push apparently is only advertising yourself to another node, I guess BIP154 is exactly that
<stevenroose>
(do bitcoin nodes currently push inadvertent addr's to other nodes? no, right?)
<bsm1175322>
What do you mean "inadvertent"?
<stevenroose>
without it being a reply to getaddr
<bsm1175322>
I don't know.
<bsm1175322>
So this to say, getaddr/addr is "pull" (and subject to poisoning) where they're proposing a "push" based mechansim?
laurentmt has joined #bitcoin-wizards
<bsm1175322>
Oh I see, they treat "push" and "pull" as two different sampling mechanisms, and use that to reduce bias in their peer list.
laurentmt has quit [Client Quit]
<bsm1175322>
Combined with BIP154, this seems like a very reasonable idea for Bitcoin.
<yoleaux>
Integrating ValueShuffle into the Mimblewimble protocol : Mailing list archive : mimblewimble team in Launchpad
jtimon has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 260 seconds]
RubenSomsen has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
<andytoshi>
waxwing: no, it would not break the protocol
<andytoshi>
waxwing: however, the attack jonas published would still work
<waxwing>
andytoshi: oh yes, no doubt about that
<waxwing>
i just found myself wondering what the point was in having distinct points for each element in the ring .. or even each tx come to that
<waxwing>
since a distinct pubkey is enforced for each tx iiuc
c0rw1n has quit [Ping timeout: 268 seconds]
<andytoshi>
waxwing: no idea. this occurred to me when i was first comparing the bytecoin ringsigs to the LWW ones (which are also 50% the size), i believe it's a holdover from the ringsigs' applicability to voting schemes
<andytoshi>
where you want one key image per election, rather than one period
<runeks>
Has research been done into using AES, instead of SHA256, as a proof-of-work function? Since AES is used in TLS, I figure the current hardware implementations should already be fairly efficient. Plus, I know newer Intel CPUs come with an AES instruction, meaning a relatively efficient and widespread hardware implementation would exist from the get-go.
<runeks>
I'm not sure exactly how it should be used. But probably either by using e.g. a hash of the previous block as the private key, and appending a nonce to the plaintext; or by keeping the plaintext constant and varying the private key (both until the ciphertext is of sufficient "difficulty").
goatturner has quit [Ping timeout: 246 seconds]
<runeks>
The important point is that an efficient AES implementation should exist in virtually all mobile devices already, since they need to encrypt data using TLS, and are highly power-constrained. This makes it much more decentralized than SHA256, since there's practically no need for a high-throughput hashing mechanism for anything but Bitcoin (and password
<runeks>
cracking).
<kanzure>
runeks: even if your claims of no remaining hardware optimizations of AES were true, it's trivial to spin up botnets to do AES-- it falls victim to the same problem as other pow changes.
<kanzure>
hence breaking your decentralization claim
<runeks>
I'm not claiming there are no remaining optimizations. I'm claiming that there is a use case for efficient AES already: TLS, meaning there's plenty of reason for companies not involved in Bitcoin to improve efficiency.
<kanzure>
arguably pow functions get optimized much more quickly than anything else due to the direct payout from mining.
<kanzure>
aes efficiency is not so strongly optimized by the industry.
<runeks>
kanzure: I'm not sure what your point about botnets is. Proof-of-work is proof-of-work.
<kanzure>
your point was about decentralization; botnet is not decentralized.
<runeks>
I'm not saying it's perfect. Just better than the current situation.
<renlord>
why AES, why not cuckoo cycles?
<runeks>
The hardware exists in decentralized form.
<runeks>
The more money a botnet can make from mining, the more money people can make from mining themselves. Just another incentive to run secure software.
<kanzure>
people generally run operations smaller than botnets, even if you look at people in aggregate
<runeks>
renlord: I'm not that familiar with how widespread symmetric encryption functions in hardware are. The important properties are soundness (AES has been tested a lot) and how widespread and efficient hardware implementations are.
<renlord>
runeks: if you use AES, you're effectively discriminating against the ARM architecture.
<kanzure>
at most you could argue that there's a temporary benefit from some people having existing aes hardware implementations, but that benefit gets stripped away pretty fast as botnets get spun up, or bitcoin asic manufacturers optimize their own implementation (aes hardware does not really do highly parallel stuff like a bitcoin asic manufacturer would choose to do).
<renlord>
iirc, x86 implements the AES instruction set to make AES functions more performant.
<runeks>
kanzure: That's the crux of it, I guess: how efficient are existing AES hardware implementations versus how efficient a dedicated ASIC miner can make it. I figure mobile chip makers have a pretty strong incentive to make efficient HW implementations already.
<renlord>
furthermore, the main issue with centralisation has little to do with ASIC, its the cost of power. It is simply cheaper to have many machines plugged directly to a hydro power station next door. Its economics.
<runeks>
renlord: I disagree. There are plenty of ways to produce cheap power, but very few companies, if any, besides TSMC that can produce efficient mining hardware.
<renlord>
runeks: there's also the issue of economies of scale. It is simply cheaper to run many dedicated hardware from a central location.
<kanzure>
if anything that's an argument for regular secret pow changes (but who gets in on the secret?); without pre-optimization you end up with botnet farmers earning the most revenue which is ungood and gets us back to miners-as-thugs.
Giszmo has quit [Ping timeout: 260 seconds]
<runeks>
"Secret pow changes" goes against everything Bitcoin stands for.
<kanzure>
well, possibly. if you want to get widely distributed hardware in a 'fair' way first-- it would have to be secret; otherwise someone is going to optimize the hell out of their own asic.
<kanzure>
similarly, handing over bitcoin mining to botnet operators is also against bitcoin ethos :)
tromp has quit [Remote host closed the connection]
<runeks>
Also, I don't agree that poor software security makes proof-of-work problematic. If people are running insecure software then that's a separate issue that needs to be addressed.
<kanzure>
what is that a reply to
<runeks>
That Bitcoin mining botnets are a problem of Bitcoin.
<kanzure>
i'm talking about the pre-existing non-bitcoin botnets
<kanzure>
they have many millions of machines.
<runeks>
I know
<kanzure>
these botnets are controlled by usually very small groups (probably one guy per large botnet)
<kanzure>
the decentralization in that scenario would be worse than current attempt at decentralization, i think.
<kanzure>
proof-of-work itself is only for the sake of decentralization, there's nothing about PoW that enforces bitcoin rules or anything-- so if you have like one guy running all the hardware you might as well just use a signature scheme to sign blocks.
RubenSomsen has quit [Ping timeout: 240 seconds]
Giszmo has joined #bitcoin-wizards
<kanzure>
runeks: one thing you could argue to me, which would be interesting, would be that the relative prevalence of ransomware is actually quite low compared to the total amount of botnet malware. so perhaps the rate of integration of a new bitcoin pow function into botnets would be as low as the prevalence of ransomware. (although those that do implement either ransomware/mining will probably ...
<kanzure>
...over time receive a selection effect advantage.. so over time it will be more prominent anyway.)
<Eliel_>
do we have any data about botnets mining altcoins?
<renlord>
why is it a bitcoin issue to address botnets mining coins?
<Eliel_>
renlord: it affects the overall network security properties
RubenSomsen has joined #bitcoin-wizards
<kanzure>
malware operators vs large businesses with regulatory oversight you pick :P
<renlord>
its a permission-less consensus network, it does not discriminate.
<renlord>
@.@
<Eliel_>
renlord: precisely. Hence, it's important to pay attention to which parties the choice of PoW function favors.
<benthamshead>
<stonecoldpat> I would side with renlord, but argue that choosing a pow should not provide any party a starting advantage. If it benefits established businesses or botnets then that isn't a great start.
<kanzure>
the argument for secret pow change is that the secrecy time gives an opportunity to widely deploy the hardware. unfortunately there are theoreitcal problems with how to prove fairness after secrecy period is over.
tiny has joined #bitcoin-wizards
<renlord>
frankly, I don't see any problems with mining centralisation as is right now so as long as there exist a vastly superior number of independent nodes doing the verification.
<renlord>
it'd be impossible to beat economies of scale and force mining decentralisation.
sudoScience has joined #bitcoin-wizards
<sudoScience>
okay im confused by something and i admit its probably im underinformed and ignorant but i want to understand. it sounds like a UASF is actually a User Activated (Hard) Fork. okay, so i dont think a hard fork is a good idea because i dont think a chain split is a good idea. i was against a hard fork for any reason, even to increase block size which we so desperately need. segwit increases the blocksize without having to hardf
<sudoScience>
, therefore its a good thing. however isnt it shooting ourselves in the foot if we hardfork to segwit, as that's what segwit was postponing anyways?
<sudoScience>
not really asking a question specifically or anything, just looking to see what you guys have to say
<sudoScience>
its my understanding that a soft fork is a fork that does not break backwards compatibility, and isnt that the exact and only purpose of a UASF?
<sudoScience>
---^I posted this earlier in the bitcoin channel and didnt get much discussion.dont want to spam but just asking for opinions. doesnt anyone else think this UASF is risky business?
<sudoScience>
i also accept that i might be ignorant on the subject
Chris_Stewart_5 has quit [Ping timeout: 245 seconds]
<belcher>
sudoScience segwit is a soft fork not a hard fork
<belcher>
perhaps the phrase you're looking for is "chain split", which can happen as a result of soft forks (see the bip66 example)
Aaronvan_ has quit []
<sudoScience>
belcher: okay thank you for that. that is helpful
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
<sudoScience>
youre right chain split is the big concern. so if there is a chain split am i correct to understand that the economic pressures to shrivel up and the leak value to the segwit chain will be what kills the legacy chain?
<Eliel_>
sudoScience: also note that the splitting risk is higher in BIP148 than what would usually be meant by UASF
<Eliel_>
a normal UASF only splits if a miner deliberately makes it happen (and the miners wanting to make it happen have 50+% of mining power). BIP148, however, splits if less than 50% of miners have chosen to signal for segwit by the activation time.
crypt0kraken has joined #bitcoin-wizards
crypt0kraken has quit [Max SendQ exceeded]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
v20100 has joined #bitcoin-wizards
rusty1 has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
LeMiner has quit [Read error: Connection reset by peer]
LeMiner has joined #bitcoin-wizards
flandero has joined #bitcoin-wizards
flandero is now known as mn3monic
tiny has quit [Ping timeout: 240 seconds]
mn3monic has quit [Changing host]
mn3monic has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
tiny has joined #bitcoin-wizards
RubenSomsen has quit [Ping timeout: 268 seconds]
RubenSomsen has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 260 seconds]
<stevenroose>
if I test scriptPubKeys and corresponding scriptSigs and they work as intended, I can assume that they can also be used in P2SH and P2WSH, right? Without any precautionary measures?
<sipa>
the redeemscript in P2SH is at most 520 bytes
<sipa>
and the scriptSig must be push only
RubenSomsen has quit [Ping timeout: 240 seconds]
RubenSomsen has joined #bitcoin-wizards
AaronvanW has quit []
AaronvanW has joined #bitcoin-wizards
<stevenroose>
sipa, wait, in traditional terms (at least I think because that's how I think they used to be), you have
<stevenroose>
scriptPutKey - the script on the output; and
<stevenroose>
scriptSig - the script on the input, right?
<sipa>
yes
<stevenroose>
I guess those names have different meaning in p2sh context
<sipa>
and to P2SH-ify it, you turn the scriptSig into scriptSig + push of scriptPubKey
<stevenroose>
ah you mean scriptSig only push because the while script is a push?
<stevenroose>
whole*
<stevenroose>
okk got it
<sipa>
no, every operation in the resulting scriptSig has to be a push
<sipa>
which is not a requirement for non-P2SH (but it is a standardness rule)
<stevenroose>
yeah I mean the previous scriptPubKey is encoded in a push on the scriptSig now
<gmaxwell>
P2WSH has the additional restriction that keys must be compressed.
<sipa>
yes
<sipa>
but i'm not talking about that :)
<stevenroose>
srry was a bit confused
<stevenroose>
got it now
<sipa>
the redeemscript is the actually executed script
<sipa>
so the thing that is pushed at the end of the scriptSig is the redeemscript
<stevenroose>
ah ok, didnt know that term
<stevenroose>
so I get lost when the redeemscript contains checksigs
<stevenroose>
oh actually I don't, think I get it
<stevenroose>
the signature only depends on the outputs of the whole new tx (in case of sighash_all)
<sipa>
the redeemscript can contain a checksig... that's very normal
<stevenroose>
right?
<sipa>
yes, and on the scriptcode
<stevenroose>
yeah I mean when migrating a normal scriptPubKey into a redeemscript, the signatures obviously chcange
<stevenroose>
but you can generate them just as easily
<sipa>
yes
<stevenroose>
weell, "easily", let's say in the same way
<stevenroose>
great, thanks
<stevenroose>
I just drafted this script based on a lightning htlc, didnt vet or test yet, but do you see any obviosu red flags?
<stevenroose>
goal is for the initiator to send the money to counterparty only when it provides the preimage and otherwise refund it after timeout
<stevenroose>
it's like a simplified htlc I guess
RubenSomsen has quit [Ping timeout: 245 seconds]
<arubi>
stevenroose, you should check out zero knowledge contingent payments
<arubi>
I don't actually.. I read about it on the bitcoin wiki and some random interesting threads, but never tried applying it myself
<arubi>
ah and this :)
<stevenroose>
I struggled a bit with the fact that CHECKLOCKTIME does not exist (without VERIFY)
<stevenroose>
I'd prefer the case that it's also impossible to spend wth the preimage after the timeout
<sipa>
yeah, not going to happen :)
<arubi>
it has to either do nothing or fail, else it wouldn't be a nopp'ed soft fork
<sipa>
arubi: no
<stevenroose>
sipa, ah that tx is exactly mine lol
<sipa>
it could still be a softfork while doing what stevenroose asks for
<arubi>
oh? enlighten please
<stevenroose>
ah no it has an OP_DROP
<stevenroose>
hmm
<sipa>
but it would be monotonicity of transaction validity
<sipa>
*break
<stevenroose>
oh yeah the verify doesnt drop the locktime value
<sipa>
meaning you'd need to re-evaluate every transaction for every block
<arubi>
oh I see!
<arubi>
yep, understood
<sipa>
and wallet receivers wouldn't know for certain if an unconfirmed transaction could really ever confirm
<stevenroose>
sipa is there a workaround that accomplishes that?
<stevenroose>
like do an if-else based on locktime
<sipa>
you can't branch on locktime, but you don't have to
<sipa>
just create two branches, one that demands a certain locktime and one that doesn't
<stevenroose>
yeah but say (in the script I linked you), the initiator wants to refund using the locktime branch because the timeout passed and he get's boycotted by a miner so that the counterparty wins the race
<stevenroose>
solution is to set the real-world timeout sufficiently after the on-chain timeout
<stevenroose>
but still the counterparty can win a race
<stevenroose>
wait that solution doesnt work at all
c0rw1n has joined #bitcoin-wizards
<stevenroose>
(gtg, back in an hour or so. thanks already anyways :) )
<kanzure>
Eliel_: i think it's a good question. maybe fluffypony or someone will have info on botnets + altcoin mining.
belcher has quit [Ping timeout: 240 seconds]
goatturner has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
Guyver2 has joined #bitcoin-wizards
Guyver2 has left #bitcoin-wizards [#bitcoin-wizards]
Storyteller has joined #bitcoin-wizards
Storyteller has quit [Quit: Cheers...]
jtimon has joined #bitcoin-wizards
kmels has quit [Ping timeout: 260 seconds]
tromp has joined #bitcoin-wizards
moneyattracts has joined #bitcoin-wizards
<moneyattracts>
can someone please help
tromp has quit [Ping timeout: 268 seconds]
moneyattracts_ has joined #bitcoin-wizards
<moneyattracts_>
please help
<stevenroose>
moneyattracts_, I guess #bitcoin is a better place for general Bitcoin related support :)
<moneyattracts_>
I dont know what to do I thought was in the right place
<sipa>
moneyattracts_: 1) don't ask to ask, just state your question
<sipa>
2) this channel is not about anything that exists in bitcoin today, but for long term research
<moneyattracts>
I have a transaction thats been in Blockchain sin ce like the 12th of May was sent back by the network to start over again sent to Polo address right and eveything
<sipa>
totally off topic here, try #bitcoin or stackexchange
<moneyattracts>
I tried the excelerater over at vita
skeuomorf has quit [Ping timeout: 260 seconds]
moneyattracts has quit [Quit: Page closed]
moneyattracts_ has quit [Quit: Page closed]
kmels has joined #bitcoin-wizards
sinahab has joined #bitcoin-wizards
sinahab has quit [Client Quit]
tromp has joined #bitcoin-wizards
airbreather has quit [Read error: Connection reset by peer]
smk has joined #bitcoin-wizards
rmwb has joined #bitcoin-wizards
rmwb has quit [Remote host closed the connection]
tromp has quit [Remote host closed the connection]
AaronvanW has quit []
tiny has quit [Ping timeout: 245 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
smk has quit [Ping timeout: 260 seconds]
airbreather has joined #bitcoin-wizards
mn3monic has quit [Read error: Connection reset by peer]