< adiabat>
right, so I'm just suggesting, for rpc calls, return the cost of the tx
< gmaxwell>
(there is a problem with using the word cost, annoyingly, it seems like it gets confused with fee)
< adiabat>
yeahhhh I know
< gmaxwell>
when it's just an abstract unit.
< adiabat>
It's just that right now it's a bit confusing because blocks have cost and txs have Vsize
< adiabat>
seems like you could say that txs also have cost with no real loss of information
< gmaxwell>
they do, the vsize is strictly a lossy unit.
< gmaxwell>
I agree they should be consistent. And really, they should be the cost unit..
< gmaxwell>
I wish we had a better word than cost.
< adiabat>
OK cool that's what I'm saying
< adiabat>
with txs now, you see:
< adiabat>
"size": 38919,
< adiabat>
"Vsize": 26433,
< adiabat>
but you could return "size": 38919, "cost": 105732
< adiabat>
that way it's more consistent and one less name to keep track of for users
< CubicEarth>
gmaxwell: Thinking about your 'carving a block of marble' analogy for forks, and thinking about the nature of Bitcoin, I tend to think that anything can be accomplished with a 'soft-fork', such as effectively raising the coin limit, etc. I see it like a nested-universe scenario, but in the marble analogy... take the statue of David. Say we find ourselves disappointed that Michelangelo didn't give David
< CubicEarth>
two heads. We could basically carve a miniature replica of David out of the right butt-cheek of the full size version, with the 'replica' having two heads. In real life there would be problems with absolute scale, but I don't see a parallel in code.
< CubicEarth>
Perhaps I am taking the analogy too far.
< gmaxwell>
You can try, but it's not invisible or non-consentual.
< gmaxwell>
Imagine that you try to make more coins.. well no existing wallet will reconize or accept those coins.
< gmaxwell>
you pay me some 0 value output that the softfork reconizes as the extra coins. fine.. but my wallet will see it as zero.
< CubicEarth>
That is true
< CubicEarth>
Thankfully
< gmaxwell>
so the most you could do is try to also DOS attack me to force me into going along with that change and accepting those coins, but that reduces to a power miners always have (DOS attacking users) which has a tidy solution: change the POW to fire the service provider (miners) that are screwing over the users and not faithfully including ordinary transactions.
< dgenr8>
<gmaxwell> These folks are extremely and dangerously incompetent.
< dgenr8>
Don't be so hard on yourself. The last core checkpoint was 4 months old when added to a release candidate.
< dgenr8>
That's the same as XT when 4 script checking threads are enabled
< dgenr8>
Your 1-day figure is off by a factor of 30
< dgenr8>
...
< dgenr8>
The partition risk to XT is a result of your sneak attack on its usage of bip37 for the original thin blocks mechanism. Thanks for that.
< luke-jr>
sure, blame us for your bugs..
< luke-jr>
you could have easily taken petertodd's patch to prefer RBF connections and used it for thin blocks instead
< gmaxwell>
dgenr8: Checkpoints, dumb as they are, reference a particular block, they're not subject to miners claiming old times on blocks. The code in classic, at least, triggered at one day, and I've already tested making it accept invalid blocks on a chain without reorg. If you backed it off to make it more sensible then good for you, but triggering on header timestamps is still incompetent.
< dgenr8>
If you choose not to explain your test, we'll have to assume you gave yourself 100% hash power and control of the local clock
< gmaxwell>
dgenr8: I immediately pointed out the attack when classic proposed this fool scheme. Miners can widen the permitted time back arbritarily far, and then a single block can be created that breaks the rules without any reorg at all. No clock control is required.
< gmaxwell>
The fact that you also didn't immediately sees this shows that you are probably not qualified to be maintaining an implementation that makes security critical changes such as this.
< gmaxwell>
The fact that it's possible for miners to widen the accepted time window has been well known since at least 2011.
< gmaxwell>
(google "timewarp attack" for a description on widening the accepted timestamp window)
< gmaxwell>
Though even if that attack didn't exist, and it did require all the blocks to agree, it still wouldn't require changes to the local clock... and it _still_ would be a change to the security model that deserved the loudest possible disclosure.
< kanzure>
and even if local time change was required, aren't lots of time protocols busted anyway?
< gmaxwell>
yes, including the one built into bitcoin's p2p protocol, though thats several layers of irrelevance down the line. (also an attacker who can influence that one is already too powerful)
< kanzure>
yeah but who needs clock time when you have block time (/cringe)
< dgenr8>
So yeah, well over 51% hash power required
< gmaxwell>
so now you've gone from 100% and local clock control to over 51%. Actually that isn't quite correct still.
< gmaxwell>
A majority hashpower is needed to open the time window, but once it does, anyone can produce an invalid block. Moreover, when synchronizing, a partitioned node will accept a backdated invalid chain -- even if the attacker had far less than a majority hashpower.
< dgenr8>
XT, like Core, is vulnerable to 51% of hash power doing all sorts of nasty things. And a partitioned Core node is vulnerable to an invalid backdated chain prior to the checkpoints.
< gmaxwell>
No, the scriptsig skipping is pinned to a particular well known chain hardcoded in the software. This chain is not invalid.
< gmaxwell>
The primary, nearly exclusive, argument provided to why someone won't overpower the network (e.g. briefly) is becaues there isn't much that they can do with it. They can't just blank-check write themselve an extra 100,000 Bitcoin. They can DOS attack and double spend their own payments.
< gmaxwell>
You and your community (while you withhold contradiction) have regularly and agressivly attacked very narrow soft-forks because they cause some non-upgraded warning-spewing nodes to not check a few new rules introduced, and then nearly silently and without fanfair you roll out a feature that makes every node running your software check no signatures at all on any block when the miner provided ti
< gmaxwell>
mestamp is old.
< gmaxwell>
and you have done so without even actually understanding the effect, as demonstrated by your above "100% hashpower and control of the local clock"
< kanzure>
iirc they are fine with malicious miners and rule invalidity
< kanzure>
e.g. "it's up to the miners"
< gmaxwell>
kanzure: not so, or they would have nothing to complain about softforks at all.
< kanzure>
i don't mean to strawman anyone but it would explain the observation
< kanzure>
ah hmm
< gmaxwell>
don't mistake pure politics for technical understanding or logic.
< kanzure>
maybe it's more of a "just query the miners" sentiment. dunno. but rapidly off-topic from my end for this channel.