pablomartin4btc has quit [Ping timeout: 252 seconds]
mcey_ has joined #bitcoin-core-dev
mcey_ has quit [Remote host closed the connection]
mcey_ has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 272 seconds]
msc has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
Saloframes has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
mcey has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
mcey_ has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
msc has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
abubakarsadiq has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
johnzweng has quit [Ping timeout: 246 seconds]
msc has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
<glozow>
🚀
Talkless has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #30010: lint: [doc] Clarify Windows line endings (CR LF) not to be used (master...2405-lint-win-crlf-) https://github.com/bitcoin/bitcoin/pull/30010
<instagibbs>
now that #28970 is in ( 🚀 earned), I'd like to see if people are interested in doing a WG for the remaining couple items for mempool policy pre-cluster mempool, starting with #28984 . Useful for LN and other cases today.
<instagibbs>
optimal linearization of size 1, finally someone who cares about speed
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
<gmaxwell>
If you then also bound transaction weight to be a small fraction of the limit, it then because easy to prove that the mining algrorithim has a small and tight approximation error bound.
<gmaxwell>
(cause include by feerate sort absent dependences obviously cannot be worse than optimal by more than leaving out the next transaction in the sort order after the last one that fit.)
<sdaftuar>
yep, part of the motivation to start making progress towards lower limits on tx size, eg #29873
<gmaxwell>
oh wow, I wasn't aware. Yeah, had the limits never been set very high it would probably be a mostly non-issue but it's always hard to restrict.
<instagibbs>
policy is kind of the opposite of consensus: easy to relax, hard to restrict
msc_ has quit [Ping timeout: 260 seconds]
Digger has joined #bitcoin-core-dev
preimage has joined #bitcoin-core-dev
msc_ has joined #bitcoin-core-dev
msc_ has quit [Remote host closed the connection]
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has joined #bitcoin-core-dev
Digger has quit [Quit: Client closed]
PennyEther has joined #bitcoin-core-dev
PennyEther has quit [Changing host]
PennyEther has joined #bitcoin-core-dev
<PennyEther>
Hi
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
<PennyEther>
Firstly, I'd like to apologize for any errors in my terminology. I'm looking for the part of the source code that handles when a new block is received from a peer. Presumably, the client will validate the block, and if it's acceptable, will consider it the new "head" block, and start mining off of it. I'd like to know how it handles receiving a
<PennyEther>
head block that has a height a few blocks higher than the currently known head block, as in this case it must receive all the blocks back until a common ancestor. How does it get these intermediate blocks?
<gmaxwell>
in modern bitcoin software it won't obtain the blocks at all unless it's first obtained the block headers and determined that the headers could constutite a best tip if their contained blocks were valid. In the early software, I believe the behavior, if it got a block where it didn't know the immediate ancestor of the block it would set the block aside and fetch the prior block from the same
<darosior>
s/if it/question if it/
<gmaxwell>
source, which it would then keep doing until it got to a common chain.
msc_ has joined #bitcoin-core-dev
<gmaxwell>
and yeah thats the sort of thing that would probably get some long, useful, researched stack exchange writeup.
<PennyEther>
It can't determine if the headers could constitute a best tip without evaluating the whole chain, since it needs to determine the total work in the chain
<gmaxwell>
sdaftuar: (as I look at sipa's answer:) are unsolicited blocks still processed?
<sdaftuar>
yes i believe so, if they're at (or build on) the tip
msc has joined #bitcoin-core-dev
<gmaxwell>
k, for some reason I thought those had finally gotten nuked (they at least used to get abused by some mass broadcasters that would selfishly send their whole newly found block to everyone they could connect to, ironically probably slowing its propagation)
<instagibbs>
I think ViatBTC sometimes still does this, very poorly? b10c ?
<instagibbs>
(they advertise witness stuff, you ask them, and they drop the response)
<sdaftuar>
i just double checked and i don't believe that logic (in `AcceptBlock()`) has changed since 2017 or so (and that might have just been a refactor)
msc_ has quit [Ping timeout: 260 seconds]
<gmaxwell>
lol still? yeah they were IIRC not just spamming blocks but doing it without the witnesses before.
<lightlike>
just at the tip? I thought having MinimumChainWork was sufficient.
<gmaxwell>
which is obviously useless.
<sdaftuar>
lightlike: yes you're right, not just at the tip. MinimumChainWork is not enough by itself though; must have more work than the tip
<lightlike>
ah, I see.
msc has quit [Remote host closed the connection]
<instagibbs>
wouldn't put it past them, I don't think their code ever actually worked, which is... interesting
<PennyEther>
Supposing I were reasonably confident I found a problem with Bitcoin Protocol, what would be a responsible way to disclose it? I'm nearly certain of a fundamental issue, related to timestamps.
<PennyEther>
I am well aware of median time and the 2-hour rule, but this is more existential than that
<gmaxwell>
I wonder if anyone has ever created a "I think I found a vulnerablity" FAQ that goes over all the things people keep thinking are vulnerablities and aren't, and things that are but are just unaddressed (e.g. becuase they're not 'limiting vulnerablties' -- if you could do that attack you could do much worse, and the worse thing doesn't have a known fix)
<PennyEther>
I spent hours searching for this last night, couldn't find it. Looked at the code and the way it handles it is insufficient. Trying to come up with the ramifications of it now
<gmaxwell>
like from PennyEther's questions, I might guess that they are thinking of the issues that header pre-sync solves.
<PennyEther>
I'll just ask about it here. What if a peer receives a block that is otherwise valid, except that it is 2 hours and 5 minutes in the future?
<PennyEther>
AFAIK, it is ignored.
<gmaxwell>
it gets ignored
<darosior>
PennyEther: then it's refused
<PennyEther>
Yes, but it shouldn't be.
<PennyEther>
It will be valid in 5 minutes.
<darosior>
Try again in 5 minutes :)
<gmaxwell>
it'll get picked up again later when its offered then and another block comes after it
<PennyEther>
Consider if it is 2 hours and 1 minute in the future
<PennyEther>
That's 1 minute of wasted work
<sipa>
it will not be rejected (as in: it won't be marked permanently invalid), it will just be ignored
<instagibbs>
as long as it's not permanently rejected(!) should be ok
msc_ has joined #bitcoin-core-dev
<PennyEther>
If it's 2 hours and 1 minute, then nodes that ignore it will be wasting work. As, in all likelihood, it *will* be the next valid block in just a minutes time
<PennyEther>
Hence, nodes should *not* simply discard based off the 2 hour rule. They should apply poisson distribution to determine the likelihood that it will become the next valid block
<Murch[m]>
PennyEther: How is that an issue? It’s no different than two blocks being found at the same height, if someone else happens to find a block before it becomes valid
<gmaxwell>
it may be or may not be, that will be decided by whomever wins the lottery and gets the next block.
<sipa>
tracing through the code, i believe the requirements for an unannounced block being processed are (a) either we already have the header, or the header passes min-pow checks (b) don't have the block already (c) has at least as much work as active tip and as minpow (d) height is not more than 288 than active tip's height
<PennyEther>
sipe, where do you find the 288 rule?
<gmaxwell>
PennyEther: assuming (cough) nodes times are synced and the broken miner who created it has insubstantial hash power, the probablity that it will be the next block is zero, because almost everyone will have ignored it as it was from the future at the time it arrived.
<sipa>
I guess my rule (a) is automatically satisfied if (c) is satisfied, so (a) can be ignored
<Murch[m]>
I mean, sure if some miners were running with a slightly fast clock, they would accept it, and others would not, and there might temporarily be two active chaintips. But again, it’s not clear to me how that introduces a security issue that is not resolved as soon as either the time passes or one of the chaintips pulls ahead the other in total work.
<gmaxwell>
Murch[m]: I agree. (this is also fwiw, not a new discussion, though I dunno if there is any specific prior one that would be useful to link to)
<PennyEther>
Yes, I agree, but lets play it out
<PennyEther>
Murch: two points. 1) a smart miner wouldnt simply discard it. they would hold it, and wait for it to be valid, then mine off of it.
<gmaxwell>
PennyEther: Are you imagining that if a minute passes then suddenly that block will be best? nodes don't reprocess it automatically. so the block remains effectively degraded even once its time is valid.
<PennyEther>
yes, but it shouldnt be degraded, it should be accepted (by smart miners), no?
<PennyEther>
2) it would behoove all miners to submit timestamps that get rejected by some (but not all) of their peers.
<Murch[m]>
Okay, let’s play it though.
<gmaxwell>
That would be an improved greedy strategy. (less clear if it's rational from a longer perspective since it's harmful to encourage from the future blocks)
msc_ has quit [Ping timeout: 260 seconds]
<Murch[m]>
Current best block is 100 at time T. Mallory mines block 101 with time T+201. When it’s broadcast 90% of the hashrate drops it on the floor, but 10% accepts it because they have skewed clocks or are "smart".
<gmaxwell>
(2) is why I included the synced times assumption. Though it is not in your favor to have less than 30% of the hashpower mining on your block.
<PennyEther>
let me rephrase 2. 2) It would behoove all miners to submit timestamps that get reject by some (but not the majority) of their peers
<sipa>
What does "submit timestamps" mean?
msc_ has joined #bitcoin-core-dev
<PennyEther>
timestamp in the other-wise valid new block
<gmaxwell>
sipa: adopt future timestamps when mining.
<Murch[m]>
After some time, with 90% likelihood, someone mines block 101' at T+about 11 minutes, with 10% likelihood, someone mines block 102 at time T+100 minutes. If 101' gets found first, there are two active chaintips where 101' is being mined on by 90% of the hashrate and 101 is being mined on by 10% of the hashrate. If 102 is found first, everyone reorgs to 102 and continues.
<sipa>
I think if you continue that reasoning, you'll end up with miners that just ignore the max-timestamp rule, and can end up heading off on their own, pushing timestamps ever further into the future... not the be accepted by the rest of the network, but hoping that these blocks will eventually be part of the best chain
<gmaxwell>
evenutally they bring mtp up to that threshold and then cant mine a chain that will be accepted in the present by 'honest' (in the hbar sense) software.
<Murch[m]>
So, Mallory loses their block if 90% of the hashrate mines two blocks before 10% of the hashrate mines 1 block. Either way that looks not particularly attractive to me. And 10% is pretty generous
<gmaxwell>
Murch[m]: mallories goal should be accepted by a third, then its essentially the same as 'selfish mining'.
<PennyEther>
Murch, your example only works because you did a 90/10 split, and because currently, the mining software rather stupidly drops soon-to-be-valid blocks rather than stores them.
<instagibbs>
gmaxwell yes, seems like the natural analogy is selfish mining?
msc has quit [Ping timeout: 260 seconds]
<gmaxwell>
PennyEther: it's not stupid to behave in a way that keeps the system working. :P but that aside.
<PennyEther>
It's stupid because it is not in their best incentive
<gmaxwell>
PennyEther: it's complicated, because if the collusion to behave in a way that undermines convergance breaks the system then they all go bankrupt. but I don't think we need to split these particular hairs.
msc has joined #bitcoin-core-dev
msc_ has quit [Remote host closed the connection]
msc has quit [Remote host closed the connection]
<PennyEther>
This is not about collusion, it's about financial incentive.. let me make an example
msc has joined #bitcoin-core-dev
<Murch[m]>
PennyEther: Unless it’s a coordinated change in behavior, the chance of losing their block reward seems way higher than them having an advantage.
<PennyEther>
First, an argument for not ignoring T+>2h blocks. If it's T+2h1s, then you shouldn't ignore it. It will be valid in just 1s. So you should mine off of it. In fact, an otherwise-valid block with a timestamp of T+2h6m has about a 65% of becoming valid before another block is found.
<Murch[m]>
If it’s a coordinated change in behavior, miners are undermining rules that keep the network safe. This tends to get some pretty strong reactions from the Bitcoin community.
<gmaxwell>
PennyEther: so in the selfish mining case which I think your example is just a special case of, the commonly proposed "fix" is to randomly select the next block in a race based on its hash. But this has the effect of creating selfish mining gains all the way down to 0 hashpower, so an attack that requires 1/3 hashpower (or participation) turns into a weaker attack that works from zero
<Murch[m]>
PennyEther: I think you have an adoption gap issue. The first miner to start behaving this way is going to lose money.
<gmaxwell>
hashpower up. So that fix is not an obvious win.
<instagibbs>
Murch[m] a single miner can trigger it, I guess is the point, vs "does this block move MTP up beyond 2 hours" ?
<instagibbs>
single block*
<Murch[m]>
instagibbs: But defacto all miners are just gonna drop it on the floor then, and the miner just loses their reward
<instagibbs>
but if it happens just once, miners will just ignore this game, as they do now
<gmaxwell>
maybe your variation has an advantage that some would 'accidentally' participate due to clock skew, propagation, etc. but I think that would need an numerical simulation to see if accidental participation mattered.
msc_ has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: there are 10001 things that participants could do to increase their income. For example, it would have been rational for miners to try to ignore the halving block and try to replace the block prior to the halving. But for any sufficiently rare non-optimality, you have to consider the development (and poentially goodwill) cost of exploiting the gain.
<PennyEther>
So... I'm supposed to rely on "strong reactions" from dissuading behavior which is otherwise financially benificial?
<gmaxwell>
Maybe? the security in the system ultimately arises from social and economic properties.
<Murch[m]>
It’s only financially beneficial if a big portion of the hashrate adopts your strategy, and it’s not in the interest for anyone to go first
<instagibbs>
PennyEther it is pointed out that it looks like a subset of an already-known attack, selfish mining, so it might be a good way forward to research on it? lots of e-ink spilled on the subject
<Murch[m]>
Sounds mostly like a mexican standoff unless a big portion of the hashrate changes their behavior to your strategy together
<PennyEther>
Murch, what do you mean by "it" when you say "it is only financially beneficial". It is financially beneficial to mine off of a block that is T+2h6m regardless of what any other peer is doing.
<gmaxwell>
Murch[m]: well "multiple equlibrium" is a nicer term than mexican standoff.
<instagibbs>
(maybe not a subset, but related)
<gmaxwell>
PennyEther: no because it will get your block ignored too when you're successful.
<Murch[m]>
PennyEther: But it’s financially detrimental to mine the T+2h6min block
<instagibbs>
> It is financially beneficial to mine off of a block that is T+2h6m regardless of what any other peer is doing.
<instagibbs>
you're making assertions that aren't necessarily true
<PennyEther>
instagibbs, this assertion is true
msc has quit [Ping timeout: 260 seconds]
<PennyEther>
There is a >50% chance that the T+2h6m block will become valid BEFORE another valid block is mined
<gmaxwell>
PennyEther: say you are mining, you get a T+2h6m block. Is it in your interest to mine off it right now? no it is not. if you are successful right now, your block will also get ignored/have poor propagation.
<gmaxwell>
PennyEther: that's a misunderstanding of the mining process.
jonatack has joined #bitcoin-core-dev
<PennyEther>
No. There is a 51% chance your block will become valid before another block is found, meaning you were allocating work correctly. in the other 49% chance, you will start mining off of the other valid block.
<gmaxwell>
No.
<instagibbs>
you're assuming the answer tbh. It's not obvious.
msc has joined #bitcoin-core-dev
<sipa>
PennyEther: let's make the example more extreme. You have 1% of the hashrate, and you see a block with a timestamp that's a day into the future. Is it beneficial for you to mine on it, assuming that you know for a fact that 99% of the hashrate will ignore blocks with a timestamp more than 2 hours?
<gmaxwell>
PennyEther: mining is memoryless.
msc has quit [Remote host closed the connection]
<PennyEther>
instagibbs, the answer is derived from poisson distribution probability. I'm moving on from discussing if the assertion is correct or not, because we can just use T+2h1s and be certain the odds are in your favor
msc_ has quit [Remote host closed the connection]
msc has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: when you attempt a mining operation, it will either find a block or it won't. Lets assume it doesn't, then you go again,-- this second time your success is independant of any of your desisions at the prior stage.
<PennyEther>
Regardless of your hashrate, if you receive a block that is T+2h6m, it is to your benefit to hash off of that block, not the old one. in 6m time, that block will become valid. there is <50% chance that another valid block will be found before then. this is derived from poisson probability. are we all on the same page?
<gmaxwell>
PennyEther: so in your example, when the block is T+2h6m if you attempt to mine it and are successful in that attempt you'll just have yourself another block that gets ignored. Now-- would it be rational to start attempting to extend it once its at T+2h? Yes, at that point in time.
<gmaxwell>
no we are not.
<Murch[m]>
PennyEther: I think the main disconnect is that when the miner publishes their block with a timestamp of T+2h6m, all of their peers will drop it on the floor and nobody will even hear about it.
<gmaxwell>
PennyEther: you would be best off just attempting to orphan it for some span of time. (perhaps not the full 6 minutes, that would require a careful analysis).
<Murch[m]>
It’s not like people sit pouring over their debug.log all day and manually accept blocks that are invalid according to network rules.
<PennyEther>
let me just write out the example very clearly.
<instagibbs>
It's a question of if they should drop or not, and it's highly dependent on what others are doing
<PennyEther>
no, its not dependant on others. let me write it out.
<sipa>
We can simulate this.
msc_ has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: so say you and I are miners and we see this 2h6m block. You mine on it, I reject it. a minute passes. I find a block. the network adopts my block and will not be unseated by the delayed block because mine was 'first valid'.
PennyEther has quit [Quit: Client closed]
<gmaxwell>
There is a hashpower sensitive component to this (because as I said, it's an analog to the selfish mining paper), where this works out for you but only if you have enough hashpower that you can get the future block two ahead by the time its valid.
msc has quit [Ping timeout: 260 seconds]
<gmaxwell>
and I believe that point is at ~30% hashpower participating on the future block.
msc has joined #bitcoin-core-dev
<Murch[m]>
Whoever said it earlier hit the nail on the head. It seems to me that this boils down to a variant of selfish mining
msc_ has quit [Ping timeout: 260 seconds]
<gmaxwell>
doesn't make it uninteresting.
<gmaxwell>
I mean it might be the same thing: if you fix by randomizing your acceptance, then you make it immediately interesting to defect from protocol conforming behavior even if you're alone. ... or the natural skew in acceptance times might make the behavior change reasonable regardless of hashpower.
msc has quit [Ping timeout: 260 seconds]
<gmaxwell>
Murch[m]: and meanwhile, running a constraint solver against the mempool yields a block that pays $2000 more in fees than the one that is gonna get mined. :P (not really, well didn't try, but it used to be pretty normal when there was backlog)
msc has joined #bitcoin-core-dev
PennyEther has joined #bitcoin-core-dev
PennyEther has quit [Changing host]
PennyEther has joined #bitcoin-core-dev
<PennyEther>
Is there any way to view chat history? I got DC'd
<gmaxwell>
PennyEther: I think sipa is off simulating this right now.
<sipa>
haha, no
<gmaxwell>
oh damn getting slow in your old age. lol
msc_ has joined #bitcoin-core-dev
<sipa>
gmaxwell: i
<sipa>
gmaxwell: i'm working on reducing that $2000, ok?!
<gmaxwell>
haha
<sipa>
:P
<sipa>
though, limiting transactions to 25 kvB would really help, kthxbye
bugs_ has joined #bitcoin-core-dev
<gmaxwell>
sipa: you and sdaftuar will do some heroic work with cluster mempool, then murch can swing in with something that forks and calls some coinor off the shelf solver and produces optimal solutions for the entire block including tail packing in 50ms. :P
msc has quit [Ping timeout: 260 seconds]
<PennyEther>
Current block is 100, and wall clock is 0. You receive block 101-f (f for future), with T=2h6m. Most clients (foolishly) drop this block.
<PennyEther>
However, based on probabilities, there is a >51% chance block 101-f will become active BEFORE block 101-a (another block with prev = block 100) is discovered. To make the example more clear, just imagine block 101-f has T=2h1s. In just 1s, somebody can resubmit the block and it will be taken as the current block.
<PennyEther>
So, when you receive block 101-f with T=2h6m, you *should* start mining off of it. In all likelihood, it will become the next valid block, and you'll have a head start on the new chain. If in If block 101-a comes in before, then it is up to you which one to work on, it makes no difference. The advantage is in the 6m head start you get.
<PennyEther>
We can now start to see how hashrate might get forked if miners start mining in this "smart" manner of NOT ignoring valid blocks (with invalid blocktimes). It is in their best incentive to look at future blocks and determine the likelihood they "vest" into the actual blocks. Assuming a poisson distribution with mean of 10m, anything less than ~2h7m
<PennyEther>
should be temporarily accepted as the head and mined off of. Again, it's far more obvious if we go with 2h1s.
<PennyEther>
Furthermore, miners are INCENTIVIZED to submit blocks with timestamps that cause their peers to continue hashing off of block 100 rather than 100-f. At present, that would be T=1h59m ... because, the code (at present) foolishly drops future blocks. Regardless, If I submit a block 100-f with T+1h59m, I will cause some % of miners (with slow clocks)
<PennyEther>
to ignore the block. This effectively forks the hashrate between 100 and 100-f.
<PennyEther>
This provides further benefit (beyond strictly the probability) to mining off of 100-f rather than 100.. because 40% of your peers are wasting their time on 100-f.
<PennyEther>
Extending this further.. if we assume miners do start acting rationally and do start mining off of block 100-f with T=2h6m, then I believe there are more severe ramifications other than just some drift.
blockdyor has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 268 seconds]
msc has joined #bitcoin-core-dev
<sipa>
gmaxwell: both are great; the point of clustermempool is primarily making relay policy capable of reasoning about what is an improvement, though as a side effect it will improve block building itself too
<PennyEther>
There's my example. Appreciate your thoughts.
jonatack has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: I think you are using an overly quantized mental model, and thinking of mining as a choice you make block by block. As a result there is a superior strategy to what you sugget.
<gmaxwell>
suggest*
<gmaxwell>
PennyEther: which is that someone can mine on 100 until 101-f becomes valid, and then instantly switch to that.
<PennyEther>
You are failing to understand the poisson distribution.
<PennyEther>
That is not a superior strategy
<gmaxwell>
and that is superior, I say, to mining on 101-f, unless the 101-f' miners have enough power to get it two ahead before 101-a is found.
<PennyEther>
No. 101-f will most likely become valid BEFORE 101-a is found.
<PennyEther>
regardless of hashrate on 101-f
<PennyEther>
In 6 minutes, it will simply be resubmitted and accepted.
msc_ has quit [Ping timeout: 260 seconds]
<gmaxwell>
PennyEther: perhaps you should not concern yourself so much with what I do or don't understand.
<gmaxwell>
I know you probably live your life in frustration of people who are completely uncomfortable with statistics, but please trust me for a moment that I am not one of them.
<PennyEther>
heard.
<gmaxwell>
:)
<PennyEther>
So, you agree that 101-f is more likely become valid before 101-a is found?
<gmaxwell>
Yes.
<PennyEther>
Ok, I didn't think you understood that, my apologies.
<PennyEther>
Having that understanding, why do you believe that mining off of 101-f is an inferior strategy?
msc has quit [Remote host closed the connection]
<gmaxwell>
though most blocks will be found in less time than the expectation thanks to the distribution, but I don't think that matters for this discussion)
<PennyEther>
~50% of blocks will be found in under 6m57s, which is why I go with T=2h+6m .. to be sure it's >50%
<gmaxwell>
PennyEther: Lets imagine you and I adopt opposing strategies. I will mine on 100 until 101-f is valid. You will just mine on 101-f.
<PennyEther>
Sure.
msc has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: so if I find a block anywhere from the arrivial time until 101-f's validity, the network will be working on extending my block. At 101-f's validity time we become the same.
<PennyEther>
I would switch to your block if you found it first.
<PennyEther>
If you find 101-a, I'll switch to 101-a.
<PennyEther>
Most of the time, you will not find 101-a first
<gmaxwell>
no but I'm not harmed by trying, and I do sometimes find it first.
msc_ has joined #bitcoin-core-dev
<gmaxwell>
so I say it's only an advatnage to mine on 101f prematurely if I (and other timestamp ignoring nodes) have enough hashpower that when 101f becomes valid my fork will win even against a tie, e.g. that it'll have a one block advantage.
<gmaxwell>
and without that I'm better off staying on 100 until 101f is valid and instantly switching when its valid.
<PennyEther>
Ok, I agree
<PennyEther>
Actually, I disagree.
<PennyEther>
LOL ok let me think
<gmaxwell>
so I think the system has multiple equibrium: 100 and instant switch is a domant strategy until some threshold hashpower is willing to mine in the future. But I might be reasoning excessively from the selfish mining results, and be incorrect. :)
<PennyEther>
I think you are correct to mine off of 100.. if you find a block, you 100% keep it. If you find a block on 101-f, you only 51% (but increasing through time) get to keep it.
msc has quit [Ping timeout: 260 seconds]
<PennyEther>
Now how do things change with 101-f having T+2h1s
msc has joined #bitcoin-core-dev
<PennyEther>
Do we assume that in 2s everyone will see 101-f again and accept it?
<gmaxwell>
aside, I think you're also right that in theory miners should be keeping the block (and switching as I suggest) at least when it becomes valid: but so long as no one produces such blocks, there is no reason to implement it. And so long as that logic isn't implemented there is very good reason to not produce such blocks (perhaps still reason to not produce even if miners would switch).
<instagibbs>
the "attacking" miner can always resend the block as soon as it matures, seems straight forward enough
<gmaxwell>
PennyEther: well the current behavior in the network is that everyone will continue to ignore 101-f unless at some point after it becomes valid someone relays a child block on 101f and then they'll take both (with somewhat slower propagation)
<gmaxwell>
yes, and they could resend to make that happem though it doesn't currently happen automatically.
<PennyEther>
Could you explain to me why a miner would NOT submit 101-f with a timestamp of T+1h59m59s? It would appear strictly advantageous to "trick" the hashrate with slower clocks to continue on block 100, while the majority will carry on with 101-f
msc_ has quit [Ping timeout: 260 seconds]
<PennyEther>
If the concern is their block might get rejected, they can choose a T+1h59m58s... or "low" enough timestamp that they are certain consensus agrees with them
<sipa>
PennyEther: i'm not following entirely, but just to make sure this isn't a misunderstanding: miners need to decide on the timestamp of the block template before attempting to mine on it; it can't be changed after the fact
msc_ has joined #bitcoin-core-dev
<gmaxwell>
because you want your block to be continued, as your block may be (unknown to you) in a race which is only decided by the next block found after yours.
<PennyEther>
sipa: yes, I understand. they can adjust the timestamp as they mine, such that if found T= T+1h59m59s
<gmaxwell>
PennyEther: yeah your use of the word submit was probably causing sipa concern.
<sipa>
PennyEther: indeed; in that case ignore my comment :)
<gmaxwell>
PennyEther: so for the same reason the selfish mining paper claims, if you have low hashrate relative to the network you very much wnat everyone else trying to continue your block ASAP to make sure you're the winner in a race.
<gmaxwell>
For sufficiently high hashpowers this incentive reverses, and you are better off to 'withhold' your block.
<PennyEther>
I see. Let me play out an example, please correct me where I'm wrong
msc has quit [Ping timeout: 260 seconds]
<PennyEther>
Let's say you mine block 101-f with T such that you think 90% of the hashrate will accept your block (eg: their clocks arent slow). Eg: T=1h50m. The disadvantage here is that 10% are still hashing on 100, and they might find 101-b. In which case, what happens? 101-f has 90%, 101-b has 10%.
msc has joined #bitcoin-core-dev
<PennyEther>
Still seems to me an incentive to let timestamp drift up to near the T=2h mark.
msc_ has quit [Remote host closed the connection]
<gmaxwell>
PennyEther: also imagine someone else finds a block effecitvely concurrent with you and that you've done this. They will end up with more hashrate trying to continue their block than you have.
pablomartin4btc has joined #bitcoin-core-dev
<gmaxwell>
so they are more likely to win the race.
<gmaxwell>
But if your hashpower is very great, then you plus the percentage you've carved off with your timestamp and won in propagation, will have more hashpower behind it than the other honestly stampped block. So in that case it's an advantage.
<achow101>
oh hey, gmaxwell, long time no see
<gmaxwell>
Hi Ava!
<gmaxwell>
PennyEther: considering your example, I think differences in node timesync on that boundary have a similar effect on mining fairness that propagation times do.
<gmaxwell>
in other works, I think nodes having clocks that differ by 10 seconds is a lot like nodes taking 10 second to propagate a block, -- in the presense of blocks that are right up on the boundary.
msc has quit [Ping timeout: 260 seconds]
<PennyEther>
gmaxwell: why would somebody else finding a block end up with more hashrate? I chose a value of T < 2h in this case
<PennyEther>
block 101-f should be accepted by the vast majority (eg: 90%)
msc has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: yeah I understand you've assumed that timestamps are desynced enough on miners such that you can carve off 90% through your timestamp choice.
msc has quit [Remote host closed the connection]
msc has joined #bitcoin-core-dev
<gmaxwell>
PennyEther: but say I'm mining and then sometime shortly before or shortly after you, I find a block and mine is timed normally. I'm obviously acceptable to the 10% that reject you so I should get all of them. I'll also get whatever share of other nodes I'd othrewise get in a race with you (so lots of them if I was first, few if you were first).
<gmaxwell>
so your decision to push your timestamp hurt you in the race with me.
jonatack has quit [Ping timeout: 252 seconds]
msc has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
<PennyEther>
I see. So then it's a question of the costs of losing that race condition (which depends on propagation time distribution), vs the benefits of carving off 10% of hashrate for some period. Correct?
<gmaxwell>
yeah well also the carving off the hashrate doesn't directly benefit you I think: it causes them a higher orphaning rate. which then only benefits you after it cases a reduction in difficulty.
<gmaxwell>
(even more than your other situation this one is exactly the pattern discussed in the selfish mining paper, except using the timestamps to cause blocks to be withheld from some miners)
jonatack has quit [Ping timeout: 252 seconds]
<PennyEther>
true, it does not directly benefit me if others are hashing less. I am competing against difficulty.
msc has joined #bitcoin-core-dev
<gmaxwell>
so essentially you take on more race loss risk in exchange for making some othre miners have higher orphan rates. So this may not look too good if hashrate is increasing overall because you've forgone some lower difficulty income for some higher (but still reduced from what it would have been) difficulty income later.
<PennyEther>
also the decrease in difficulty would only be a 1 shot deal over all of time, correct? just an extra ~2h in one difficulty period.
<PennyEther>
the end result is just a ~2hr forward drift in timestamps, and that's it
msc_ has joined #bitcoin-core-dev
<gmaxwell>
ah: two things: the forward timestamp thing only lets you get 2hours once (ignoring the timewarp attack which is another matter). Yes, but above I wasn't referring to that. I mean the result of partitoing off that 10% is that sometimes they get two blocks and win, but more often they get none (no effect) or 1 block, in which case their one block gets orphaned. They have a higher orphan rate.
<gmaxwell>
This doesn't directly profit you but it means takes longer for the network to mine 2016 blocks and so difficulty is reduced.
zeropoint has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
jonatack has joined #bitcoin-core-dev
msc_ has joined #bitcoin-core-dev
<PennyEther>
Correct. Thank you for the distinction
S3RK has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc_ has quit [Remote host closed the connection]
msc has joined #bitcoin-core-dev
S3RK_ has quit [Ping timeout: 260 seconds]
cguida has joined #bitcoin-core-dev
<PennyEther>
So, to recap: Choosing 101-f having T=2h5m is not a good strategy simply because most miners will ignore it, and if there's a block 101-a that comes in before hand, they'll switch to that one, and you'll lose the race between 102-f and 102-a
<gmaxwell>
Yes until it's valid, in which case it would be good to switch. it would be rational for miners to implement that logic today but absent any 2h5m blocks it's not worth the cost to code/test/etc.
<PennyEther>
Presumably the submitter would resubmit after 5m, anyway
<gmaxwell>
haha
<gmaxwell>
they should.
<PennyEther>
gmaxwell, thank you very much for exploring this with me
<gmaxwell>
But same kind of logic applies: absent this happening, I bet no one has implemented logic to do that.
<PennyEther>
I'm sorry I accused you of misunderstanding the poisson distribution, I see that the game theory / consensus impact does indeed outweigh the probability aspect
<gmaxwell>
(while you were out I quipped that miners routinely leave thousands of dollars in fees on the table that they could have taken with moderately smarter transaction selection code)
blockdyor has quit [Remote host closed the connection]
<instagibbs>
I suppose for selfish mining mitigations(DAG ones) you'd aggregate the future blocks into your tip to not have difficulty reduce?
<gmaxwell>
PennyEther: oh no offense taken. I just wanted to move the discussion over to areas that I was more likely to have misunderstood.
msc_ has joined #bitcoin-core-dev
<PennyEther>
very prudent, it work out. thanks again.
<PennyEther>
*worked
<gmaxwell>
PennyEther: and indeed, I thought it was an interesting discussion too.
<instagibbs>
+1
<gmaxwell>
instagibbs: well whats your incentive to mine a orphan marker? it'll increase difficulty! :P
<instagibbs>
non-attacker? same reason as the uncle stuff I'd think
<instagibbs>
(it's been way too long since ive read hte literature)
<gmaxwell>
instagibbs: ethereum gave people reward for this and I understand that people gamed it by intentionally maxing out the orphan rate to increase the yield.
<gmaxwell>
and so they cut back the reward significantly eventually.
<instagibbs>
it was *really* broken when it didn't add the uncles into the difficulty retarget
<instagibbs>
sounds plausible :)
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
cguida has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] kevkevinpal closed pull request #29994: doc: removed help text saying that peers may not connect automatically (master...docsRemoveNetNote) https://github.com/bitcoin/bitcoin/pull/29994
<bitcoin-git>
bitcoin/master e504b1f Brandon Odiwuor: test: Add test case for spending bare multisig
<bitcoin-git>
bitcoin/master d73245a merge-script: Merge bitcoin/bitcoin#29120: test: Add test case for spending bare multisig
<bitcoin-git>
[bitcoin] achow101 merged pull request #29120: test: Add test case for spending bare multisig (master...spending-bare-multisig) https://github.com/bitcoin/bitcoin/pull/29120
ion- has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has joined #bitcoin-core-dev
ion- has quit []
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
cguida has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
cguida_ has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
cguida has quit [Ping timeout: 268 seconds]
msc_ has joined #bitcoin-core-dev
the_mariner has quit [Ping timeout: 260 seconds]
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
cguida_ has quit [Ping timeout: 246 seconds]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
VonNaturAustreVe has quit [Quit: Leaving]
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
Guest64 has joined #bitcoin-core-dev
Guest64 has quit [Client Quit]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
PennyEther has quit [Quit: Client closed]
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
blockdyor has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Remote host closed the connection]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
cguida_ has joined #bitcoin-core-dev
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
cguida_ has quit [Ping timeout: 272 seconds]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
nanotube has quit [Ping timeout: 246 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
mudsip has quit []
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.2.2]
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
msc has joined #bitcoin-core-dev
msc_ has quit [Ping timeout: 260 seconds]
msc_ has joined #bitcoin-core-dev
msc has quit [Ping timeout: 260 seconds]
Lockesmith has quit [Remote host closed the connection]