sipa changed the topic of #bitcoin-wizards to: This channel 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
Dizzle has quit [Remote host closed the connection]
Dizzle has joined #bitcoin-wizards
Dizzle has quit [Remote host closed the connection]
MaxSan has quit [Quit: Leaving.]
jb55 has quit [Ping timeout: 258 seconds]
<luke-jr>
sipa: confusing >_<
<luke-jr>
sipa: any reason not to be consistent and drop the toward-block-sigop-limit too?
<sipa>
luke-jr: dropping limits scares me, but there's no reason to not consider it
<luke-jr>
sipa: well, I'd probably leave it, except it's already dropping it for signature-embedded scripts and tail-call scripts anyway..
<sipa>
why would you drop it for those?
<luke-jr>
not practical, since they break static analysis
<luke-jr>
you'd need to count them at execution
<sipa>
i think you either need a way to count them at execution, or not do it then
<luke-jr>
maaku was arguing that sigops are now so cheap that the weight limit is sufficient
<gmaxwell>
only if you can't do 2DUP 2DUP 2DUP 2DUP CHECKSIG CHECKSIG CHECKSIG ...
<luke-jr>
otoh, the possibility of recursive CHECKSIGs may change that :x
<luke-jr>
hrm
<gmaxwell>
I think the seperate limit can go away, but you can't stop counting. you need to compute a weight equivilent checksig count or whatnot.
<luke-jr>
gmaxwell: what need is there to count, if you don't limit it?
<luke-jr>
or you mean add it to the weight? (effectively decreasing block sizes?)
<gmaxwell>
It's not reasonable to ignore it completely, weight is not sufficient if you can just do the example I just gave, where each operation costs 2 weight.
<luke-jr>
hmm
<gmaxwell>
weight needs to only be one dimensional linear on a whole block basis, within a single transaction you can do things like:
<luke-jr>
I suspect counting at execution will be painful. :<
<gmaxwell>
so that ordinary transactions work like now, but sigops abusers get a higher effective weight.
<gmaxwell>
It sure shouldn't be. The execution already has to be exactly specified for other reasons. e.g. you need to precisely specify which gets executed so you terminate on invalidity in a consensus consistent way.
jb55 has joined #bitcoin-wizards
<luke-jr>
well, I need to be absolutely sure the end count comes out the same as the static method
<sipa>
not if it's the only method
<luke-jr>
the current consensus rules use the static method
<sipa>
the current consensus rules don't apply to v1 scripts
<luke-jr>
right, I was thinking of refactoring sigops everywhere
<luke-jr>
I guess that's unnecessary
<gmaxwell>
The next question though is it better to do that non-linearity per transaction or per input. Per input would be better for reasoning about fees if inputs are independanly computed.
jb55 has quit [Ping timeout: 248 seconds]
dnaleor has quit [Quit: Leaving]
<maaku>
luke-jr: I think you shouldn't add anything new except for the prefixed script version in witness
<maaku>
the only other thing you should do is cut things out, like unnecessary limits
<maaku>
(which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
<maaku>
gmaxwell: 2DUP 2DUP ... CHECKSIG CHECKSIG ... doesn't do much thanks to the signature cache.
<gmaxwell>
then you've just made specific caching behavior consensus critcial... and there are similarly short sequences that can't be cached (or at least there are if the opcode set isn't absurdly limited)
<maaku>
it's not consensus critical, just critical to performance guarantees
rusty has joined #bitcoin-wizards
<gmaxwell>
it's consensus critical because if you don't implement it you will potentially verify slowly enough that you'll end up on a seperate chain in the presence of it.
<gmaxwell>
performance can be consensus critical, that fact that it doesn't form a black and white boundary doesn't make that not the case.
<maaku>
go benchmark secp256k1 and see how long it will take you to verify a block chock full of CHECKSIGs
<sipa>
around a minute, on reasonable hardware
<maaku>
sipa: and that's a single core, I presume, based on my own checks
<gmaxwell>
two million checksigs are about two minutes, on a fastish i7, verified sequentially.
<sipa>
maaku: no, quadcore
<gmaxwell>
and that is more than enough to split the network.
<maaku>
if that's not acceptable, then limit an input to no more than witness_size / 64 checksigs.
<maaku>
now you've reduced it to seconds
<gmaxwell>
Thats what it appears that you were arguing against above. :)
<maaku>
> 01:37 < maaku> (which sometimes means adding new things, making policy consensus or new per-input limits, to make that safe)
<maaku>
per-input, not per-block
<maaku>
it doesn't enter into transaction selection that way.
<gmaxwell>
maaku: you should read the backscroll.
<maaku>
I don
<maaku>
I don't see myself saying anything different
<gmaxwell>
You're repeating what I said above, before you started talking but it sounds like you're disagreeing.
<sipa>
luke-jr: i don't understand why a separate witness for code would be needed
<sipa>
luke-jr: bip114 does not need it
<sipa>
gmaxwell, maaku: this discussion is too meta for me to follow
<sipa>
please, repeat the statement you saw someone make you agree or disagree with - i think it would help everyone
Ylbam has quit [Quit: Connection closed for inactivity]
Dizzle has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 248 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
dabura667 has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
dnaleor has quit [Remote host closed the connection]
dnaleor has joined #bitcoin-wizards
jb55 has quit [Ping timeout: 260 seconds]
jb55 has joined #bitcoin-wizards
<maaku>
I'm not sure. I don't think it's relevant. I think we should drop limits where we can and where the worst you can do with them is comparable to what can be accomplished by other means.
<maaku>
That means ideally just the size/weight limit, and everything else is naturally limited because we've eliminated anything with greater than linear cost, and the max block weight is picked from the worst thing you can do, extrapolated to fill the block.
<maaku>
In this case that means making signature caches a requirement for low latency validation, and maybe some other tweaks, or if that can't be accomplished then have a per-input limit instead of a global one, so transaction selection still deals with a linear metric.
<maaku>
Obviously we can't change existing global limits, but at least don't make it worse by continuing to count towards them in new-style scripts.
<sipa>
thanks, now i understand what you're talking about :)
c0rw1n_ has quit [Quit: Leaving]
c0rw1n_ has joined #bitcoin-wizards
dnaleor has quit [Remote host closed the connection]
<luke-jr>
I'm liking the idea of requiring all executable stuff be directly in the witness stack, and having a tag at the start of each element for number of times executed..
<luke-jr>
does that work for all use cases?
<luke-jr>
(this preserves static analysis)
<sipa>
why would the number of times executed be above 1?
<gmaxwell>
maaku: but then you end up with patterns like DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR DUP2 DUP HASH160 XOR... CHECKSIG CHECKSIG CHECKSIG being phenominal blowups it worst case cost.
<luke-jr>
sipa: using the same condition script for multiple signatures, for example
<sipa>
luke-jr: it's either valid or not, no need to evaluate it more than once
<gmaxwell>
e.g. that has checksig costs about 20 times higher per weight than sane usage, which effectively translates into limits that need to be lower (perhaps under some arguments 20x lower)
<sipa>
luke-jr: i haven't read about the condition script - it sounds a bit like signature delegatio
<luke-jr>
sipa: hm, that might be worth giving up the stack copy to guarantee..
<sipa>
stack copy?
<luke-jr>
sipa: yes, the signature is currently appended with a script, which is executed with a copy of the current stack
dnaleor has joined #bitcoin-wizards
<sipa>
luke-jr: giving it a separate stack sounds safer
<luke-jr>
I haven't thought through if there are any use cases for the stack copy
<sipa>
or rather, a separate initial stack
<luke-jr>
but separate stack and cache the answer sounds like a good idea
<luke-jr>
right
<luke-jr>
especially since the condition scripts are most likely to be used for things like CHECKBLOCKATHEIGHT, which are likely to be reused for all sigs
<sipa>
it sounds a bit premature to include that in a proposal right now, though
<luke-jr>
it's a pretty annoying thing to have missing in Segwit IMO
<gmaxwell>
ugh, please. don't propose things inside script that aren't pure functions of the transactions; thats recreating the ethereum non-scalablity disaster.
<luke-jr>
gmaxwell: ?
<gmaxwell>
that was a comment to CHECKBLOCKATHEIGHT
<luke-jr>
we don't have any place to put it outside script..?
<gmaxwell>
if the validity of a transactions scripts aren't a pure function of the transaction you must reevaluate the scripts every time something changes that could invalidate them, which means you either need tracing execution that extracts the invarients, or no caching at all or...
<luke-jr>
or cache the additional condition
<gmaxwell>
So? Life is hard. The fact that it's currently the only way you have to do it doesn't makes it acceptable.
<gmaxwell>
Script's purity is a long standing design invarient that we reconized as important, a view which has only been confirmed by the total mess in ethereum.
jb55 has quit [Ping timeout: 240 seconds]
<luke-jr>
I don't see why this should be unacceptable. It's more or less the same thing as SigAgg?
<sipa>
sigagg validity only depends on the txn
<sipa>
not on the context in which it is evaluated
<luke-jr>
sipa: implement CHECKBLOCKATHEIGHT as "always NOP, but log a condition for the transaction to be valid"
<luke-jr>
this way, it's effectively the same as the locktime field
<gmaxwell>
(the other problem with CHECKBLOCKATHEIGHT is that it causes all outputs of the transaction to be non-equally fungible due to their destruction in reorg, so they need maturity like coinbases)
<luke-jr>
except you don't need to store it redundantly
<sipa>
luke-jr: right, so make it actual work like locktime, not as a script feature
<luke-jr>
sipa: that's insanely more complex, for negative value..
<luke-jr>
(now your transaction needs to specify the information twice, and it doesn't improve anything)
<sipa>
i don't understand
<sipa>
for example, allow a particular witness stack element to encode an extra condition
<sipa>
which does not require scriot execution to detect
<sipa>
and signatures automatically commit to it
<sipa>
as if it were part of the txin
<luke-jr>
and then in the script, you still need a CLTV-equivalent with a copy of the data, to make sure it's in there..?
<luke-jr>
hmm, I guess that's redundant with the CHECKSIG
<luke-jr>
provided there is a CHECKSIG in the first place (but condition scripts don't help if there aren't anyway)
<luke-jr>
ok, so how would you detect the particular witness stack element? add a type prefix to every element? :/
<sipa>
fair, but transactions with no checksigs at all are pointless anyway
<sipa>
luke-jr: let the bikeshedding begin :)
<luke-jr>
:<
<luke-jr>
while a possible option, I don't really see how this is *better* than a CLTV-like opcode that implies the locktime on the tx rather than requires a separate commitment. It just adds complexity, but the net result is essentially identical.
Chris_Stewart_5 has joined #bitcoin-wizards
<luke-jr>
I suppose it comes down to the static analysis thing again
<maaku>
sipa: a hypothetical 2-way SPV peg implemented in an expanded script would have no checksigs but be useful
<maaku>
also there's NONE|ANYONECANPAY
<luke-jr>
maaku: in that hypothetical, I'm not sure there is a use case for replay protection
<sipa>
luke-jr: it isn't. if the context is visible.to svript execution, you need to invoke the script validation essentially after every block for your whole mempool, for example
<sipa>
things that are recognizable external to scripts can be dealt with directly
<sipa>
luke-jr: for example, in CLTV, we can just reevaluate the locktimes when a reorg occurs... we know the script validity can't ever change
<luke-jr>
sipa: no, because the outcome of CHECKBLOCKATHEIGHT (hypothetical, ignore the BIP for now) would be NOP *always*; there is a side effect of copying the expected block hash and height to a transaction variable, which is the same for all executions of that script; the transaction validity depends on compatibility of the context and that variable
<luke-jr>
it's the same as runtime counting of sigops
<sipa>
define 'transaction variable' ?
<sipa>
ah, i see - some tx-wide result of script execution
<luke-jr>
sipa: we could store it on CTxMemPoolEntry, or even CTransaction (but never serialise it)
<luke-jr>
right
<sipa>
i think that's ugly - just make the outcome of that variable directly something part of the transaction
pro has quit [Quit: Leaving]
<sipa>
why make it be the outcome of script validation?
<sipa>
it's semantically the same, but the construction is easier
<luke-jr>
simpler and less ugly :x
<luke-jr>
also programmable
<luke-jr>
eg, this way a script can commit upfront to specific heights
<sipa>
right
dnaleor has quit [Quit: Leaving]
<sipa>
you effectively have the script has output true/false, plus a list of additional validity criteria
<sipa>
but the evaluation itself is context independent, it's just the produced criteria that may be context-dependent and need re-evaluation
<luke-jr>
right, and in this case, the end output can be collapsed for all the inputs
<luke-jr>
(select the lattermost height)\
<luke-jr>
well, assuming the inputs don't contradict each other.. maybe not so simple to optimise there
<gmaxwell>
among other things now you need to execute scripts fully to even know if the result is valid with your current context.
<gmaxwell>
you cannot ban a peer for having a different context than you...
<luke-jr>
hmm, true
<gmaxwell>
and you also now have some output property (outputs that need maturity) depending on script execution.
<luke-jr>
ugh
<luke-jr>
if only the witness data was a map.. XD
<luke-jr>
I suppose we could serialize the entire initial-stack for witnessv1.. although that feels ugly, it's probably less ugly than tagging every single stack item?
<luke-jr>
(going back to sipa's idea of a witness-data field)
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<maaku>
luke-jr: you might consider expanding the CHECKBLOCKATHEIGHT bip. it's not obvious to me what use cases it enables that are both interesting and not easily accomplished by other means
<luke-jr>
maaku: not sure what there is to say besides the Motivation section.. :/
<luke-jr>
you're looking at the BIP 115, right?
carman^^ has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
dnaleor has quit [Remote host closed the connection]
chjj has quit [Ping timeout: 248 seconds]
chjj has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
carman^^ has quit [Quit: Page closed]
Emcy has quit [Ping timeout: 258 seconds]
Emcy has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
<CryptAxe>
It seems like the relay protection that OP_CHECKBLOCKATHEIGHT would provide couldn't be done in any other way, so there's that
<CryptAxe>
Also didn't see what time you guys were disussing this but maybe you'll still see that
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
TheSeven has quit [Ping timeout: 246 seconds]
jb55 has quit [Ping timeout: 240 seconds]
TheSeven has joined #bitcoin-wizards
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jb55 has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 258 seconds]
[7] has joined #bitcoin-wizards
Dizzle has quit [Remote host closed the connection]
Dizzle has joined #bitcoin-wizards
chjj has quit [Ping timeout: 248 seconds]
CubicEarth has quit []
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
Dizzle_ has joined #bitcoin-wizards
Dizzle has quit [Disconnected by services]
Dizzle_ is now known as Dizzle
intcat has quit [Remote host closed the connection]
<maaku>
CryptAxe: there are a great many other ways that replay protection can be provided
<maaku>
luke-jr: I was looking at an earlier version in your repo it seems. the one in the bips repo is more clear
<maaku>
But the first motivating feature, "Securely recovering from double spends" seems like a NASA space pen vs Russian pencil situation. We have a mechanism for resolving double-spends. If you want to make sure that one transaction is dependent on another transaction going through, including an output linking the two.
BashCo_ has quit [Remote host closed the connection]
<maaku>
The second motivating feature is not very motivating. Purposeful chain splits should have built-in replay protection, by changing the signature hash, for example, and we should be advocating for a standard approach to that (in as much as we should be advocating for anything regarding chain splits)
<maaku>
pinning specific block heights has the disadvantage of not being something you can do until after the split, whereas most people are interested in preparing for the split -- signing time-locked transactions valid on one but not the other. And if you constrain yourself to only being able to sign post-split, then there's already an existing technique that requires no consensus code changes -- using
<maaku>
post-split coinbase outputs or their descendents
<CryptAxe>
maaku agreed, but I'm not familiar with any method that wouldn't require a soft fork of some kind. So an opcode that could handle replay protection, and provide other features seems interesting
deusexbeer has quit [Ping timeout: 240 seconds]
deusexbeer has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
rusty1 has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
meshcollider has quit [Quit: Connection closed for inactivity]
Guyver2 has joined #bitcoin-wizards
rusty1 has quit [Ping timeout: 264 seconds]
daszorz has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
Dizzle has quit [Remote host closed the connection]
<uiuc-slack1>
<amiller> Non-interactive proofs of proof-of-work
jtimon has quit [Ping timeout: 258 seconds]
<kanzure>
win3
<kanzure>
aaaaaa
pro has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
bsm117532 has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
dnaleor has quit [Remote host closed the connection]
daszorz has quit [Read error: Connection reset by peer]
Murch has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 248 seconds]
Aranjedeath has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
BashCo has quit [Remote host closed the connection]
dnaleor has joined #bitcoin-wizards
c0rw1n_ has quit [Ping timeout: 248 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
pro has quit [Quit: Leaving]
Chris_Stewart_5 has quit [Ping timeout: 246 seconds]
jb55 has quit [Ping timeout: 248 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
CheckDavid has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
bildramer1 has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 258 seconds]
abpa has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
abpa has quit [Ping timeout: 258 seconds]
abpa has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
<maaku>
amiller: thank you for continuing work on this
dnaleor has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
rusty has quit [Ping timeout: 248 seconds]
<maaku>
amiller: is there a code implementation to look at somewhere?
jb55 has quit [Quit: WeeChat 1.9]
<uiuc-slack1>
<amiller> we're working on it, we have some simulation code that should already be up, currently working on some demo integration of an ethereum verifier and bitcoin testnet as the sidechain
<maaku>
thanks. I'm not familiar with all the terminology in the paper and it helps to see the end result
dnaleor has joined #bitcoin-wizards
afk11 has quit [Ping timeout: 248 seconds]
Aaronvan_ has joined #bitcoin-wizards
afk11 has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 264 seconds]
laurentmt has joined #bitcoin-wizards
Aaronvan_ has quit [Ping timeout: 248 seconds]
dnaleor has quit [Ping timeout: 248 seconds]
<Chris_Stewart_5>
amiller: look forward to reading!
afk11 has quit [Ping timeout: 248 seconds]
dnaleor has joined #bitcoin-wizards
abpa has quit [Ping timeout: 258 seconds]
Aranjedeath has quit [Ping timeout: 248 seconds]
<maaku>
clear as mud.
<maaku>
amiller: the diagrams in the paper show regularly spaced skip links, but this should be probabilistic, right?
<uiuc-slack1>
<amiller> yes they're probabilistic, the diagrams just show an average case
<maaku>
layer 2 points back to the last 2x (but not >=4x) lucky block, which is not necessarily every other block
<maaku>
ok gotcha
<maaku>
wait actully was what I said correct? would a layer 2 point to, say, a 8x lucky block if that was the most recent >2x block?
<maaku>
or rather does that matter?
<maaku>
section 3.2 isn't clear on that
afk11 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
<maaku>
amiller: If I am reading section 5 correctly, it is possible for an attacker with <50% hashpower starting from a superblock to create a chain from which a succinct proof can be extracted that is "more work" than the honest chain
<maaku>
with >50% probability.
<maaku>
it would be very interesting to have numbers for what minimum hash power is required for these attacks to be reasonable
rusty has quit [Ping timeout: 240 seconds]
abpa has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
AaronvanW has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
Aranjedeath has joined #bitcoin-wizards
dionyziz has joined #bitcoin-wizards
meshcollider has joined #bitcoin-wizards
<dionyziz>
maaku: You're reading section 5 right. But the proof has very loose bounds, because the aim was just to show that the probability is non-negligible.
<dionyziz>
The attack has been weakened to make the analysis easier.
<dionyziz>
e.g. the fixed constant r is really stupid from the adversary's point of view
<dionyziz>
Normally a clever adversary would try the supression attack and wait until either the honest parties get a block or the adversary gets two.
<dionyziz>
And then stop.
<dionyziz>
So the analysis works out with a fixed r, but it's not an ideal situation for the adversary.
<dionyziz>
I'd like to also get some estimates on the computational power required for the adversary to be able to make these attacks.
<dionyziz>
I think one way to do it is through running some monte carlo simulations (akin to kls-attack/simulate.cpp)
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
<CryptAxe>
maaku it seems that the bitcoin cash replay protection has to be built in to the fork that we don't want our transactions replayed on?
AaronvanW has quit [Ping timeout: 248 seconds]
<sipa>
CryptAxe: any sane fork would do that
<CryptAxe>
Yeah, I wouldn't expect them to be sane though.
<CryptAxe>
Luke's seems to work for any fork regardless of sanity, or maybe I'm confused
<CryptAxe>
bip 115
<sipa>
right, it would require pretty crazy trickery to subvert it
<sipa>
but it's not impossible
<CryptAxe>
To me it seems a lot better for Bitcoin to have replay protection, than to expect forks to be nice to us.
<CryptAxe>
Already I think you can see that people aren't interested in playing nice
abpa has quit [Ping timeout: 240 seconds]
<CryptAxe>
So 115 seems like a good idea to me, the bitcoin cash method also works of course but I wouldn't want to rely on them doing anything
<sipa>
CryptAxe: bitcoin has very good replay protection; it's what it's designed to solve (double spending)
<sipa>
forking without changing the genesis block or validity rules is intentionally subverting that protection
<sipa>
anf if that is the goal, anything can be subverted in a hard fork
<sipa>
it can only be made harder
<sipa>
for starters, they can choose to just not implement the checkblockhash opcode... resulting in at best one-way protection
<esotericnonsense>
i can't see that it is possible to implement two-way replay protection without cooperation.
<CryptAxe>
That's a good point, one way protection does seem to be all that Bitcoin can do
<esotericnonsense>
if you had a magical box that would allow you to scrap ECDSA tomorrow and started using a different signature scheme entirely, the other fork can just copy it and allow those transactions.
<CryptAxe>
So I guess it can't actually be solved completely in the way I'm thinking
<esotericnonsense>
if you have a magic p2sh box the other fork can decide to hardcode it in, etc.
<CryptAxe>
yeah... :\ darn
<CryptAxe>
I guess it doesn't really matter what some weird fork wants to do
<CryptAxe>
anyone can make an altcoin at any time
<esotericnonsense>
consider the simplest, most ridiculous hard fork case, which just hardcodes in a single invalid block
<CryptAxe>
"some mechanism is desired by which the UTXOs valid in either chain may be spent without the transaction being validly replayable on the other chain." I guess that isn't possible either, given that the other chain determines what is valid to themselves
<esotericnonsense>
yes, that's the key
dnaleor has quit [Quit: Leaving]
<maaku>
CryptAxe: you can't protect against another chain choosing to treat bitcoin transactions as valid.
<CryptAxe>
maaku I understand your criticism now, agreed
koshii has quit [Ping timeout: 240 seconds]
wraithm has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andytoshi>
"replay protection" is something of a misnomer, what's really under consideration is whether the alternate system should require users produce and publish unrelated valid bitcoin transactions
<andytoshi>
this will obviously cause confusion and loss of funds, but unfortunately it's also obviously impossible for bitcoin to prevent other software from working this way
afk11 has quit [Ping timeout: 248 seconds]
<gmaxwell>
you cannot prevent someone from building a system which maliciously allows updates for another system to effect it and vice versa, unfortunately. (except by keeping your system secret).
<CryptAxe>
"keeping your system secret" ahh the nxt approach
<CryptAxe>
security via hiding behind curtains
dnaleor has joined #bitcoin-wizards
koshii has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
afk11 has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
smk has quit [Ping timeout: 260 seconds]
abpa has quit [Read error: Connection reset by peer]
dnaleor has quit [Quit: Leaving]
rusty has joined #bitcoin-wizards
afk11 has quit [Ping timeout: 248 seconds]
afk11 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
CheckDavid has quit [Quit: Connection closed for inactivity]