wumpus changed the topic of #bitcoin-wizards to: This channel is 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
n9270 has left #bitcoin-wizards [#bitcoin-wizards]
Zooko-phone has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
afk11 has quit [Ping timeout: 256 seconds]
rubensayshi has quit [Remote host closed the connection]
FranzKafka has joined #bitcoin-wizards
FranzKafka has quit [Max SendQ exceeded]
FranzKafka has joined #bitcoin-wizards
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 248 seconds]
harrow has quit [Ping timeout: 248 seconds]
afk11 has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
p15x has joined #bitcoin-wizards
p15x_ has quit [Ping timeout: 256 seconds]
cryptoreach has joined #bitcoin-wizards
cryptoreach is now known as reach4thelasers
c0rw1n is now known as c0rw|zZz
bendavenport has quit [Quit: bendavenport]
mrkent has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
shesek has quit [Ping timeout: 240 seconds]
sadoshi has quit [Remote host closed the connection]
sadoshi has joined #bitcoin-wizards
rusty has quit [Ping timeout: 256 seconds]
shen_noe has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
alewis_btc has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
shen_noe has quit [Quit: quitquitquit]
bramc has quit [Quit: This computer has gone to sleep]
Zooko-phone has quit [Ping timeout: 248 seconds]
shen_noe has joined #bitcoin-wizards
shen_noe has quit [Client Quit]
ruby32 has joined #bitcoin-wizards
ruby32 has quit [Client Quit]
jtimon has quit [Ping timeout: 246 seconds]
Dr-G has joined #bitcoin-wizards
Dr-G has joined #bitcoin-wizards
frankenmint has quit []
Tebbo has joined #bitcoin-wizards
Dr-G2 has quit [Ping timeout: 256 seconds]
dabura667 has quit [Quit: Connection closed for inactivity]
maaku has joined #bitcoin-wizards
maaku is now known as Guest22663
maaku_ has quit [Ping timeout: 264 seconds]
mrkent has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 265 seconds]
afk11 has quit [Ping timeout: 264 seconds]
<dgenr8>
<CodeShark> then perhaps we can cut down the number of global commitments even further
<dgenr8>
global commitments are not the problem. the merkle tree allows effectively unlimited commitments, all guaranteed directly by the full network proof of work
<dgenr8>
the problem, if there is one, is various parties who would like to keep up with all this activity, being able to do so
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 264 seconds]
afk11 has joined #bitcoin-wizards
afk11 has quit [Ping timeout: 252 seconds]
p15x has joined #bitcoin-wizards
p15x_ has quit [Ping timeout: 250 seconds]
TheSeven has quit [Ping timeout: 246 seconds]
tromp has joined #bitcoin-wizards
TheSeven has joined #bitcoin-wizards
afk11 has joined #bitcoin-wizards
tromp has quit [Ping timeout: 248 seconds]
harrow has joined #bitcoin-wizards
alewis_btc has quit [Quit: alewis_btc]
shesek has joined #bitcoin-wizards
bendavenport has joined #bitcoin-wizards
jlrubin has joined #bitcoin-wizards
<jlrubin>
Oops I realize I'd been asking about my more theoretical 2 phase commit idea oon -dev rather than here...
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
<jlrubin>
(sorry for the delay, meant to send back2back but got cut off. Chinese internet man...
<jlrubin>
)
<jlrubin>
I realize that there are definitely large flaws in such a change, but I'm curious because a phased commit structure might have some other uses that are interesting to cryptocurrency.
<amiller>
jlrubin, my first concern is you can include an invalid transaction or a txhash for which there is no corresponding preimage
<amiller>
jlrubin, if you never reveal those transactions, can't subsequent miners just keep building on your block and get stuck?
<jlrubin>
Yes
<jlrubin>
but then
<jlrubin>
they can just set a pointer below it
<jlrubin>
and it will never be considered valid
<jlrubin>
The block does not need full acceptance.
RH311ish has quit [Read error: Connection reset by peer]
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<amiller>
jlrubin, does the first step even accomplish anything
<amiller>
how about if instead of a pointer to a previous block, i just include the hash of a transaction to 'confirm' it
<amiller>
this doesn't seem to have much in common with two-phase-commit
<jlrubin>
formally would accomplish the same thing, but less efficient implementation
<jlrubin>
It does
<jlrubin>
Think of first write as a journaling phase
<jlrubin>
and you write a checksum of the data at that point. Then, you begin to write to disk by broadcasting the transactions for that header. '
<jlrubin>
On "crash" (or not enough network bandwidth compared to mining time, it leaves the disk in a consistent state
<jlrubin>
amilller: that's why I feel it is similar to 2 phase commit. Different from a typical "full abort" though
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 256 seconds]
ThomasV has joined #bitcoin-wizards
<amiller>
jlrubin, if a transaction isn't committed in the next block, can it be resubmitted again?
bblue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jlrubin>
yes/no
<jlrubin>
In theory it's still in mempool then
<jlrubin>
so the next miner will try to commit it
<jlrubin>
* include, not commit
<jgarzik>
amiller, it is the client's responsibility to resubmit until confirmation
<jgarzik>
amiller, of course, your network nodes will ignore that resubmit if they've already seen it
<jlrubin>
jgarzik:his comment is in reference to the gist I shared earler, not sure if you caught it
<jgarzik>
ah, didn't see that in scrollback, sorry
<jgarzik>
jlrubin, just read it - my comments appear to be applicable
<jlrubin>
amiller: in theo also, if it is in mempool then the miner should have comitted it so maybe it isn't there, and would need more broadcasting as per jgarziks comment
<jlrubin>
jgarzik: yep, they are, but I figured you missed it ;)
<amiller>
i'm still trying to figure out what having it 'precomitted' in a block accomplishes
<amiller>
it guarantees that *if accepted in the next block* that they'd be in a particular order
<jlrubin>
That's not the focus
<jlrubin>
the focus is to decouple mining from other bottlenecks
<gmaxwell>
jlrubin: I am unable to determine from this document what utility this scheme has. In particular the phrase "double spend" does not occure in it, so I cannot tell what-- if any-- role these scheme intends to play in the fundimental purpose of the blockchain.
<jlrubin>
gmaxwell: no fundamental role, but then again, neither do merkle trees either or script etc. This is inteneded to help better utilize network resources.
<gmaxwell>
jlrubin: better utilizae resource by potentially decreasing goodput? (sending block data which will subsiquently be ignored?)
<jlrubin>
Ah no
<jlrubin>
'well
<jlrubin>
yes; in that you would also need to broadcast bits and pieces of the merkle tree for proofs which reduces goodput
<gmaxwell>
I don't think thats necessary for what you're describing in fact.
<gmaxwell>
other than a single stroke for truncation.
<jlrubin>
but the transactions to 'the right' of the pointer are not broadcast
<jlrubin>
gmaxwell: it is necessary to make it a "streaming" proof
ThomasV has quit [Ping timeout: 256 seconds]
<gmaxwell>
jlrubin: consider, someone makes a 1MB block. then the next miner sets the pointer to 0 and moots the content of that block-- that was 1 MB sent without moving the system forward.
<gmaxwell>
(1MB to roughly every particiapant)
<jlrubin>
Sure; but that would suggest they didn't get that block actually
<jlrubin>
gmaxwell: I think I mention an incentive for nonzero pointer maybe being needed
alewis_btc has joined #bitcoin-wizards
<gmaxwell>
But everyone else may well have. And; it seems according to 'Antagonistic Pointer Selection' those transaction then can never be included? How do you know if you accidentally included a transaction which you just hadn't previously fetched?
<gmaxwell>
Well obviously non-zero wouldn't be sufficient, as one could just set it to 1.
<jlrubin>
gmaxwell: "previously fetched"?
<gmaxwell>
(but I'm trying to understand at a higher level what this is intending to accomplish)
<jlrubin>
Ah
<jlrubin>
let me jump back a bit then
<jlrubin>
Right now, mining is tightly coupled to resource allocation
<gmaxwell>
jlrubin: someone creates a 1MB block. You only recieve the first 500k. Then you create a block pointing halfway into it, and include a duplicate transaction with the latter 500k (seems quite likely).
<gmaxwell>
jlrubin: Expand on what you mean by "tightly coupled to resource allocation"
<jlrubin>
Yes that is the intent, however one of my hopes (and mentioned in the pointer allocation bit) is that a pointer "filter" could minimize this but I don't know a good masking pointer algorithm
<jlrubin>
A miner, when creating a block, has to gauge carefully if the network will be able to work with that block
<jlrubin>
ie, Disk, Network Bandwitch, CPU for Crypto
<gmaxwell>
jlrubin: I don't believe thats actually correct.
<jlrubin>
by changing it to something like what I am proposing, they always try to make it as-big-as-possible
<gmaxwell>
Today, using state of the art softwhere here is what the transmission of a block looks like:
p15x has joined #bitcoin-wizards
<jlrubin>
Sure, today miners perform this function by fixing the size to 1mb
<jlrubin>
this is with the idea that you would want blocks larger than 1mb
<jlrubin>
so it's a dynamic sizing idea
<jlrubin>
(but I'm interested to see the transmission stats)
<gmaxwell>
jlrubin: no, the 1MB constrain does not have anything to do with miners; it's enforced by all full nodes, which are not paid for their activities and need to keep up auditing the system to align the economic incentives of miners.
<jlrubin>
Yes, correct.
<gmaxwell>
So what actual block transmission with state of the art software looks like is this: I send you a list of few (e.g. 2) byte indexes into a an array of transactions that had been shared or rumored previously between us (over the lats hours), plus a small number of transactions that hadn't yet made it across. You reconstruct the block compute the hashroots. You do no signature validation, as it's
<gmaxwell>
all cached, except for the small amount of new transactions.
zooko has joined #bitcoin-wizards
<gmaxwell>
There is linearity there that can-- in theory, with fancier protocols-- be eliminated... but it's very small owing to the constant factors.
<jlrubin>
gotcha
<jlrubin>
I thought it wasn't yet amortized as such.
<jlrubin>
By reconstruct
<jlrubin>
you are refering to invertable bloom?
<jcorgan>
gmaxwell: is there a name i can google on for prior discussions of the concept you just described?
<jgarzik>
it is low hanging fruit to avoid sending transactions twice (once at initial broadcast, and second when it appears in a block). the metadata needed to reconstruct a block is quite small, even without IBLT.
<jgarzik>
larger blocks of course slow down sync'ing nodes which are not caught up
<jlrubin>
I thought it's about full nodes not hashpower ;)
<gmaxwell>
jlrubin: lets rewind what you said above.
<gmaxwell>
22:00 < jlrubin> A miner, when creating a block, has to gauge carefully if the network will be able to work with that block
Emcy has quit [Read error: Connection reset by peer]
<gmaxwell>
Miners don't care if some fraction full nodes fall behind-- they'll continue to produce the longest valid chain.
<jlrubin>
sure
<jlrubin>
but if they make a block too large to propagate
mjerr has joined #bitcoin-wizards
<gmaxwell>
And they don't need to suffer any of these latency mediated sizing concerns due to the use of efficient relay.
<gmaxwell>
jlrubin: there is no such thing. As I pointed out, the block does not propagate "in the raw", it can be transmitted efficiently.
<gmaxwell>
(and is, in practice, most of the time)
<jlrubin>
That's a best case though, in the worst case it is orthogonal
<jlrubin>
Perhaps that forcing for non-orthogonal is good for getting txns in
<gmaxwell>
Beyond that, to the extent that there is a loss related to propagation miners can eliminate that loss by pooling (which was what drove the development of the efficient relaying software; to reduce the incentive do to that)
<phantomcircuit>
jlrubin, the average case and the best case are very similar in practice
<gmaxwell>
jlrubin: Well, I'm trying to spare you from wasting your time on trying to optimize a toy case that doesn't even reflect reality today. :)
<jlrubin>
gmaxwell: appreciated
<gmaxwell>
I think you fundimentally misunderstand what the purpose of having a limited blocksize is, it isn't to arbritrate things between miners-- if miners wanted they could simply refuse to extend blocks they though were too big to handle, and through that mechnism enforce a defacto blocksize which is acceptable to at least half the hashpower (though that would be rather messy)
<gmaxwell>
Miners have substantial income which can be used to pay for resources to process transactions as well, or (unfortunately) can amortorize all validation and propagation costs to almost nothig (one shared system for the whole world) by pooling.
<jlrubin>
gmaxwell: I think there are differing schools of thoughts on that
<jlrubin>
gmaxwell: that's no good if only one validator
<gmaxwell>
On what in particular? at least the factual points I'm making are really not disputable.
<gmaxwell>
E.g. that combining into a single validator reduces the total validation costs to a small constant, and that it eliminates propagation related costs between miners.
<jlrubin>
gmaxwell: I think the two major schools are "scarcity of txns is good", "abundance of txns is good"
<gmaxwell>
It is highly undesirable, I agree.
<gmaxwell>
I have not expressed any opinion on that subject.
<gmaxwell>
(in this discussion)
<jlrubin>
I thought that's where you were leding to with "fundamental purpoe of limited blocksize"
<gmaxwell>
(and I don't see how it connects but if I were to express an opinion I don't see how it can be other than an abundance is great-- assuming all other things equal!)
sneak has quit [Ping timeout: 256 seconds]
<jlrubin>
Well
sneak has joined #bitcoin-wizards
<jlrubin>
From what I've heard, some people feel that scarcity of transactions is good otherwise miners won't be paid in the future
<gmaxwell>
jlrubin: No the primary purpose is to preserve a system that other parties will audit, which is essential to the assumption of honesty on the part of the anonymous self-selecting miners; secondarily avoiding keeping the costs which can be perfectly amortized via centeralization from dominating. There are orther arguments, but I think they're unrelated to this discussion right now.
sneak has quit [Changing host]
sneak has joined #bitcoin-wizards
<jlrubin>
Yes, so part of pointer selection, as mentioned in proposal, is also validation costs
<gmaxwell>
jlrubin: well I'm leaving long term questions aside. There is a long term issue about what pays for POW in the future, if all costs are going to verification ... POW is open loop and can adapt to zero; but ... I think thats an independant question from the rest.
<jlrubin>
agreed
<gmaxwell>
jlrubin: Almost no resource are spent on validation is performed at the time a block is broadcast, the costly parts have already been performed.
<jlrubin>
Well that's a artifact of current sizes
<rusty>
gmaxwell: that's more true with IBLT, where there's pressure to match the expected block contents.
<gmaxwell>
jlrubin: I am not following what you're thinking there.
<jlrubin>
Ie, if the number of tps a node gets goes up, overlap would be less likely and harder to enforce
<gmaxwell>
jlrubin: to be included in a block a transaction must be sent to the network. Doing so also primes the caches from the participating system, allowing them to take validation out of the cricial, highly latency sensitive path of block relay.
<jlrubin>
Ie, flood node A with X1, flood node b with set X2
<jlrubin>
will keep them orthogonal
<gmaxwell>
jlrubin: I don't know why you believe this, the requirement is one sided-- so for example you can delay including a block in your template until a second after you've recieved it, in order to ensure that it will have achieved comprehensive forwarding and validation.
<gmaxwell>
replace "including a block" with "including a transaction"
<jlrubin>
gotcha, was confused
<jlrubin>
I think that's fair
<jlrubin>
You can ping your other miners too
<jlrubin>
asking if they got that one/forwarding it
<jlrubin>
but the problem is
<jlrubin>
at a certain saturation point
<jlrubin>
you still cause a latency partition
<jlrubin>
ie, littles law. the ones coming out of the queue will be there for a while
<jlrubin>
so if one queue is [x1, x2] and the other [x2, x1] then you are likely to mine a block while orthogonal
tromp has joined #bitcoin-wizards
<jlrubin>
so I think the "real world case" while it can be used (ie, most pointers should be 100%), having a byzantine fallback is good IMO
<gmaxwell>
If you exceede the throughput capability of the other miners overall, then yes the system will backlog. Though at that level verification costs have become quite substantial and other problems dominate: Non-miners cannot afford to audit, reducing the incentive to conform to the protocol for miners among other issues, and miners can make significant cost reductions by centeralizing.
<gmaxwell>
jlrubin: perhaps, if it doesn't open new attacks (otherwise its an improvement in a case which should be rare or which the system would have already failed in; which might open a more pratical attack).
<jlrubin>
Miners could pool their peers for recommended pointer
<gmaxwell>
so going to my earlier question say block X sets the pointer at 50%. later X includes transactions that were in the latter 50% ... or perhaps block >X does? the proposal seems to prohibit this, which sounds bad, but also I don't see how this can be enforced efficiently without assuming hosts would have obtained the data in that latter half.
<jlrubin>
Ah
<jlrubin>
No it isn't forbididden
<jlrubin>
more noted that
<gmaxwell>
also given the above desynchronization between validation and blocks, I am not sure that a pointer in to a particular blocks tree is likely to meaningfully map to the validation work any participant has done.
<jlrubin>
A possible attack is lying about what you put in
<gmaxwell>
jlrubin: okay if it isn't forbidden, why isn't this a free mechenism to steal transaction fees?
<jlrubin>
but lying creates a proof of lying
<jlrubin>
which could be used to reject such blocks
tromp has quit [Ping timeout: 256 seconds]
<gmaxwell>
I am not following you now. Who is lying about what at what point?
<jlrubin>
A puts abcdefgh into a block
<jlrubin>
B commits ab, then says my new block is cdefxyz
<jlrubin>
The block could be treated as invalid because they could have selected cdef
<gmaxwell>
Right B did not fetch all of A's block and has no idea whats in it beyond ab. Both parties behaved honestly.
<jlrubin>
well no
<jlrubin>
they had cdef
<gmaxwell>
If it would be invalid in that case then B was obligated to fetch the whole thing all along.
<jlrubin>
so they were not honest
<jlrubin>
becsue they should have updated their pointer
<gmaxwell>
This would have required them to obtain the complete list of transactions from A, rather than a log() scale hashtree prefix proof.
<gmaxwell>
So now B must recieve O(N) IDs. There is no need to send tree fragments, since you can reconstruct the root hash from the full list. (the talk of hashtrees is why I assumed your scheme did not require transmitting the full list)
<jlrubin>
(I should note, proposal is far from complete, sections like this were more of an attempt to consider design space and weaknesses)
<jlrubin>
I think a better prevention of fee stealing is splitting the fee with the next miner
<gmaxwell>
jlrubin: it's not clear that any kind of fee sharing scheme is workable; old result. The problem is that participants can pay fees 'out of band' e.g. by just using a dedicated output or via other mechenisms, and this is actually widely done in bitcoin today: many large miners have tx processing deals.
<gmaxwell>
maybe in this case it would fly because those deals would just have to also split or otherwise partiicpants will set the pointer low.
<jlrubin>
yep
<jlrubin>
It can even be set such that there is no fee for mining a block
<jlrubin>
only for the pointer selection
<jlrubin>
replace mining a block with including txns
<gmaxwell>
okay, so next issue. So txn A goes in in block a, then in block B, pointer is tet to exclude A and instead the double spend A' is included. So in this case the first block does not provide protection against double spend. The second does, if it doesn't set too low a pointer. From the user's perspective; why not just have their transaction accepted in the second block when it was widely enough di
<gmaxwell>
stributed to be accepted, as it could have been doublespent until that point in any case?
<gmaxwell>
well if there is no fee for mining a block, why would I bother including any transactions at all? or rather, why not fill up all my lists with 'transactions' storing your banned pornography collection in the blockchain, which you're paying me on the side to do? :P
akrmn has quit [Ping timeout: 256 seconds]
<jlrubin>
hah!
<jlrubin>
So the game theory would work out such that
<jlrubin>
if you include no txns
<jlrubin>
no one would mine your block!
<jlrubin>
No reward
<jlrubin>
(I think sharing is better, but I think the curve can go to that point and work out)
<gmaxwell>
jlrubin: lets assume, for a second, that I have 50% hashpower. Now the actual nodes are going to follow whatever chain I'm on. So no reward elsewhere either! :)
<jlrubin>
Let's not pretend you have 50%
<gmaxwell>
this also applies if I have less
<jlrubin>
Tht would be the least of the problems ;)
<gmaxwell>
say I have 20%, someone extends me still has an advantage in being in the longest chain, so I could include transactions inversely proportional to my hashrate and still get in the chain.
<gmaxwell>
and with the rest of my capacity, include 0 fee transactions where I am paid under the table.
<jlrubin>
I think the meta-reason on why commit is more valuable than include is that for include you are saying one person knows this, on include you are saying the network knows this (more likely)
<gmaxwell>
(or at least very low fee) That would be an efficient strategy.
<jlrubin>
(for why fees could go to commit)
<gmaxwell>
Esp if the other data is not bitcoin transactions but some other data packed in.
<jlrubin>
gmaxwell: re your earlier question, this is an attempt to define a byzantine tolerant notion of "enough distribution'
<gmaxwell>
(e.g. it may not care if it ever gets the commitment pointer)
<jlrubin>
Yes; other data may not care
<gmaxwell>
jlrubin: so on that point, you only go finitely deep here. It's two party, and so I think your scheme is actually isomorphic to selection by the second miner, though not quite because you've reduced his degree of freedom slightly.
<jlrubin>
reduced whose?
<gmaxwell>
As I was saying before, from the users perspective he is not confirmed (protected from double spends) at all until a second block sets a pointer past him. So he might as well just wait to be in the second block to begin with (from his perspective). E.g. the first phase bought him nothing of value.
<jlrubin>
gmaxwell: I'm not sure on the exact mechanics, but I think the easy answer is don't put the ratio fixed, let the miner chose the amount of fee to give to the next miner
<jlrubin>
Well
<jlrubin>
same is true for 1 block now anyways
<jlrubin>
and, assuming a linear pointer (not a mask), then you get more confidence the earlier in the tree you re
<gmaxwell>
No, not quite, when someone decides to not accept a block they lose the advantage of its work and start at a very costly disadvantage against it.
<gmaxwell>
So to say there is an equivilence I believe you must at least linearly derate the work credited for the prior block when the pointer is moved back.
<gmaxwell>
(and probably worse than linear because fees are not homogenous)
<jlrubin>
Can you say that in other words
<jlrubin>
"lineraly derate the work credited"
<gmaxwell>
Sure. right now I am a miner and I can choose to extend block X or mine a fork at X'. If I choose to extend X I take all thats in it even if I'd like to censor some of it or take some of its fees. If I fork, I can censor at will and take fees at will.. BUT I start a whole block behind, the network has progress on me, and I am quite likely to be unsuccessful unless my hashrate is substantial co
<gmaxwell>
mpared to the network's.
<gmaxwell>
Now in your scheme as I understand it, I could set the backpointer to a low value and take some (or maybe all) of X's transactions and replace them with conflicts, or censor or maybe steal fees (however you work out fees, not clear, but regardless I can still censor) and yet I gain the consensus-success advantage of having built on X.
<jlrubin>
yes
<jlrubin>
near the end of the proposal
<jlrubin>
I discuss this a little
akrmn has joined #bitcoin-wizards
<gmaxwell>
So to make these cases equivilent I think that when I reduce the pointer when I build on X you must dededuct a proportion of X's weight. And if all fees were the same it would need to be at least linear to make that equivilent.
<jlrubin>
i guess not explicitly
<jlrubin>
but what I discuss with n-phase
<gmaxwell>
But fees are not all homogenous, and presumably the higehst fees are first, so the deduction has to be faster than linear to make it equal otherwise lower fee txn are not protected by inclusion in a block with higher ones.
<jlrubin>
would distribute the pointer selection more
<jlrubin>
such that one bad miner wouldn't spoil it
<gmaxwell>
I didn't read that part; though I do not understand how you'd address conflicts in such a scheme.
<jlrubin>
ie, imagine needing 3 commits
<gmaxwell>
E.g. X includes abcd X+1 confirms ab and includes c' d' efg (where ' denotes a conflicting alternative). then X+2 does what? he cannot confirm more of a without undoing the effect of B'c confirmation.
<jlrubin>
and you sect the middle size'
<jlrubin>
So you have the following properties needed (for 3 blocks)
<jlrubin>
No spends on a txn in the window
<jlrubin>
(ie, 6 block wait)
<gmaxwell>
(and so in that case I think poor user observing all this doesn't get his first resistance to double spends until the third block; and again he is asking why not dispense with all this and just put his transaction in the third block after its good and propagated :) )
<jlrubin>
Pointer can only monotonicly decrease
p15x_ has joined #bitcoin-wizards
<jlrubin>
Well so the point is a byzantine tolerant propogation proof
<gmaxwell>
jlrubin: well that gives more miners more ability to censor transactions they do not like.
<jlrubin>
So yes, give me one of those
<jlrubin>
and then just put it in the t-0th block ;)
<gmaxwell>
So you have increased tolerance for one kind of fault at the expnse of making it massively easier to obstruct.
<jlrubin>
Well so that's the poit of the "middle " size
p15x has quit [Ping timeout: 240 seconds]
<gmaxwell>
(which seems like a common tradeoff in threshold signatures; the ability to unilatterally cause action is always in tension with the ability to unilatterally block an action)
<gmaxwell>
jlrubin: I don't see how middle of several blocks meets your monotone critera.
<jlrubin>
Yeah I was just typing that
<jlrubin>
realized it violates
<jlrubin>
perhaps "not larger than the first commit"
<jlrubin>
double spends from the rejected pointer block could be ignored
<jlrubin>
(but that adds complexity.... not very elegant)
<gmaxwell>
right so in any case, this indeed creates a trade-off where it becomes cheaper to unilatterally block action, at the expense of transactions neeing to wait longer for confidence in their state to build.
<gmaxwell>
and I think we do already have this, in the aggreate. For example, imagine that every block had just one transaction. I think your scheme and bitcoin are identical in that case.
cryptoreach has joined #bitcoin-wizards
<jlrubin>
Correct, that is equivalent
<jlrubin>
minus the work argument you raised prior
<gmaxwell>
(Actually your scheme with N infinity and linear deduction penalities, and a bunch of other handwaving to ignore discontinuities)
<gmaxwell>
(and constant fees and so on)
shen_noe has joined #bitcoin-wizards
<gmaxwell>
jlrubin: I think most of us have considered the shared fate in blocks and the ability to unilaterally cause action to be critical censorhsip resistant properties in bitcoin. So I'm not sure that fixing them is desirable.
reach4thelasers has quit [Ping timeout: 246 seconds]
<jlrubin>
I think you are correct in that trade-off, and I agree that it is not desired
<gmaxwell>
(actually I'm working on some work that will make that property much stronger)
<jlrubin>
great :)
<jlrubin>
I have to run -- thank you for taking the time to go through this with me.
<jlrubin>
I still think that there may be something interesting which a multiple phase rule could be used for, and perhaps there are solutions to the censorship tradeoff.
<jlrubin>
Excited to hear about your new work -- any links for reading available?
<gmaxwell>
(As a parting thought-- consider my expample from the user perspective, and also consider the efficient relaying meaning that the blocks only have to be small enough to stay within a throuput bound (so long as we don't care about auditing or decenteralization). ... might want to think about how your scheme is superior to miners deciding how big the next block can be; rather than expostfacto decid
<gmaxwell>
ing how big the prior really was)
<gmaxwell>
jlrubin: not yet.
mjerr has quit [Ping timeout: 264 seconds]
<jlrubin>
Yeah, I have a draft sitting in my todo pile of an idea to force validation.
<jlrubin>
It's high overhead
<jlrubin>
but the general idea is
<jlrubin>
chaffing in bad transactions
<jlrubin>
and making the next miner include a filter for the wheat transactions
<jlrubin>
(I really like two phase if you couldn't tell ;) )
<jlrubin>
If the chaffe can be such that a miner has to check the whole block to know, it can put (hoepfully) sufficient pressure to validate fully
<jlrubin>
but maybe, you know, they will have learned the lesson this time
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Read error: Connection reset by peer]
<gmaxwell>
jlrubin: ah, well man of my own heart, I had suggested requiring miners commit to a both a good block and a bad block; in order to make fraud proofs that actually worked... but generally most people regard that kind of thing as crazy.
shen_noe has quit [Quit: quitquitquit]
Mably has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
Guest9223 has quit [Remote host closed the connection]
<jlrubin>
Ah, I see :)
<jlrubin>
The extreme is Peter Todd's "just mine the raw bytes, let the client decide what it means"
paveljanik has joined #bitcoin-wizards
rusty has quit [Ping timeout: 256 seconds]
CoinMuncher has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
Xh1pher has joined #bitcoin-wizards
Mably has quit [Ping timeout: 252 seconds]
drwin has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
FranzKafka has quit []
wallet42 has quit [Quit: Leaving.]
p15x has joined #bitcoin-wizards
drwin has quit []
p15x_ has quit [Ping timeout: 246 seconds]
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 264 seconds]
tromp has joined #bitcoin-wizards
zooko has quit [Remote host closed the connection]
zooko has joined #bitcoin-wizards
moa has quit [Ping timeout: 272 seconds]
tromp has quit [Ping timeout: 246 seconds]
bblue has joined #bitcoin-wizards
jae has joined #bitcoin-wizards
jae is now known as Guest1085
coryfields_ has quit [Ping timeout: 256 seconds]
drwin has joined #bitcoin-wizards
Guest1085 has quit [Ping timeout: 255 seconds]
<gmaxwell>
http://www.adelard.com/papers/i97_revh.pdf just goes to show that there is nothing interesting in computing that someone working on nuclear reactors hasn't thought of first.
drwin has quit [Read error: Connection reset by peer]
zooko has quit [Remote host closed the connection]
drwin has joined #bitcoin-wizards
<jcorgan>
heh, i was a nuclear reactor engineer once, before cherynobyl dropped the bottom out of the industry and i returned to CS. fewer laws of physics to obey :-)
<venzen>
jcorgan: and less fallout in case of the inevitable human error :)
stonecoldpat has joined #bitcoin-wizards
stonecoldpat has left #bitcoin-wizards [#bitcoin-wizards]
<venzen>
gmaxwell: any idea what year Bishop wrote that? can't find a date in the text... the refs are all pre-1995. He'd be delighted with moxiebox
<venzen>
well, moxie put to his design, right?
<gmaxwell>
venzen: looks like 97.
NewLiberty has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
jtimon has joined #bitcoin-wizards
bblue has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bendavenport has quit [Quit: bendavenport]
Guest22663 has quit [Ping timeout: 240 seconds]
stonecoldpat has joined #bitcoin-wizards
maaku has joined #bitcoin-wizards
maaku is now known as Guest25136
AaronvanW has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
espes__ has quit [Ping timeout: 256 seconds]
espes__ has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
OneFixt_ is now known as OneFixt
AaronvanW has quit [Remote host closed the connection]
ThomasV has joined #bitcoin-wizards
coryfields has joined #bitcoin-wizards
JackH has quit [Quit: Leaving]
c0rw|zZz is now known as c0rw1n
AaronvanW has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
p15x_ has quit [Ping timeout: 240 seconds]
dEBRUYNE has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
p15x has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
tromp has quit [Ping timeout: 264 seconds]
moa has joined #bitcoin-wizards
arubi_ has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
MrTratta has quit [Read error: Connection reset by peer]
Xh1pher has quit [Read error: Connection reset by peer]
Xh1pher has joined #bitcoin-wizards
drwin has quit [Read error: Connection reset by peer]
drwin has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
gsdgdfs has joined #bitcoin-wizards
Transisto2 has quit [Ping timeout: 246 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 248 seconds]
ThomasV has quit [Ping timeout: 264 seconds]
AaronvanW has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 255 seconds]
Tiraspol has joined #bitcoin-wizards
erasmospunk has joined #bitcoin-wizards
alewis_btc has quit [Quit: alewis_btc]
frankenmint has joined #bitcoin-wizards
Mably has quit [Ping timeout: 246 seconds]
<waxwing>
who puts their postal address in the title of their paper? :)
<waxwing>
good old days i guess
erasmospunk has quit [Quit: ttm]
cryptoreach is now known as reach4thelasers
Mably has joined #bitcoin-wizards
FranzKafka has joined #bitcoin-wizards
FranzKafka has quit [Max SendQ exceeded]
tromp has joined #bitcoin-wizards
FranzKafka has joined #bitcoin-wizards
FranzKafka has quit [Max SendQ exceeded]
FranzKafka has joined #bitcoin-wizards
priidu has quit [Ping timeout: 246 seconds]
davi has joined #bitcoin-wizards
tromp has quit [Remote host closed the connection]
prodatalab has joined #bitcoin-wizards
FranzKafka has quit []
Quanttek has joined #bitcoin-wizards
FranzKafka has joined #bitcoin-wizards
davi has quit [Ping timeout: 256 seconds]
davi has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 248 seconds]
airbreather has quit [Read error: Connection reset by peer]
airbreather has joined #bitcoin-wizards
davi has quit [Ping timeout: 246 seconds]
SDCDev has quit [Remote host closed the connection]
moa has quit [Quit: Leaving.]
SDCDev has joined #bitcoin-wizards
Xh1pher has quit [Read error: Connection reset by peer]
Xh1pher has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
frankenmint has quit []
GAit has joined #bitcoin-wizards
narwh4l has quit [Quit: leaving]
narwh4l has joined #bitcoin-wizards
p15x has joined #bitcoin-wizards
p15x_ has quit [Ping timeout: 265 seconds]
eudoxia has joined #bitcoin-wizards
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 264 seconds]
zwick has joined #bitcoin-wizards
alawson has quit [Remote host closed the connection]
Starduster has quit [Ping timeout: 256 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 256 seconds]
Giszmo has joined #bitcoin-wizards
MatrixBridge has quit [Read error: Connection reset by peer]
MatrixBridge has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 250 seconds]
DougieBot5000 has joined #bitcoin-wizards
p15x has joined #bitcoin-wizards
p15x_ has quit [Ping timeout: 264 seconds]
StephenM347 has joined #bitcoin-wizards
Starduster has joined #bitcoin-wizards
badmofo has quit [Quit: Leaving]
ThomasV has quit [Ping timeout: 265 seconds]
badmofo has joined #bitcoin-wizards
b_lumenkraft has joined #bitcoin-wizards
www has joined #bitcoin-wizards
www1 has quit [Ping timeout: 255 seconds]
agner has joined #bitcoin-wizards
dc17523be3 has quit [Ping timeout: 246 seconds]
dc17523be3 has joined #bitcoin-wizards
justanotheruser has quit [Ping timeout: 248 seconds]
agner has quit [Ping timeout: 250 seconds]
shesek has quit [Ping timeout: 246 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
Hunger- has quit [Quit: _._]
mjerr has joined #bitcoin-wizards
FranzKafka has quit []
Hunger- has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
Mably has quit [Quit: Page closed]
dc17523be3 has quit [Ping timeout: 264 seconds]
dc17523be3 has joined #bitcoin-wizards
spinza has quit [Ping timeout: 264 seconds]
dEBRUYNE has joined #bitcoin-wizards
jae_ has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
spinza has quit [Excess Flood]
spinza has joined #bitcoin-wizards
bendavenport has joined #bitcoin-wizards
www has quit [Ping timeout: 264 seconds]
binaryatrocity has joined #bitcoin-wizards
www has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Mably has quit [Ping timeout: 240 seconds]
Tiraspol has quit [Ping timeout: 252 seconds]
Tiraspol has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
zooko` has joined #bitcoin-wizards
mjerr has quit [Ping timeout: 256 seconds]
zooko` is now known as zooko
spinza has quit [Excess Flood]
<zooko>
#p
<zooko>
oops
<zooko>
#p
<zooko>
double oops
bblue has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
GAit has quit [Remote host closed the connection]
SDCDev has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
CoinMuncher has quit [Quit: Leaving.]
SDCDev has joined #bitcoin-wizards
priidu has quit [Ping timeout: 246 seconds]
p15x_ has joined #bitcoin-wizards
p15x has quit [Ping timeout: 248 seconds]
Starduster has quit [Ping timeout: 256 seconds]
tromp has quit [Ping timeout: 265 seconds]
Starduster has joined #bitcoin-wizards
alawson has joined #bitcoin-wizards
JackH has quit [Ping timeout: 252 seconds]
AnoAnon has joined #bitcoin-wizards
AnoAnon has quit [Read error: Connection reset by peer]
mrkent_ has joined #bitcoin-wizards
shen_noe has joined #bitcoin-wizards
jgarzik has quit [Quit: This computer has gone to sleep]
jae_ has quit [Remote host closed the connection]
Guest25136 is now known as maaku
<jcorgan>
still looking for an SPV wallet that does standard BIP32 HD key derivation, uses BIP39 mnemonic seeds, and allows import of xpubs. i would have thought the intersection of these four criteria would be large but apparently it is the null space.
gabridome has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
<afk11>
mycelium might, but you'd be stretched to find wallets supporting that unfortunately :/
<afk11>
could write your own?
<jcorgan>
i have some python command-line tools i've written that cover the BIP32 address generation and xpub import, but not the SPV or watching wallet/bloom filter/address scanning part
davi has joined #bitcoin-wizards
<jcorgan>
or BIP39
gabridome has quit [Remote host closed the connection]
zooko has quit [Ping timeout: 256 seconds]
<afk11>
I haven't seen a py implementation of bloom filtering :/ bitcore doesn't have it yet either
<jcorgan>
i want a wallet implementing those 4 requirements i can point over Tor to a trusted bitcoind hidden service
<afk11>
android wallet wouldn't take much hacking just to drop the wallet part, and tell you about tx's on the xpub. if transparent proxying (orbot) works with it, use the trusted peer setting
<afk11>
otherwise, look at stratum. it doesn't have bloom filtering though
eudoxia has joined #bitcoin-wizards
jae_ has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 256 seconds]
FranzKafka has joined #bitcoin-wizards
FranzKafka has quit [Max SendQ exceeded]
FranzKafka has joined #bitcoin-wizards
FranzKafka has quit [Client Quit]
justanotheruser has quit [Read error: Connection reset by peer]
justanot1eruser has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
davi has quit [Ping timeout: 246 seconds]
Dizzle has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
davi has joined #bitcoin-wizards
spinza has quit [Excess Flood]
ThomasV has quit [Ping timeout: 256 seconds]
spinza has joined #bitcoin-wizards
user7779078 has joined #bitcoin-wizards
www has quit [Ping timeout: 264 seconds]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Remote host closed the connection]
maaku has quit [Remote host closed the connection]
tromp has joined #bitcoin-wizards
maaku has joined #bitcoin-wizards
maaku is now known as Guest15047
p15x_ has quit [Ping timeout: 244 seconds]
b_lumenkraft has quit [Quit: b_lumenkraft]
tromp has quit [Ping timeout: 240 seconds]
Guest15047 is now known as maaku
maaku is now known as Guest15047
Guest15047 is now known as maaku
Madars has quit [Quit: reconnecting]
Madars has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 264 seconds]
JackH has joined #bitcoin-wizards
davi has quit [Ping timeout: 246 seconds]
hashtag has quit [Ping timeout: 255 seconds]
priidu has joined #bitcoin-wizards
www has joined #bitcoin-wizards
mrkent_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hashtag has joined #bitcoin-wizards
www has quit [Ping timeout: 256 seconds]
NewLiberty has quit [Ping timeout: 248 seconds]
Oizopower has joined #bitcoin-wizards
priidu has quit [Ping timeout: 252 seconds]
gabridome has joined #bitcoin-wizards
gabridome has quit [Remote host closed the connection]
* gmaxwell
eyes Guest8453 with tremendous suspicion
<gmaxwell>
Guest8453: how did you find this channel?
<Guest8453>
Sorry, I will leave
Guest8453 has left #bitcoin-wizards [#bitcoin-wizards]
<Tiraspol>
way to go gmaxwell
<Tiraspol>
you scared off another one
<gmaxwell>
Another troll? bully for me.
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 252 seconds]
chmod755 has joined #bitcoin-wizards
Quanttek has quit [Read error: Connection reset by peer]
eudoxia has quit [Quit: Leaving]
c-cex-yuriy has joined #bitcoin-wizards
gabridome has joined #bitcoin-wizards
Quanttek has joined #bitcoin-wizards
gabridome has quit [Ping timeout: 246 seconds]
paveljanik has quit [Quit: Leaving]
zwick has quit [Quit: WeeChat 1.2]
drwin has quit [Read error: Connection reset by peer]
drwin has joined #bitcoin-wizards
user7779078 has quit [Remote host closed the connection]
GAit has joined #bitcoin-wizards
user7779078 has joined #bitcoin-wizards
<dgenr8>
LN invites address reuse on a massive scale. Receipt address can no longer be used to identify an incoming payment. Will have to be part of HTLC, and a new protocol will be needed for your hub to share this data with you.
DougieBot5000 has quit [Quit: Leaving]
frankenmint has quit []
superobserver has quit [Quit: Leaving]
Mably has quit [Read error: Connection reset by peer]
shen_noe2 has joined #bitcoin-wizards
shen_noe has quit [Ping timeout: 244 seconds]
shen_noe2 has quit [Client Quit]
<nsh>
dgenr8, not sure i follow
NewLiberty has joined #bitcoin-wizards
<dgenr8>
as I understand it, everybody sends to the 2of2 multisig of your payment channel
jgarzik has joined #bitcoin-wizards
<phantomcircuit>
dgenr8, the hash preimage is also a payment id
<dgenr8>
your daily net settlement naturally contains no information about who actually paid you. so you need to get all this information another way. nothing too surprising I guess since you need totally new software to manage HTLC's anyway
jtimon has joined #bitcoin-wizards
<dgenr8>
i observe that the internet did not scale via ISP's aggregating incoming packets into a daily digest
Mably has joined #bitcoin-wizards
afk11 has quit [Ping timeout: 264 seconds]
tromp has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
ttttemp has quit [Remote host closed the connection]
<dgenr8>
... maybe it could have, if special protocol for working with your ISP to access the details of the probable digest in real time (and for handling all kinds of timeouts and error correction scenarios)
tromp has quit [Ping timeout: 246 seconds]
<dgenr8>
... and maybe it would have, if there were some reason that core routers could only handle 1KB in real packets, and the meta-protocol was all carrier pigeons
<phantomcircuit>
dgenr8, bitcoin is a flood network
<phantomcircuit>
lightning is point to point network
<jgarzik>
dgenr8, Many people did aggregate Usenet - a flood-fill network - into daily digests...
jae_ has quit [Remote host closed the connection]
<nsh>
<dgenr8> i observe that the internet did not scale via ISP's aggregating incoming packets into a daily digest # deserves some kind of analogy police award lol
<gmaxwell>
dgenr8: you've misunderstod lightning (again). There need be no address reuse at all.
<gmaxwell>
nsh: apparently dgenr8 doesn't use DNS
* nsh
smiles
<gmaxwell>
dgenr8: to do _any_ transfer with lightning requires a seperate protocol for communicating with the micropayment hub network.
StephenM347 has quit []
Dizzle has quit [Quit: Leaving...]
<dgenr8>
gmaxwell: how do 2 different senders send to my channel?
<jgarzik>
dgenr8, have you read Rusty's blog posts on Lightning?
<dgenr8>
yes
<jgarzik>
They are a great resource
<jgarzik>
good
<gmaxwell>
dgenr8: "your channel" ? You don't have just one channel, you have multiple, and any channel has two endpoints.
<gmaxwell>
dgenr8: read them again?
<dgenr8>
gmaxwell: not germaine to the question
<gmaxwell>
A basic understanding of the system is critical to having any discussion about it.
<dgenr8>
gmaxwell: clearly I don't have a different channel for every incoming payment, or the whole thing is a waste of time, space, money, bandwidth, and valuable human energy.
SubCreative has quit [Remote host closed the connection]
<gmaxwell>
A channel itself only is transacted directly on by its endpoints. Please, go reread the information, --- I've talked to a dozen random people at the bitcoin SF devs meetup who managed to get the idea without trouble, you're just missing an overall understanding.
<dgenr8>
gmaxwell: so, no answer to my simple question will be forthcoming?
<gmaxwell>
dgenr8: the answer is "by using the lightning network"
<gmaxwell>
which, is unsurprisingly, not useful to you.
eric has quit [Ping timeout: 252 seconds]
Quanttek has quit [Ping timeout: 264 seconds]
afdudley has quit [Ping timeout: 276 seconds]
alawson has quit [Ping timeout: 264 seconds]
prodatalab has quit [Remote host closed the connection]
afdudley has joined #bitcoin-wizards
alawson has joined #bitcoin-wizards
<dgenr8>
gmaxwell: i don't see why it's surprising to you that circular reasoning is not useful to me
<dgenr8>
gmaxwell: oh, you did say it was unsurprising. we agree on that then.
eric has joined #bitcoin-wizards
<gmaxwell>
dgenr8: responding basically requires explaining how the whole thing works, up from the very premise-- which it why I suggested you go reread that.
<gmaxwell>
Because you clearly misunderstood it completely if you believe that a third party makes a bitcoin transaction directly to your endpoint address in a channel.
prodatalab has joined #bitcoin-wizards
<dgenr8>
gmaxwell: paper clearly states that an HTLC contains R, and a bitcoin address.
<dgenr8>
hash(R) .. don't know what's come over me
moa has joined #bitcoin-wizards
gmaxwell has left #bitcoin-wizards [#bitcoin-wizards]
tromp has joined #bitcoin-wizards
tromp has quit [Client Quit]
tromp has joined #bitcoin-wizards
drwin has quit [Remote host closed the connection]
drwin has joined #bitcoin-wizards
shen_noe has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 246 seconds]
user7779078 has quit [Ping timeout: 256 seconds]
jae_ has joined #bitcoin-wizards
user7779078 has joined #bitcoin-wizards
drwin has quit [Remote host closed the connection]
drwin has joined #bitcoin-wizards
drwin has quit [Client Quit]
Xh1pher has quit [Read error: Connection reset by peer]