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
jtimon has quit [Ping timeout: 250 seconds]
Burrito has quit [Ping timeout: 244 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
fkhan has joined #bitcoin-wizards
fkhan has joined #bitcoin-wizards
fkhan has joined #bitcoin-wizards
bliljerk101 has quit [Quit: Leaving...]
rusty has joined #bitcoin-wizards
rusty has quit [Changing host]
rusty has joined #bitcoin-wizards
<rusty>
gmaxwell: regarding your "publish weaker blocks" idea for network compression; I'm considering the bootstrap problem. If you set the "weak block" threshold at 1/20th of the current diff target, it might be a long time before it's useful, especially if miners wait for other miners to jump first.
<rusty>
gmaxwell: wondering if there's a sane way for the network to agree on a target over time, even if it ratchets to 1/20th eventually.
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
<gmaxwell>
rusty: sure you just do what p2pool does, target a share rate. (or even a max of of a rate from time and a rate from orphans)
<rusty>
gmaxwell: am looking at p2pool source now...
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sparetire_ has quit [Quit: sparetire_]
jtimon has joined #bitcoin-wizards
<rusty>
gmaxwell: hmm, can't immediately see who sets the target for p2pool.
<jtimon>
runeks: you may want to take a look at https://github.com/haskoin/haskoin (from what I've heard, the main author learned a lot doing it and even found bugs in Bitcoin Core while doing so, but he himself doesn't recommed it as a safe implementation due to the potential for consensus fork bugs)
dEBRUYNE has joined #bitcoin-wizards
<rusty>
gmaxwell: perhaps it's enough to have a tolerance factor of 2. Each node accepts blocks 2x weaker than it would use itself. Then have some handwavy average over the last 100 real blocks and aim for 30 seconds per weak block.
<gmaxwell>
rusty: it starts off at something stupidly low and increases like bitcoin's difficulty does, until it gets to a 30s block.
<jtimon>
runeks: you may want to watch sipa's explanation on why "the implementation is the specification" and the reasons to separate libconsensus: https://youtu.be/l3O4nh79CUU?t=764
<rusty>
gmaxwell: sure, but there has to be consensus, otherwise you send me a block I consider too weak (and discard), and then you refer to it in your next block...
kmels has quit [Ping timeout: 256 seconds]
<gmaxwell>
rusty: indeed, it can be done without one, but I've not given it much thought.
<rusty>
gmaxwell: I think having a separate threshold for "I'll relay this" vs. "I'll refer to this" works to paper over consensus issues.
<gmaxwell>
rusty: e.g. accept ones that are half as good as the ones you've seen suggest it should be.
<gmaxwell>
but don't relay.
<gmaxwell>
right.
<rusty>
gmaxwell: no, relay, but don't use.
<gmaxwell>
Oh I see. right.
<rusty>
gmaxwell: thanks, I'm happy now. I think this is complementary to IBLT, but far simpler and may get us the bulk of the gains.
<rusty>
gmaxwell: it also seems to allow a new form of SPV mining, for better or worse?
<rusty>
gmaxwell: One concern: not sure that miners will be incentivized to broadcast weak blocks themselves.
metamarc has joined #bitcoin-wizards
agorist000 has joined #bitcoin-wizards
agorist000 has joined #bitcoin-wizards
metamarc has quit [Ping timeout: 265 seconds]
nessence has quit [Remote host closed the connection]
<jtimon>
rusty gmaxwell didn't followed the full conversation but it seems you are talking about some kind of enforced p2pool, am I correct?
<rusty>
jtimon: not quite, but gmaxwell suggested reusing the approach for block transmission. ie. "this block is just like <previous weak block> with following changes".
<rusty>
jtimon: reduces latency for block upload/download and is pretty simple.
<rusty>
jtimon: if you wanted to interpret the cb this could turn into p2pool, I think.
<jtimon>
I don't deeply know p2pool but what you are saying sounds just like the little I know about p2pool
bendavenport has quit [Quit: bendavenport]
<jtimon>
oh, I think I see the difference: they're sharing these partial blocks but they don't share the reward of the "full blocks" they find individually
<rusty>
jtimon: yeah, exactly. Though if they want to reward share that'd be up to them, right.
<jtimon>
ok, thanks, yeah I like this a lot, it completely lacks the "uniform mining policy" concerns I have about IBLT
<rusty>
jtimon: no, it has the same issue. If you're mining differently from everyone else, your blocks don't compress at all.
<rusty>
jtimon: and IBLT can be layered on these blocks like anything else, of course.
<jtimon>
but the inter-block synchronizations don't rely on common policy at all, one partial block can be completely different from the previous one and that's fine, no?
LeMiner2 has joined #bitcoin-wizards
LeMiner has quit [Ping timeout: 246 seconds]
jtimon has quit [Ping timeout: 265 seconds]
Guest25488 has quit [Changing host]
Guest25488 has joined #bitcoin-wizards
Guest25488 is now known as s1w
dEBRUYNE has quit [Ping timeout: 244 seconds]
Dr-G has quit [Disconnected by services]
Dr-G2 has joined #bitcoin-wizards
Starduster_ is now known as Starduster
jaekwon has joined #bitcoin-wizards
Aquentin has quit [Ping timeout: 246 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
jaekwon has quit [Ping timeout: 244 seconds]
frankenmint has quit [Remote host closed the connection]
jtimon has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
belcher has quit [Quit: Leaving]
<rusty>
jtimon: sure, but it takes more bandwidth to communicate a completely different block. Exactly like IBLT.
<jtimon>
but if partial block A and partial block B are completely different and final block C is a subset of A + B, we're fine, right?
<jtimon>
I don't know much about IBLT but I'm assuming that whatever is equivalent to those partial blocks...once one is A, the next cannot be B, but rather A + B
<jtimon>
I assume instead of partial blocks IBLT has "synchornization steps" or something of the short
<jtimon>
I mean, maybe even if I'm right it doesn't make much difference in practice
Aquentin has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 256 seconds]
<rusty>
jtimon: IBLT encodes against the mempool, so the closer a peer's mempool is to block, the smaller it can be. THis encodes against previous weak blocks, which is effectively encoding against the other miners' mempools, so same problem?
<jtimon>
I think I see the hidden assumption I'm making
<jtimon>
with IBLT I have an incentive to make my own mempool similar to other miner's mempools to make "sync steps" (do they have a name?) faster, right?
<jtimon>
rusty: but with quasi-p2pool (does it have a name?) that's not necessarily true
<jtimon>
I could have my own mempool with my own eccentric policy and an auxMempool with transactions I've seen from other miners that I don't want to include in my own block for whatever reason
<jtimon>
maybe IBLT can somehow use 2 mempools as well and then all my "uniform policy" concerns are gone as well
<jtimon>
rusty: does that make sense?
<rusty>
jtimon: ok, if you're "weird-mining", weak blocks is worse for you. When you send out your block, you need to full-encode any txs which haven't been seen in a weak block, right?
<rusty>
jtimon: with IBLT (at least, as I proposed it), it's slightly better if it's in others' mempool, because the encoding is more complex.
<jtimon>
yes, but if I've created a weak block with my "weird mining policy" then all the other miners have seen my transactions (or a subset of it) when I relay my full block
<rusty>
jtimon: first, it says "here's the lower fee-per-byte" threshold. Then it says "but here are the txs which I included despite being below that". That last one is encoded compactly, as ~log2(num-txs-in-mempool) bits.
<rusty>
jtimon: only if you made a weak block, say 5% of hash power.
<jtimon>
5% or just luck
<rusty>
jtimon: yeah :)
<rusty>
jtimon: but even with 5%, it's probably only got 1/2 the transactions in it you do now.
<jtimon>
but there's also transactions above the fee threshold that I don't want to include, by not including them in my own mempool I'm being penalized in each IBLT sync step
<rusty>
jtimon: oh, sorry, there's also "here's the ones which are over tx threshold, which *aren't* in"
<rusty>
(same encoding style)
<jtimon>
ok, the difficulty target is to produce 1 weak block per 30 seconds, right? (that's where the 5% comes from? [30 seconds = 30% of 10 minutes)
<rusty>
jtimon: yeah, p2pool uses 30 seconds, it seems reasonable as a first guess.
<jtimon>
ok, so in your current IBLT design there's actually 2 mempools: one for synchronizing and the one that I'm going to actually use to produce my own block, correct?
<jtimon>
sorry, 30 seconds = 5% of 10 minutes
<rusty>
jtimon: my simulator only has one mempool, but you're right; there's no real reason for them to be the same.
<rusty>
jtimon: doublespends are the obvious candidate for the second mempool.
<rusty>
jtimon: but any miner doing tx filtering would want them to go into the second mempool, too.
<jtimon>
not just double-spends, anything that other miners want my I don't
<jtimon>
s/my/but
<rusty>
jtimon: yeah...
<jtimon>
ok, and you sync both with the other miners, cool
<jtimon>
if you do that separation all my "uniform policy" concerns are gone
<jtimon>
mhmm, an attack comes to mind...what if I'm not even a miner but I pretend to be so that other miners have to IBLT sync transactions that nobody else wants?
<jtimon>
note that it doesn't apply to quasi-p2pool (seriously let's name this) because you can't prodce weak blocks without hashpower
p15 has joined #bitcoin-wizards
<rusty>
jtimon: IBLT is only between peers, it gets re-encoded if necessary. That's OK, because it's fast.
<rusty>
jtimon: you doing a running guestimate on how similar your mempool is to the peer, and set the IBLT size based on that (plus some margin).
<rusty>
jtimon: the IBLT basically gives you a redundant encoding if there are a few missing/extra txs basically. But it only seems about 45% efficient, so you don't want too many...
<rusty>
* 45% result very very preliminary, take as a ballpark!
<jtimon>
ok, then if an incentive for a uniform mempool is unavoidable with IBLT, I defintely prefer quasi-p2pool over IBLT
<rusty>
jtimon: I prefer quasi-p2pool because it has additional side effects, like 0 conf implications and SPV fee estimation (with block order changes), and it's easier to implement :)
<jtimon>
yeah, it's also easier to estimate double-spend risks with that. I remember someone asking about estimating double-spend risks and me answering something along the lines: "p2pool blocks can be an interesting source for data, it would be better if p2pool was somehow enforced among the centralized pools and solo miners"
<jtimon>
but I was wondering if using a mempoolView = myMempool + otherMinersMempool in IBLT could solve my uniform policy concerns (it seems it can't from what you said earlier)
ShannonCode has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
p15 has quit [Ping timeout: 250 seconds]
NLNico has joined #bitcoin-wizards
<rusty>
jtimon: there are several kinds of uniform policy concerns, right?
<rusty>
jtimon: if you (a miner) include a tx nobody else has, any encoding will hurt you.
p15 has joined #bitcoin-wizards
<jtimon>
yep, with both approaches
<rusty>
jtimon: if you only include txs which are in mempools, but most not in others blocks (eg, larger priority area than normal, or spam filtering) then weak-blocks hurts you badly, and iblt only hurts you very very marginally (eg. 6000 txs from a 1M tx mempool => 15k)
<jtimon>
but if you don't want to include txs that everyone else want to include IBLT penalizes you but quasi-p2pool doesn't
p15_ has quit [Ping timeout: 250 seconds]
<rusty>
jtimon: only if you use a strict subset: if you don't include some of those txs and that leaves room to include others....
<rusty>
jtimon: then see above...
<rusty>
jtimon: if you only include a subset, quasi-p2pool is great, and iblt costs you *20 bits* per tx you don't include. Say, worse case, 15k.
<rusty>
jtimon: I really tried hard to get the non-uniformity penalty for IBLT down low, and I think I've achieved it to the point that it's noise.
<rusty>
jtimon: (Side node: I'm assuming that we eventually have a canonical block ordering, which makes encoding for both IBLT and quasi-p2pool cheaper).
<jtimon>
it's not a subset not a superset: there will be transactions that I only want to include and txs that everybody wants to include but I don't
<jtimon>
we have 2 cases here:
<jtimon>
1) transactions that I only want to include
<jtimon>
2) txs that everybody wants to include but I don't
<jtimon>
1) seems bad for both quasi-p2pool and IBLT
<jtimon>
2) is far worse for IBLT than for quasi-p2pool
<jtimon>
did I get it right?
<rusty>
3) some txs I don't want to include, some I want to add.
<rusty>
and it's not "far" worse.... the cost is log2(txs-in-mempool) * txs-you-want-to-exclude.
<rusty>
(3) is what I'd expect if blocks are full.
<jtimon>
I don't undesrtand 3
<rusty>
jtimon: say mempool is overflowing. You don't take some txs, so now you can fit others?
<rusty>
jtimon: s/mempool/blocks/
<jtimon>
yes, that's still 1, no?
<rusty>
It's 1 *and* 2.
<jtimon>
??
<jtimon>
let's replace you and me with miner A and B, please
<rusty>
OK :)
TheSeven has quit [Disconnected by services]
<jtimon>
tx1 would be included by miner A but it doesn't fit, since B exlcluded other txs, tx1 fits in miner B block
[7] has joined #bitcoin-wizards
<jtimon>
let's say miner A follows the majoritary policy
<jtimon>
then tx1 is just case 1 for miner B
<jtimon>
what am I missing?
<rusty>
jtimon: Yep. Cost for Qp2POOL == sizeof(tx1). Cost for IBLT ~= 20 *bits*.
<rusty>
jtimon: case 2. Cost for QP == 0 (you just don't include it). Cost for IBLT ~= 20 bits.
<jtimon>
ok, so case 1 for B is worse with qp2pool than for IBLT, but case 2 for B is worse for IBLT than for qp2pool
<rusty>
jtimon: yeah... but 1 is much worse, 2 is marginal.
<jtimon>
I think I get it
<rusty>
jtimon: of course, this is assuming that for IBLT you do the "two mempools" thing. Which I think is sensible.
<rusty>
jtimon: ... but it's not entirely trivial to code this up.
<jtimon>
ok, that makes sense, these conclusions were surprising without the 2 mempool thing
<jtimon>
well, I was much more worried about the policy uniformity than about code complexity, it seems the 2 mempool thing solves my concerns after all
<jtimon>
also, you're the one coding IBLT, it is you who eat the complexity costs, not me, not worried at all ;)
<jtimon>
</bad joke>
<jtimon>
gavinandresen: my "uniform policy" concerns about IBLT are gone, see above
zooko has quit [Remote host closed the connection]
p15 has quit [Ping timeout: 264 seconds]
priidu has joined #bitcoin-wizards
p15 has joined #bitcoin-wizards
spinza has quit [Excess Flood]
Transisto2 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
p15 has quit [Ping timeout: 246 seconds]
elastoma has quit [Ping timeout: 260 seconds]
snthsnth has quit [Ping timeout: 246 seconds]
p15_ has quit [Ping timeout: 265 seconds]
p15 has joined #bitcoin-wizards
snthsnth has joined #bitcoin-wizards
priidu has quit [Ping timeout: 240 seconds]
gsdgdfs has joined #bitcoin-wizards
p15 has quit [Ping timeout: 250 seconds]
Transisto2 has quit [Ping timeout: 256 seconds]
gsdgdfs has quit [Ping timeout: 252 seconds]
p15 has joined #bitcoin-wizards
Transisto2 has joined #bitcoin-wizards
p15_ has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 246 seconds]
jgarzik has quit [Quit: Leaving]
p15 has quit [Ping timeout: 240 seconds]
Transisto2 has quit [Ping timeout: 240 seconds]
Transisto2 has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
CodeShark has quit [Ping timeout: 272 seconds]
Aquentin has quit [Ping timeout: 260 seconds]
snthsnth has quit [Ping timeout: 265 seconds]
ThomasV has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
NLNico has quit [Quit: Leaving]
snthsnth has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
kang_ has joined #bitcoin-wizards
<kang_>
Bitcoin can be scaled by changing the behavior of wallets towards deferred transactions using DKG threshold crypto
<kang_>
If we have an unbroadcasted transaction paying A to B, and A's private key becomes unusable thereafter, then without relaying the transaction, B has the power to show it can claim the coins at address A by relaying this transaction.
<kang_>
Anyone willing to hear it out?
elastoma has joined #bitcoin-wizards
deego has joined #bitcoin-wizards
Aquentin has joined #bitcoin-wizards
<gmaxwell>
kang_: sounds like you're going to reinvent duplex payment channels.
<gmaxwell>
(but sure, go through it!)
<kang_>
Ah, let me read on duplex payment channels first then.
robbak has joined #bitcoin-wizards
rusty has quit [Ping timeout: 244 seconds]
rusty has joined #bitcoin-wizards
<jtimon>
kang_: do you have a link to read about "DKG threshold crypto"
snthsnth has quit [Read error: Connection reset by peer]
<btcdrak>
completely randomly based on the fact Chinese miners have expressed extreme consternation against anything more than 8MB. I have no strong opinions, but I propose a limit so it can become a talking point to keep, alter or remove.
<btcdrak>
similarly increasing immediately to 2MB is chose as a peace pipe. It is also not essential to the proposal.
<gmaxwell>
I'd drop the immediate increase, I think thats an olive branch that doesn't help. The updates may be two frequent because they don't allow for planning thats tricky.
<gmaxwell>
The issue is that in business I would always have to provision assuming that it could become the maximum very quickly at any time (unless I retain enough hashpower to personally stop it)
jtimon has quit [Ping timeout: 252 seconds]
<gmaxwell>
in your scheme you need to make the block invalid if it fails. Otherwise I can always _try_ to vote for a huge increase at no cost to myself.
<warren>
btcdrak: "Chinese miners have expressed extreme consternation against anything more than 8MB." ..... URL?
<gwillen>
gmaxwell: the 2MB initial seems harmless enough; do you really think it would not be a useful peace offering?
<c0rw1n>
is there anything technical that makes it really really hard to up the limit to like 4 megs ?
<gmaxwell>
My comment was basically that no one would find it a useful peace offering. I agree it's not so harmful (though perhaps more than you're thinking as it forstalls any fee market further, perhaps by years-- which makes running into a limit more scary and dangerous as time goes on)
<kanzure>
when you mention fee markets i have generally assumed that you are talking about "making sure that things like fee estimation are actually happening" in terms of more local timespans and things like "paying for decentralized security" for longer timespans. but this might be a poor interpretation.
<btcdrak>
warren: multiple sources, I would need to go digging. It was expressed on the mailing list a few times and hinted at again today by Yifu. Maybe I am embellishing a little, but they certainly were not happy about going over 8MB. Remember the discussions with f2pool's wangchen on the list?
kmels has quit [Ping timeout: 244 seconds]
wyrag has joined #bitcoin-wizards
<btcdrak>
gmaxwell: Yes, I thought the block failing was implicit in my text. I will clarify.
<btcdrak>
gmaxwell: do you think a larger window than 2016 blocks?
<gmaxwell>
I don't know that if its tidly solvable.
<gwillen>
gmaxwell: I can't read the minds of gavin/mike/redditors but my intuition is that at least some people will be more pacified by an immediate bump even if it has no long-term consequence
<btcdrak>
kanzure: Maybe I need to elaborate, I am referring to healthy competition for blockspace that will promote transaction fees necessary to replace blocksubsidy over time.
<gwillen>
(and then at least that's one less thing people can tar the proposal with)
snthsnth_ has quit [Ping timeout: 244 seconds]
<gmaxwell>
gwillen: hm. that doesn't exactly comfort me (e.g. would they be immediately appeased because they believe that they can later argue that we're commited to make further bumps as jeff has? --- like how US has copyright with limited terms)
<gwillen>
I think it's more emotional than that
<gwillen>
plus, at least with the Reddit crowd and other ill-informed sorts, "Bigger blocks now" is what they're looking for, without thinking too hard about complex proposals
<btcdrak>
gmaxwell: I dont think I am sufficiently qualified to make a technical judgement there, but my reading politically is the community wants to see some kind of commitment to extending size. I'm perfectly happy not to include an initial bump because once the hard fork took place, miners could take control of matters according to the algo.
<gmaxwell>
btcdrak: well they can't because you also put the floor at 2mb.
snthsnth has joined #bitcoin-wizards
<btcdrak>
It's a very rough idea, I just wanted to float it as a rough idea and see if it can be polished. the floor is means to be a maxsize = 2mb. If you feel suffiently strong about it I can remove the limits entirely.
<gmaxwell>
so imagine, (I agree this is not the most likely case) that demand doesn't go above the current 500k level. This means miners will lack an in protocol mechenism to coordinate a lower size that results in fee pressure, and instead leaves the situation where a single miner can clear the market every time they find a block. :(
<btcdrak>
you are right, I'll remove it. it's an unncessary talking point over the main concept of the proposal.
<gmaxwell>
I wish hashtree membership proofs weren't so large with respect to N for small N.
<kanzure>
ooh clearing the market is a neat side effect
<kanzure>
or, direct effect
<gmaxwell>
btcdrak: if you find a push that suggests adding it back, don't hesitate due ot me.
<gmaxwell>
I wish hashtree membership proofs weren't so large with respect to N for small N. Otherwise I'd love to have a proposal where miners commit to hashtress of the transactions they know, and then the winning block hash proportioanl selects a subset of the limited transactions in a fee weighted way, to become official.
ASTP001 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<btcdrak>
gmaxwell: what about the upper limit, should I get rid of that too?
kang_ has joined #bitcoin-wizards
<gmaxwell>
there needs to be a software engineering target, otherwise that issue of having to privison for the worst case becomes intractable.
<gmaxwell>
at 10%/2016 you can get into sizes that will overflow your integer types faster than many users upgrade software.
snthsnth has quit [Ping timeout: 244 seconds]
<btcdrak>
again 10% was just a random starting point to get things going. I am sure there is a scientific way to reach an ideal number.
snthsnth has joined #bitcoin-wizards
adam3us has quit [Quit: Leaving.]
adam3us has joined #bitcoin-wizards
adam3us has quit [Client Quit]
jtimon has joined #bitcoin-wizards
<gmaxwell>
oh proportional right.
<gmaxwell>
So proportional has a problem that even with isotropic fees, it's never a win to increase the size.
<gmaxwell>
If you go work through the algebra you'll see that the decreae in chance of finding a block offsets the increased transaction count you can include.
<gmaxwell>
Thats why my proposal suggestion was quadratic.
trippysalmon has quit [Read error: Connection timed out]
trippysalmon has joined #bitcoin-wizards
zooko has quit [Ping timeout: 272 seconds]
ASTP001 has joined #bitcoin-wizards
<tromp_>
btcdrak: isn't the cost to vote toward +10% negligible?
<btcdrak>
there is no cost to vote down.
ThomasV has quit [Ping timeout: 240 seconds]
<tromp_>
roughly 90% of all blocks beat the difficulty target by at least 10%
<tromp_>
that's a lot of free upvotes
<tromp_>
potential upvotes to be precise
AlphaTech has joined #bitcoin-wizards
drwin_ has quit []
afk11 has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
zooko has joined #bitcoin-wizards
c-cex-yuriy has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
agorist000 is now known as metamarc
p15 has joined #bitcoin-wizards
p15_ has quit [Ping timeout: 256 seconds]
jtimon has quit [Ping timeout: 265 seconds]
<btcdrak>
tromp_ what if we base the penalty as a percentage above a moving average of the last 144 blocks or whatever.
ASTP001 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<tromp_>
then even if a miner likes to go +10%, i doubt she'lll refrain from publishing her solved blocks that are sub-avg difficulty.
ASTP001 has joined #bitcoin-wizards
gill3s has joined #bitcoin-wizards
<tromp_>
you can simplify your scheme to just 3 votes, -10%, 0, +10%
<tromp_>
you can tweak your def. so that the +10% vote is only possible for some X% of blocks
<tromp_>
but setting X=30 for instance is similar to allowing votes for -3%,0,+3% with no restriction on votes
c0rw1n_ has joined #bitcoin-wizards
<tromp_>
so your voting restriction looks like a unneccesary diversion
<kanzure>
table 1 is neat
c0rw1n has quit [Read error: Connection reset by peer]
c0rw1n_ is now known as c0rw1n
ASTP001 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
damethos has quit [Quit: Bye]
damethos has joined #bitcoin-wizards
ASTP001 has joined #bitcoin-wizards
StephenM347 has quit []
ThomasV has joined #bitcoin-wizards
user7779078 has joined #bitcoin-wizards
ASTP001 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nwilcox has joined #bitcoin-wizards
slyf0x has quit [Quit: Leaving]
user7779_ has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
user7779078 has quit [Ping timeout: 245 seconds]
ASTP001 has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
rodarmor has quit [Quit: leaving]
agorist000 has joined #bitcoin-wizards
metamarc has quit [Ping timeout: 255 seconds]
ThomasV has quit [Ping timeout: 264 seconds]
Guyver2 has quit [Quit: :)]
AnoAnon has joined #bitcoin-wizards
AnoAnon has quit [Read error: Connection reset by peer]
bendavenport has quit [Quit: bendavenport]
afk11 has quit [Ping timeout: 264 seconds]
ASTP001 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
adam3us has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
damethos has quit [Quit: Bye]
rivito has joined #bitcoin-wizards
Burrito has quit [Remote host closed the connection]
K1773R has quit [Ping timeout: 246 seconds]
Burrito has joined #bitcoin-wizards
nwilcox has quit [Quit: leaving]
K1773R has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
<Taek>
fwiw I'm also against an immediate increase to 2mb. At 500k blocks there is a lot of headroom for growth, and as we've seen infrastructure for dealing with a fee market won't be put in place until people are suffering for the lack of it
<Taek>
similarly I'm against any sort of large 'jump' in the blocksize, as that would completely remove all fee pressure and give an unrealistic impression of how necessary fee-market infrastructure is
<Taek>
if the block size is to have some way to increase, it should be in numerous small steps
<Taek>
<tromp_> roughly 90% of all blocks beat the difficulty target by at least 10%
<Taek>
<tromp_> that's a lot of free upvotes
<Taek>
my understanding is that you need to commit to the increased target before mining
<Taek>
which means you are definitely giving up a portion of your expected revenue
<Taek>
no free votes there
<tromp_>
miners are not gonna do that:)
<Taek>
" ensures the mining community will collude to increase it only when there is a clear necessity"
<tromp_>
also, there is no way i can see to make such a commitment
<Taek>
you'd have to add a flag/field somewhere, probably in a txn
<tromp_>
that's one hardfork just to enable voting on another hardfork. never gonna happen
Mattie^ has joined #bitcoin-wizards
<Taek>
at that time, the voting is a part of the protocol as much as the difficulty change is, it's no longer a hardfork to increase the size by then
<Taek>
it's just 1 hardfork to add the new rules (correct me if I've misunderstood)
<tromp_>
oh, the vote commit can be a soft-fork
<tromp_>
but then instead of commit to increased difficulty, it would be simpler to vote by burning part of block reward?!
zooko has quit [Ping timeout: 244 seconds]
<tromp_>
if you want votes to have a real cost
<Taek>
one thing that is bothering me about this proposal is that volume of txns and fees doesn't relate in any way to the strength of the infrastructure
<Taek>
if Bitcoin can only safely tolerate 3mb blocks, $40 txn fees aren't going to change that
<kanzure>
but who argued that it would change it?
<kanzure>
or not who, but which argument
<phantomcircuit>
Taek, there seems to be a huge amount of confusion around how fees work in relation to full nodes
<Taek>
phantomcircut: confusion on my part, or in general?
<phantomcircuit>
in general
<phantomcircuit>
i've talked with a number of people who seemed to genuinely believe fees went to node operators
kmels has quit [Ping timeout: 250 seconds]
<kanzure>
perhaps they thought that only miners ran nodes (and that miners ran nodes at all)
<phantomcircuit>
possibly
<phantomcircuit>
either way the entire discussion is tainted by the widespread misunderstanding of fees
<kanzure>
i am still trying to parse the argument that taek is trying to reply to
<kanzure>
it would seem to be something like "high transaction fees indicate that the block size can be safely increased" but i don't think anyone has argued this
<kanzure>
or rather, i haven't seen that argument (trying to not point fingers etc)
<Taek>
kanzure: my understanding was that the proposal by btcdrak was to give a method for increasing the block size limit - which to me had an implicit argument that the limit should be based on the fee volume
<phantomcircuit>
<tromp_> also, there is no way i can see to make such a commitment
<phantomcircuit>
it's actually very easy to implement as a hardfork
<phantomcircuit>
the flexcap proposal requires a hard fork to allow larger blocks anyways
<phantomcircuit>
so that doesn't much matter
<kanzure>
Taek: ah thanks
<phantomcircuit>
you can also implement the entire thing as a soft fork with extension blocks
<phantomcircuit>
out of all the proposals i believe extension blocks and/or flex cap are the only ones that actually make any sense
<kanzure>
i have lost track- which is saying a lot. i think i have seen >50 proposals at this point.
<phantomcircuit>
Taek, ah yes, that's very true
<phantomcircuit>
fundamentally the issue is that the constraint on the blocksize limit is not something that can be reasonably derived from anything in the system
<phantomcircuit>
it's the cost per compute time
<kanzure>
i think i saw a flexcap and fee penalty or fee redistribution or reward redistribution proposal that didn't get completely demolished immediately
bedeho_ has quit [Ping timeout: 240 seconds]
<kanzure>
phantomcircuit: go on
<phantomcircuit>
kanzure, that's it really
bedeho has quit [Ping timeout: 260 seconds]
<Taek>
the block size limit is necessary because of network constraints, and (assuming network constraints disappear) computing constraints
<phantomcircuit>
the only way to track cost of compute time is to do a bunch of hard forks to change the limit as people agree the cost has gone down
<Taek>
*node computing, not mining
<kanzure>
"use an even lower max block size" could work for a goal like "keep this value as low as possible" as sort of a systemic axiom, but then you have to figure out why more than 1 byte or 100 kb
<phantomcircuit>
which is super lame
<phantomcircuit>
and almost certainly not a good plan
<phantomcircuit>
fees give us a proxy for demand, but there is no proxy for what a reasonable supply size is
<phantomcircuit>
and either way
<kanzure>
someone was saying "i suspect the demand for blockchain capacity is practically infinite" and yes i would love to dump a few billion transactions into the blockchain per day thanks for asking
<Taek>
I am okay with using limited projections. IE: we assume that network bandwidth will grow by 17% annually for at least 5 more years
<phantomcircuit>
anything more than linear growth in block size will cause a growth in the total time to validate which exceeds moores law significantly
<phantomcircuit>
bandwidth is a great example of this
nessence has joined #bitcoin-wizards
<phantomcircuit>
if bandwidth is growing 17% annually then the total size of the blockchain should not grow more than 17% annually
<phantomcircuit>
so the blocksize should be limited to 148kB
wyrag has quit [Read error: Connection reset by peer]
null_radix has quit [Excess Flood]
null_radix has joined #bitcoin-wizards
DougieBot5000 has joined #bitcoin-wizards
<Taek>
phantomcircut: where does 46GB come from?
<Taek>
I don't know if it's been brought up recently, but I would be in favor of a soft-fork that eliminates the need for IBD for all blocks before height X
<Taek>
for example, 250,000
<Taek>
there would be an explicit utxo-set that you start with, and then you could never reorg beyond 250,000 blocks
<Taek>
it's not subjective because 250,000 is a set number
<TD-Linux>
Taek, 46GB is the total size of the blockchain currently
<belcher>
is there a central page with all the anti-bitcoinxt arguments
<belcher>
could be useful for linking, if not it may be worth creating one on the bitcoin wiki?
<Taek>
belcher: I don't think so. Such a page would probably be seen as highly antagonistic and may not be beneficial to the politics of the situation
<belcher>
naturally it would be antagonistic, but with all the misunderstandings floating around it might still be useful
<belcher>
iv genuinly seen people on reddit who were not aware it was a matter of tradeoffs, and who were interested in learning more about the other side
<kanzure>
"yes i wouldn't want to intrude on the rhetoric or anything"
<Taek>
if you want people to listen to you, you have to convince them that you think they are intelligent and that you respect their existing opinions
<belcher>
ty
nwilcox has joined #bitcoin-wizards
<warren>
Hi, https://scalingbitcoin.org/montreal2015/ is trying to schedule the second workshop in Hong Kong around December 2015. This is the event where actual block size proposals are to be presented and discussed.
<warren>
One possible date proposed is December 6th-7th or Dec 13-14th... both of which conflict with Hanukkah. I am not too familiar with Jewish holidays. Does anyone know if this would make it difficult for Jewish researchers to attend the event?