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
archobserver has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
zooko` has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 272 seconds]
zooko has quit [Ping timeout: 276 seconds]
zooko` is now known as zooko
darmou has joined #bitcoin-wizards
ratbanebo has quit [Read error: Connection reset by peer]
ratbanebo has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 276 seconds]
Yoghur114 has quit [Remote host closed the connection]
zooko has quit [Read error: Connection reset by peer]
zooko` has joined #bitcoin-wizards
Quanttek has quit [Ping timeout: 276 seconds]
GAit has joined #bitcoin-wizards
zooko` is now known as zokoo
zokoo is now known as zooko
<bramc>
At the moment I'm considering making blocks have a size limit of 16k for encoding reasons. Sound reasonable?
<bramc>
A 'block' should be a bit less than the amount of stuff which gets retrieved from a single memory access
Jeremy_Rand has joined #bitcoin-wizards
<bramc>
In addition to is_included() which returns a boolean I'm going to have get_proof() which returns a boolean and a proof
<bramc>
And standalone functions confirm_included(root, val, proof) and confirm_not_included(root, val, proof)
ghostedcitizen has joined #bitcoin-wizards
<ghostedcitizen>
question in regards to mining blocks through bitcoin. Is the algorithm to mint coins separate from confirming transactions or is it the same thing?
<sipa>
#bitcoin please
<ghostedcitizen>
ten four
_alp_ is now known as alpalp
<bramc>
One thing my Python Merkle set is *not* going to do is parallel hashing. That will have to be done in the C port. It will do lazy hashing though, so 'in principle' adding such parallelism is 'easy'
<kanzure>
was this source code public linked yet
<kanzure>
haven't been paying close attention
<bramc>
kanzure, I haven't written the first line yet, so no. I'm finishing up working out the byte format of it
<bramc>
As in, I have notes on an exact byte format sitting here on my desk, and if I don't change them tomorrow I might actually start coding it.
Guest51134 is now known as pigeons
<gmaxwell>
17:02 < pindarhk> ScalingBitcoin.org: Please note that we've extended the deadline for proposals to Nov 11, 2015 at 23:59 UTC. Please see https://scalingbitcoin.org/hongkong2015/#cfp
<ebfull>
other than the fact that a transaction is meaningless with empty vin/vout vectors, are there any assumptions made elsewhere in bitcoin that would be adversely affected by the presense of such a transaction?
<ebfull>
right now it's explicitly prohibited, but are there any reasons aside from "there's no point to a transaction with no inputs and outputs"
<kanzure>
you can instantiate a transaction without those parameters, without sending to network
<ebfull>
if they were allowed, what invariants might it violate?
GAit has quit [Quit: Leaving.]
<ebfull>
one thing might be the expectation of the end user that the vectors are populated
<nwilcox>
If there are txns with 0 ins but some outs, or vice-versa, the graph of transactions would be partitioned, so any graph-crawling algorithms may stick in a subgraph.
<nwilcox>
If there any containers that index by outpoint, for example, and then code iterates over the container's values assuming all txns are covered, such code would fail.
GAit has joined #bitcoin-wizards
GAit has quit [Client Quit]
<bramc>
ebfull, There wouldn't be any way to pay for it
<ebfull>
bramc: nwilcox: that's a good point, thanks. in our situation paying for it should be covered by other means
<zooko>
Folks: ebfull and nwilcox are part of the Zerocoin Electric Coin Company team, and we're trying to understand this in order to understand how best to fit in zk-SNARK Zerocash transactions with current Bitcoin transactions.
<zooko>
☺
<sipa>
ebfull: having no inputs would mean the transaction hash cannot be guaranteed to be unique
<sipa>
ebfull: which it is in bitcoin, because coinbases have the height in their input, and other transactions have the hashes of other transactions
<ebfull>
sipa: niiice, we'll have to preserve that invariant
<jcorgan>
zooko: is there an updated whitepaper on the details of the new ZC implementation?
<nwilcox>
jcorgan: Not yet.
<jcorgan>
is it an entirely new thing from the original ZC concept or a variation
erasmospunk has quit [Remote host closed the connection]
snthsnth has joined #bitcoin-wizards
ratbanebo has quit []
snthsnth_ has joined #bitcoin-wizards
snthsnth has quit [Ping timeout: 255 seconds]
zooko has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
bramc has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
bramc has quit [Client Quit]
zooko has quit [Ping timeout: 240 seconds]
zooko` has joined #bitcoin-wizards
rusty has left #bitcoin-wizards [#bitcoin-wizards]
DougieBot5000 has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
gwency has joined #bitcoin-wizards
CodeShark has quit [Ping timeout: 246 seconds]
OneFixt has quit [Remote host closed the connection]
matsjj has quit [Remote host closed the connection]
[7] has quit [Disconnected by services]
TheSeven has joined #bitcoin-wizards
tulip has quit [Remote host closed the connection]
bramc has joined #bitcoin-wizards
metric has joined #bitcoin-wizards
jtoomim has joined #bitcoin-wizards
kgk has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
mrkent has quit []
kgk has quit [Ping timeout: 240 seconds]
<Taek>
two questions about weak blocks
<Taek>
1. what is incentivizing someone to create weak blocks?
gwency has quit [Quit: This computer has gone to sleep]
<Taek>
2. what is stopping an attacker from ignoring the weak blocks and creating difficult-to-validate blocks anyway?
<bramc>
Taek, 1. If you make a weak block and then introduce it to the network your own subsequent blocks are more likely to propagate quickly
<bramc>
2. All such an attacker would succeed in doing is making it more likely for their own block to get orphaned
<Taek>
not strictly true. There are network configurations where an attacker with sufficient mining power can drive the revenue of smaller miners down
<aj>
Taek: 1: you make weak blocks automatically while trying to make a real block, the only extra work is publishing it
<Taek>
*by making expensive-to-validate blocks
<Taek>
maybe I am overly concerned about the potential impact though
<Taek>
I want to make sure that, in all realisitic worst-case scenarios, we limit the pressure towards miner centralization
skyraider has quit [Quit: Connection closed for inactivity]
<Taek>
if we assume that there is a substantial transaction backlog, occasionally there will be two strong blocks found back-to-back, with no weak blocks to use as support
mrkent has joined #bitcoin-wizards
<Taek>
and you end up with a race that is equivalent to the races we see today
<Taek>
but if you require that a full block be within X bytes of the nearest weak block, you put a limit on the worst-case race
<Taek>
(you'd probably also need to require that weak blocks be within X bytes of eachother, and stack)
<Taek>
then, if we assume an adversary miner that is trying to make slow-validating blocks, the adversary is limited in effectiveness unless it is creating and hiding weak blocks
zooko` has quit [Ping timeout: 246 seconds]
<Taek>
and, if there is a financial incentive for sharing weak blocks, that introduces an opportunity cost to the adversary for hiding weak blocks
tulip has joined #bitcoin-wizards
<Taek>
I think, there is another advantage to this scheme - right now in Bitcoin validating nodes can occasionally get slammed with a ton of blocks in a tight window
<Taek>
but, if you are requiring that each block be built out of weak blocks, each of which can only add so many bytes, then it's much less likely that you'll get to such high throughputs in a tight window
<Taek>
and, it's safer to have longer blocks be larger, because they will likely be composed of many weak blocks.
<Taek>
essentially, you get a transaction throughput that is more correlated with the amount of time that has passed between blocks compared to today's scheme
mrkent has quit [Read error: Connection reset by peer]
<Taek>
I don't really know how one might financially incentivize sharing weak blocks, other than sharing the subsidy, which is a temporary solution for Bitcoin
<Taek>
(where the incentive is used to create opportunity cost for adversarial behavior)
<aj>
Taek: any strong block is also a weak block though -- weak blocks just have a lower minimum difficulty
<aj>
Taek: the odds of finding a strong block as your first weak block are exponentially low depending on the difference in difficulty between strong and weak
<bramc>
Requiring strong blocks be made of weak blocks and that weak blocks have their own maximum size would lower the overall transaction limit
licnep has quit [Quit: Connection closed for inactivity]
<Taek>
aj: it's only linearly low. If weak blocks are 1/64 the difficulty, then 1/64 of the time you are going to find two strong blocks in a row
<Taek>
bramc: not if you remove the maximum size requirement for a strong block
<el33th4x0r>
Taek: weak blocks would make centralization worse. small miners are unlikely to come up with a weak block candidate, and when they find a real block, the propagation of that real block will be slow
<el33th4x0r>
large miners are unaffected, and that creates pressure towards centralization.
<Taek>
el33th4x0r: not at all. small miners will build their strong blocks on top of the weak blocks that other miners have found
<Taek>
they still get the benefits of fast propagation
<el33th4x0r>
Take: that takes away their power to select what transactions go into a block.
<Taek>
It reduces censorship. They can still add X bytes of their own transactions, but they are limited in what they are allowed to exclude
<el33th4x0r>
Taek: also, it's easy for large miners to keep small ones out: just include a private transaction that is never broadcast to small miners
<Taek>
el33th4x0r: I don't see what you mean by that? How can you have a private transaction? It's a public blockchain. Unless you mean a private weak block?
<Taek>
the biggest potential problem that I see here is that by forcing strong blocks to be built out of weak blocks, you essentially make things non-progress-free. But it's not the POW itself that isn't progress-free, it's just the block composition
<bramc>
Taek, No the problem is the maximum size for a weak block. If a strong block comes up quickly and it's required to be made of weak blocks it will only have so many weak blocks worth of transactions to cobble together
<Taek>
bramc: that's the point. You make throughput time-based
<Taek>
the expected throughput stays the same, to use a concrete example:
<bramc>
Taek, It's already time-based, just more granular
<Taek>
right, you get a better granularity
<el33th4x0r>
Taek: a large miner can create a weak block that includes a set of private transactions. the large miner never transmits the private transactions to the small miners. the small miners are now either "SPV mining" or else, if they want to validate all xactions, they need to create their own weak block by finding a weak solution, but their hash power
<el33th4x0r>
might be too small to find it in time.
<Taek>
bramc: the expected throughput stays the same unless you put a cap on the max strong block size in addition to capping the max weak block size.
<Taek>
which might be a sane thing to do
<Taek>
el33th4x0r: the small miners would respond to the 'secret' weak block the same way they'd respond to a 'secret' block on the current blockchain: they'd ignore it
<el33th4x0r>
Taek: ok, if they ignore the weak blocks that contain private transactions, which weak blocks do they build on?
<Taek>
el33th4x0r: what you are suggesting is equivalent to a 51% attack.
<Taek>
Instead of building on the weak blocks that they can't parse, the build on the weak blocks that they can parse
<Taek>
but this is why I was saying it would be nice to have a financial reward for sharing a weak block
<el33th4x0r>
Disagree, not at all equivalent to a 51% attack. It can happen without a 51%er. And it can happen naturally, without coordination.
<el33th4x0r>
Taek: all it requires is for the large miners to possess and want to include some transactions that the small miners have not seen.
<el33th4x0r>
Taek: can happen consistently if the small miners have a slow connection
<Taek>
either a miner is broadcasting the weak blocks they are finding, or the miner is hiding the weak blocks they are finding, or the miner is only sharing the weak blocks they are finding with a subset of other miners. Which scenario are you talking about?
<el33th4x0r>
take the first one, the most benign, straightforward case. weak blocks pose centralization problems even in that case.
<Taek>
explain
<el33th4x0r>
large miners see a set of xactions and include them in their weak weak blocks.
<el33th4x0r>
small miners do not see those transactions yet.
<el33th4x0r>
they now have to discover their own weak block, but their hash power is too small to do this effectively.
<el33th4x0r>
the large miners have a persistent advantage.
<el33th4x0r>
if the small miner gets lucky and finds a real (strong) block, he will have difficulty propagating it, because it is not based on a weak block.
<el33th4x0r>
large miners do not suffer from this problem. weak blocks exacerbate centralization.
<Taek>
there will be no difficulty propagating it if it is not based on a weak block; it will be small
<Taek>
perhaps you mean to suggest that small miners will on average find smaller blocks than large miners? This would put them at a disadvantage because it means less income from fees.
<Taek>
I believe you could show that, despite this, it's still a strictly-superior construction to the way things work today
<el33th4x0r>
that too, but this discussion was prompted by limiting "the pressure towards miner centralization."
<el33th4x0r>
disagree. weak blocks do not appear strictly superior. they provide an advantage to large miners
<Taek>
(I say that, and then gmaxwell points out several critical problems with my suggestion)
<el33th4x0r>
(yeah he does that! :-)
<Taek>
I need to go to bed, but I will leave a final remark that you have definitely not convinced me that my weak block scheme provides an increased advantage to large miners compared to the way things work today
<Taek>
I will sleep on it and see if anything useful happens
<el33th4x0r>
same here. and nor have you convinced me that the difference is small. if weak blocks are worth implementing at all, then the difference ought to be substantial.
Giszmo has quit [Quit: Leaving.]
ThomasV has joined #bitcoin-wizards
snthsnth_ has quit [Remote host closed the connection]
<fluffypony>
sipa: they reckon someone exploited the bug you found (not sure which one they're referring to)
darmou has joined #bitcoin-wizards
<fluffypony>
oh bip66
kgk has joined #bitcoin-wizards
atgreen has quit [Ping timeout: 252 seconds]
kgk has quit [Ping timeout: 250 seconds]
<gmaxwell>
lol; zombie developer broadcast block signing forced the invalid signature into the chain.
<sipa>
fluffypony: sounds pretty literally the specific example i mentioned in the bug report
<fluffypony>
yup
wallet42 has joined #bitcoin-wizards
gonedrk has quit [Quit: Leaving]
p15x has quit [Ping timeout: 276 seconds]
<katu>
sipa: is ppcoin the only fork with this bug? i image ton of bitcoin alts are vulnerable to this
<katu>
as half of those dont bother merging from upstream
<katu>
*imagine
<sipa>
i imagine nearly all of them are vulnerable
<gmaxwell>
to that an a hundred other issues.
<fluffypony>
yup
<fluffypony>
which is why I always giggle when they make grandiose claims about having fixed
<fluffypony>
"fixed what the Bitcoin devs can't" or some such
Thireus has joined #bitcoin-wizards
<jgarzik>
:)
Thireus has left #bitcoin-wizards [#bitcoin-wizards]
<katu>
fluffypony: thats why only those which are not actually bitcoin codebase seem to be only somewhat interesting.
<fluffypony>
katu: agreed
<katu>
even there bitcoin has best track record. iirc bitcoin suffered 2 consensus bugs, monero 1, nxt too many to count :)
gribble has quit [Remote host closed the connection]
<jgarzik>
katu, Those still must fix many of these same problems, just in a different codebase - while adding new problems all their own :)
eudoxia has quit [Quit: Leaving]
<fluffypony>
jgarzik: that's true, but on the flipside the Bitcoin forks have a terrible track record of even keeping up with Bitcoin's commits
<katu>
jgarzik: yeah, reinventing wheel is the difficult, brave path
<fluffypony>
let alone doing anything innovative
<jgarzik>
agreed ^2
<katu>
and some codebases (eth and bitshares) are outright scary balls of hairy C++ code
AaronvanW has joined #bitcoin-wizards
<fluffypony>
katu: I'm not convinced we (Monero) don't have more consensus bugs lurking in the parts of the codebase we don't often touch, but at least we've started making things cleaner by replacing most of the crypto with SUPERCOP ref10 and other reference implementations
<jgarzik>
Eth has a bunch of different implementations. Which sees majority use? I don't know.
<jgarzik>
Bitshares code is quite scary.
dEBRUYNE_ has joined #bitcoin-wizards
<fluffypony>
jgarzik: oh it's much worse than that...they're PROUD about how many implementations they have, and then in the same breadth they admit that their security auditors have basically said that the mishmash of code is impossible to audit
<sipa>
jgarzik: having different imementations means that every implicit behaviour specific to an implementation is a consensus bug
<jgarzik>
sipa, I had no idea!
<jgarzik>
;p
<sipa>
it's a nice thought... starting out with multiple implementations to make sure the consensus doesn't diverge
<sipa>
i certainly have believed that that was the right way to do things
<katu>
well, what if you consider consensus bugs as part of the byzantine generals problem?
<katu>
ie the implementation with most hashpower simply wins. the end :)
<fluffypony>
lol
<sipa>
but it just doesn't work... we've seen too many times in bitcoin that we simple don't have the technology to predict all behaviour a piece of code exhibits
<katu>
fluffypony: you mean blockchain.info? it does not seem like an implementation. bitcoinjs started off as a source port of some parts of bitcoinj iirc.
<katu>
"probably works in browser too, via incomplete browserify abstraction"
bramc has quit [Quit: This computer has gone to sleep]
soiled has joined #bitcoin-wizards
<jgarzik>
After many years of software development, I'm reluctantly concluding that C++ may be a good language for secure finance software. (Reluctant because I love C99, have written a couple compilers myself, and know more about the language than most)
<jgarzik>
Rust is a great contender. D and Go, meh.
<sipa>
if only C had destructors
<fluffypony>
I agree jgarzik
<fluffypony>
his comment on Go's simplicity really drives the point home
nwilcox has joined #bitcoin-wizards
<sipa>
or C++'s use of the heap was optional
<fluffypony>
it's like writing everything in Logo
<jgarzik>
sipa, It's optional if you do a shitload of work :)
<jgarzik>
replacing STL etc.
nwilcox has quit [Client Quit]
<moa>
"reluctantly concluding" ... sounds like a ringing endorsement
<gmaxwell>
sipa: When creating the opus standard, we created a second seperate decoder implementation to test agreement, then threw it out. Key point being throwing it out.
<jgarzik>
moa: It physically pains me to diss C ;p
<moa>
heh
<katu>
sipa: nothing stops you doing the c-with-classes shtick in c++. you still get the RAII. problem is even then it brings its c++ problems down the road.
<katu>
sipa: aka spooky-action-at-a-distance in c. eew.
<sipa>
jgarzik: wouldn't be typical C++
<sipa>
but yes, new STL would do it :)
<katu>
isnt the "new STL" todays javascript frameworks in the 90s?
* katu
reluctantly agrees that boost/stl are reasonable "universal" helper abstractions
<katu>
anything "new" would simply sacrifice this universality. hence the only other way is to simply do c with classes (and some light templating instead of macros)
<sipa>
my problem is the lack of guarantees on memory usage
<jcorgan>
i guess i'm the holdout. i really like go's simplicity. i have a little heartache with its lack of dynamic linking, but supposedly i'll get over that
roxtrongo has joined #bitcoin-wizards
<katu>
sipa: frankly, the heap pressure in c++ is frankly somewhat overstated. stl does support custom allocators. thats the strenth of universality. (and weakness because additional complexity).
<jgarzik>
Debugging - or even parsing compiler error messages - quickly becomes a pain.
<sipa>
c++14 adds template constraints, so you don't get book-long debug messages anymore
<jcorgan>
heh, i once had a 250KB error message from a single letter typo
<jcorgan>
boost+stl
<katu>
sipa: even with stl/boost instantiations? thats kinda hard to believe :)
ThomasV has joined #bitcoin-wizards
<sipa>
katu: yes
roxtrongo has quit [Ping timeout: 260 seconds]
<sipa>
katu: the template just defines properties the type parameters have to obey too, so the compiler doesn't need to go try everything anymore
<sipa>
and can just state that a constraint isn't satisfied
<katu>
sipa: finally. so no more awkward type traits. sure, that will cull down some sorts of long messages. but i still think some other bugs are much deeper in the rabbit hole than mere type resolution conflicts.
darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
CoinMuncher has quit [Quit: Leaving.]
soiled has quit [Quit: Leaving]
waxwing has quit [Read error: Connection reset by peer]
waxwing has joined #bitcoin-wizards
LeMiner has quit [Ping timeout: 246 seconds]
darmou has joined #bitcoin-wizards
LeMiner has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
orik has joined #bitcoin-wizards
grandmaster has joined #bitcoin-wizards
<fluffypony>
can anyone remember that recent paper that highlighted the risk in node isolation attacks?
<katu>
fluffypony: yeah, HS involve some unique challenges, but traditional eclypse is pretty much rebuttal to that
<andytoshi>
fluffypony: regarding D/Go/Rust, I don't know much about D or Go, but i can say that his complaints about rust are silly .. you spend more time organizing code to be memory safe maybe, but then you are certain that all access patterns are safe, and that all users of your library will use it safely. GC is useless for this, all it does is prevent use-after-free and has nothing to say about data races,
<andytoshi>
mutation from multiple places (including things like iterator invalidation), keeping track of where objects are alive and where they may be mutated, etc. rust takes like 95% of the thinking out of this. and calling this "just one issue" is really disingenuous, that's like calling "manipulating data" "just one issue"
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<andytoshi>
as for complaints about syntax, rust has far better metaprogramming and generics than either D or Go, and doesn't resort to ugly hacks to deal with parser ambiguities like some languages
<fluffypony>
well he is the creator of D, so there's that
LeMiner has quit [Read error: Connection reset by peer]
<katu>
andytoshi: that d/go/rant needs more haskell when we're all in for state safety guarantees :)
<andytoshi>
katu: sure, but rust gets you a lot of the benefits of haskell (the main thing it's missing are higher-kinded types) with a syntax that's usable for imperative/stateful programming
damethos has quit [Quit: Bye]
<katu>
andytoshi: yeah, i cant decide if i love or hate rust for that
<katu>
it brings forth the painful memories of haskell
<andytoshi>
plus it interoperates better with C and is faster and (they put a lot of effort into this) name things with understandable words
<andytoshi>
e.g. haskell sum types are called "enums" in rust
jona_ has joined #bitcoin-wizards
<katu>
andytoshi: imo rust has to deliver on its promises for mass audience to believe it. it tries to peddle "haskell with human face" and people are not falling for that trick.
<katu>
but if mozilla will suddenly leap in front of chrome because of servo, folks will notice.
<andytoshi>
katu: really? go talk about haskell in #rust and see how quickly people tell you to stop talking about haskell, rust is not haskell, etc
darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<katu>
andytoshi: thats just the usual zalots being zealots :)
<andytoshi>
there is a pushback against the haskell people trying to make the language hard to understand :)
<andytoshi>
no, it's specifically haskell
<katu>
they hate when somebody likes their apple to similiar orange
DrHex_351 has joined #bitcoin-wizards
<sipa>
haskell explicitly hides execution flow from the programmer
<sipa>
rust pretty much does the opposite, as fae as i understand
<gmaxwell>
katu: I've _never_ heard anyone involved with rust make any kind of comparison that sounded remotely like "haskell with human face".
<katu>
sipa: well, i just ignore the whole functional/imperative for the moment.
<DrHex_351>
Lol, i just watch your youtube Greg :)
<katu>
gmaxwell: ever heard of people comparing lua to scheme?
<sipa>
katu: that's like comparing christianity to buddhism and say "let's forget this god thing for a momemt"
<DrHex_351>
and after 5 seconds, haskell is mentioned
<katu>
gmaxwell: dont be so focused on functional paradigm purity. thats just superficial.
<katu>
sipa: exactly :)
<gmaxwell>
huh? I didn't say anything about functional anything.
<sipa>
i may have brought that up... i believe it's dar deeper than that
<sipa>
haskell makes execution safe by hiding it
<katu>
sipa: both introduce fair amount of spooky action at a distance
<gmaxwell>
You made a statement which was more or less factual, and incorrect. I was just commenting on that; regardless of how similar they are (they really aren't similar), it's still not a comparison anyone is making.
<katu>
gmaxwell: your discontent aside, sure you're right. haskell as a nazi-ml is far more confining than anything shared state procedural (no matter the amount of state safety provided via other means).
<katu>
meaning rust will probably deliver some large-scale system written in it. haskell? people stopped believing long ago.
jona_ has quit [Quit: Page closed]
nonaTure has joined #bitcoin-wizards
<maaku>
this is incredibly far off-topic. please take it to #haskell or #rust or whatever
matsjj_ has quit [Remote host closed the connection]
Jeremy_Rand has joined #bitcoin-wizards
<nonaTure>
anybody wants to join at #blockchain-wizards?
<kanzure>
nope.
<sipa>
nope.
<katu>
nope. this is #haskell-wizards now.
Dizzle has joined #bitcoin-wizards
Yoghur114 has joined #bitcoin-wizards
<jgarzik>
Nein
mjerr has quit [Ping timeout: 252 seconds]
zooko has quit [Ping timeout: 240 seconds]
<fluffypony>
lol, inb4 "censorship" claims
Krellan has quit [Excess Flood]
Krellan has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 240 seconds]
skyraider has quit []
skyraider has joined #bitcoin-wizards
roxtrongo has joined #bitcoin-wizards
roxtrongo has quit [Ping timeout: 240 seconds]
LeMiner has joined #bitcoin-wizards
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<waxwing>
i'm going to #pinball-wizards
fkhan has quit [Ping timeout: 240 seconds]
bramc has joined #bitcoin-wizards
RoboTeddy has joined #bitcoin-wizards
DrHex_351 has quit [Quit: Page closed]
nwilcox has joined #bitcoin-wizards
darmou has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
GAit has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 240 seconds]
wallet42 has quit [Ping timeout: 240 seconds]
fkhan has joined #bitcoin-wizards
fkhan has joined #bitcoin-wizards
fkhan has quit [Changing host]
fkhan has joined #bitcoin-wizards
GAit has quit [Client Quit]
GAit has joined #bitcoin-wizards
Krellan has quit [Ping timeout: 246 seconds]
wallet42 has joined #bitcoin-wizards
jgarzik has quit [Quit: This computer has gone to sleep]
jgarzik has joined #bitcoin-wizards
darmou has joined #bitcoin-wizards
Krellan has joined #bitcoin-wizards
jgarzik has quit [Client Quit]
darmou has quit [Client Quit]
darmou has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
jgarzik has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
darmou has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
damethos has quit [Quit: Bye]
damethos has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
bramc has joined #bitcoin-wizards
Guest8443 is now known as berndj
dEBRUYNE__ has joined #bitcoin-wizards
dEBRUYNE_ has quit [Read error: Connection reset by peer]
<nsh>
"their security auditors have basically said that the mishmash of code is impossible to audit" # that means you pass automatically, right?
zooko has quit [Read error: Connection reset by peer]
sharperguy has joined #bitcoin-wizards
CodeShark has joined #bitcoin-wizards
Emcy has quit [Read error: Connection reset by peer]
zooko has joined #bitcoin-wizards
bramc has quit [Quit: This computer has gone to sleep]
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has joined #bitcoin-wizards
<AdrianG>
whose code
kgk has joined #bitcoin-wizards
Meeh has quit [Read error: Connection reset by peer]
<nsh>
bitshares, i think
Meeh has joined #bitcoin-wizards
kgk has quit [Ping timeout: 255 seconds]
belcher has joined #bitcoin-wizards
matsjj has joined #bitcoin-wizards
nabu has joined #bitcoin-wizards
soiled has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
matsjj has quit [Remote host closed the connection]
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
nabu has quit [Ping timeout: 244 seconds]
Emcy has quit [Read error: Connection reset by peer]
bit2017 has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 264 seconds]
nivah has quit [Ping timeout: 255 seconds]
orik has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
nwilcox has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
darmou has joined #bitcoin-wizards
kgk has joined #bitcoin-wizards
ll_ has quit [Ping timeout: 246 seconds]
<tromp>
i thought that was about Ethereum?!
Kireji has joined #bitcoin-wizards
Quanttek has quit [Remote host closed the connection]
erasmospunk has joined #bitcoin-wizards
Quanttek has joined #bitcoin-wizards
<nsh>
i probably misread
CodeShark_ has joined #bitcoin-wizards
CodeShark_ has quit [Client Quit]
CodeShark_ has joined #bitcoin-wizards
CodeShark has quit [Ping timeout: 240 seconds]
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
roxtrongo has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
sharperguy has quit [Ping timeout: 276 seconds]
hazirafel has joined #bitcoin-wizards
AaronvanW has quit [Read error: Connection reset by peer]
matsjj has joined #bitcoin-wizards
Dizzle has quit [Ping timeout: 276 seconds]
<bramc>
Checking the channel logs is so annoying. We should be using slack instead (kidding! I'm kidding!)
matsjj has quit [Ping timeout: 252 seconds]
<zooko>
bramc: what's the best link for your proposed fee-selection algorithm?
<kanzure>
both slack and irc have tendency to have important stuff "fall out of view"; only my bookmarks remember the good parts :-/.