Aug 3, 2021 01:33
not sure how I can thank you
Aug 3, 2021 01:33
i'll think about your points, it was very helpful
Aug 3, 2021 01:32
but a trivial code is still more code than no code
Aug 3, 2021 01:32
yep, it isn't complex
Aug 3, 2021 01:29
that is a great point though, I need to think more about it
Aug 3, 2021 01:28
isn't that good? that means that holding it is a bad idea because once you decide to publish it, someone else will also have a 1000x block, so you just wasted all your mining on the last mins
Aug 3, 2021 01:26
are you 100% sure that's not the case?
Aug 3, 2021 01:26
not sure what the actual math is but my gut feeling is that it is a self correcting problem?
Aug 3, 2021 01:25
and if it isn't common enough (say, it happens once every 1000000 blocks) then it isn't really a problem
Aug 3, 2021 01:25
I'm not sure I get how this would be a problem... if mining a 1000x better block is common (say, it happens once every 10 blocks), then someone that does get a 1000x better block only has 10 blocks to mine before someone else finds a 1000x better block too... (?)
Aug 3, 2021 01:24
hmm
Aug 3, 2021 01:21
the thing is, you'll need that your blocks 1 and 2 out-score the network blocks 1 and 2 added. that is very unlikely
Aug 3, 2021 01:20
it is of your best interest to focus all your efforts on the block of the current time, because the only way to get a block accepted permanently is to spread it as fast as possible and get other nodes to start mining on top of it
Aug 3, 2021 01:19
you can pre-mine for as much as you want, but then you're just spreading your hash-power and making it less likely to get a block through
Aug 3, 2021 01:18
yep
Aug 3, 2021 01:16
yep, but again, the same algorithm Bitcoin uses to get a reliable network time could be used on my proposal, so it still looks equivalent, albeit less efficient
Aug 3, 2021 01:13
but again I don't see how time attacks could be avoided, there is no way to know what time is it without trusting your peers, right?
Aug 3, 2021 01:13
sad, then
Aug 3, 2021 01:12
should be more updated though, it is a pretty important page lol
Aug 3, 2021 01:12
fair enough
Aug 3, 2021 01:11
I could be wrong
Aug 3, 2021 01:11
so I think it hasn't changed much
Aug 3, 2021 01:11
But it is linked on en.bitcoin.it/wiki/Weaknesses
Aug 3, 2021 01:10
hmm yea, sorry
Aug 3, 2021 01:09
IIRC Bitcoin nodes just use the average reported time of ~6 peers to define its own time
Aug 3, 2021 01:09
iirc*
Aug 3, 2021 01:09
that opens up a few attacks that have no solution, irrc
Aug 3, 2021 01:08
your peers could be lying to you, after all
Aug 3, 2021 01:08
yep, but that doesn't guarantee your time is real
Aug 3, 2021 01:07
Yep, that's right
Aug 3, 2021 01:07
I believe Bitcoin does rely on sync though, there are time attacks that basically have no solution. Pretty sure I've read that from a reliable source
Aug 3, 2021 01:06
You don't need to be sure the person *actually* mined that block in the right interval. I can mine the 12:20 block even 1 day later if you want to. But you can't mine the 1000th block, if the network has lived for only 2 hours. I.e., on the first 10 minutes, your node won't accept chains larger than 1 block. On the 20th minute, it accepts chains up to 2 blocks. On the 30th minute, it accepts chains up to 3 blocks. I.e., each node would define a maximum acceptable length as a function of its internal clock:
Aug 3, 2021 01:03
No, you got it wrong - I just meant there is no timestamp on the block, you infer it from the block height. I.e., if the genesis block started on January 1, 12:00 PM, then the first block has an implicit timestamp of 12:10, the second has an implicit timestamp of 12:20, and so on. But you absolutely need some sort of clock synchronization (but so does Bitcoin)
Aug 3, 2021 01:02
on my question
Aug 3, 2021 01:02
"Suppose that Bitcoin nodes had no target difficulty at all, and instead just accepted the block with the largest PoW every 10 minutes"
Aug 3, 2021 01:02
I did though
Aug 3, 2021 01:01
They wouldn't be able to do that though, because nodes would only accept 1 block every 10 minutes
Aug 3, 2021 01:00
Ah, fair enough. I do think that would happen, that's why I mention the finality time would be higher, to counter that. Basically I'm trying to design a simpler (i.e., less code to implement), but also less efficient Bitcoin.
Aug 3, 2021 00:59
Ah, in that case I guess you indeed should keep it secret for a while. But why is that a problem?
Aug 3, 2021 00:57
Fair enough, but what that gets you? Let's say you're mining the 38th block on top of your private 37th block that has a score of 1000. The current public 37th block has a score of 800. People are now mining the 38th block on top of it.

So, you're lonely mining on top of your 1000-score block, with your, say, 10 hashes per second. The rest of the network is mining on top of the 800-score block with its total of 1000 hashes per second. So, 1 hour later the network has the 37th and 38th block with `800 + 1000` score, and you have the 37th and 38th block with `1000 + 10` score. If you just ha
Aug 3, 2021 00:52
(Let's assume that score = (1 / (2^256 - block_hash)), i.e., an estimation of how many nonces it took to get a hash that low.)
Aug 3, 2021 00:51
So 1 hour later, you have 1 block with 1000 score, and 5 blocks with 100 score. That's a total of 1500 score. If you publish it now, the 6 last blocks of the network will have 500 * 6 = 3000 score. You won't get it through.
Aug 3, 2021 00:51
If you keep your low-hash block a secret, then you'd get outrun by the network and lose the opportunity to have it accepted, no? Say, you mine a very low hash (score: 1000) at 16:26 and keep it a secret for 1 hour. That is higher than the network average of 500, so it is very likely you'll get it accepted if you publish it. Your next 6 blocks aren't that good (after all, you're a single miner).
Aug 3, 2021 00:43
Of course, you can try to re-mine older blocks, but that makes it much less likely that your blocks will propagate, so you have incentive to always mine on top of your best block, i.e., your tip with the most accumulated PoW.
Aug 3, 2021 00:43
I see, now these are interesting points to keep in mind. I'm not sure if what you're saying really holds, i.e., if most of the computing power would be wasted, and if it is really hard to define which block to mine upon. But these are sensible points to consider. Thanks for the inputs.
Aug 3, 2021 00:43
I think you'll always be mining on top of the best block for the last 10 mins period, trying to get smaller and smaller hashes, and broadcasting the best block you have (even if it isn't yours). As long as miners keep doing that, blocks with low difficulty will just not propagate, and good blocks will reach everyone. After the 10 mins mark, miners would start mining on top of the best block they have for the latest 10 minutes period, which will almost always be the right one. If it isn't, soon enough the right one will arrive and they won't have wasted that much effort.
Aug 3, 2021 00:43
@Murch yes, lowest hash. That is exactly what I mean. Bitcoin's chaintip isn't 100% reliable either, you need ~6 confs for maximum security. In such proposal, the finality time should be considered to be quite large (say, 24h). My point is: it would work as a consensus algorithm, it would just be less efficient for finality than Bitcoin, but would be arguably simpler to implement, and more secure to against these several target-difficulty-related attacks. Does that make sense?
Aug 3, 2021 00:43
@Murch there is no timestamp. But yes, you could "re-mine" old blocks if you wanted to. But you'd still need to provide all the newer blocks, with more accumulated work, for it to be accepted. Re-mining sufficiently old blocks would be infeasible, so, ultimately, nodes do reach a consensus w.r.t. the canonical chain, exactly like on Bitcoin, no? What I'm saying is: I still don't see why a target difficulty, rather than just collecting blocks and computing the largest chain, is required for that.
Aug 3, 2021 00:43
Why doesn't just PoW suffice for that consensus? As long as nodes have a roughly synchronized clock, the time a block was mined could be computed by genesis_time + 10 mins * block_count. Nodes just broadcast blocks as usual and pick the chain with the largest work.