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
thrmo has joined #bitcoin-wizards
afk11_ has joined #bitcoin-wizards
cluckj has joined #bitcoin-wizards
thrmo has quit [Ping timeout: 260 seconds]
WungFu has quit [Remote host closed the connection]
afk11_ has quit [Ping timeout: 260 seconds]
JackH has quit [Ping timeout: 240 seconds]
JackH has joined #bitcoin-wizards
espes__ has quit [Ping timeout: 255 seconds]
espes__ has joined #bitcoin-wizards
JackH has quit [Ping timeout: 240 seconds]
rusty has quit [Ping timeout: 240 seconds]
JackH has joined #bitcoin-wizards
chjj has quit [Ping timeout: 256 seconds]
chjj has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
str4d has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
lmatteis has quit [Quit: Connection closed for inactivity]
kankles has quit [Ping timeout: 246 seconds]
Giszmo has quit [Ping timeout: 240 seconds]
dodomojo has joined #bitcoin-wizards
dodomojo has quit [Remote host closed the connection]
kankles has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
dodomojo has joined #bitcoin-wizards
dodomojo has quit [Read error: Connection reset by peer]
dodomojo has joined #bitcoin-wizards
dodomojo_ has joined #bitcoin-wizards
dodomojo has quit [Ping timeout: 246 seconds]
dodomojo_ has quit [Remote host closed the connection]
rusty has quit [Ping timeout: 240 seconds]
NewLiberty has joined #bitcoin-wizards
pro has quit [Quit: Leaving]
_whitelogger has joined #bitcoin-wizards
mryandao has quit [Quit: do not disturb. look busy...]
mryandao has joined #bitcoin-wizards
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
TheSeven has quit [Disconnected by services]
[7] has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 260 seconds]
pero has joined #bitcoin-wizards
qpm has joined #bitcoin-wizards
saintromuald has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
str4d has quit [Quit: Leaving]
pero has left #bitcoin-wizards ["Leaving"]
wasi has quit [Remote host closed the connection]
wasi has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
BashCo has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 246 seconds]
Kexkey has quit [Ping timeout: 268 seconds]
BashCo has joined #bitcoin-wizards
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
nu11p7r has quit [Ping timeout: 258 seconds]
nu11p7r has joined #bitcoin-wizards
espes__ has quit [Ping timeout: 240 seconds]
huseby has quit [Ping timeout: 260 seconds]
lmatteis has joined #bitcoin-wizards
espes__ has joined #bitcoin-wizards
huseby has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 256 seconds]
jannes has joined #bitcoin-wizards
edvorg has joined #bitcoin-wizards
leakypat has joined #bitcoin-wizards
leakypat has quit [Client Quit]
Gk-1wm-su has joined #bitcoin-wizards
Gk-1wm-su has left #bitcoin-wizards [#bitcoin-wizards]
Gk-1wm-su has joined #bitcoin-wizards
Gk-1wm-su has left #bitcoin-wizards [#bitcoin-wizards]
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
arubi has quit [Ping timeout: 240 seconds]
nanotube has quit [Ping timeout: 258 seconds]
Marquess_Loaf has quit [Quit: Connection closed for inactivity]
nanotube has joined #bitcoin-wizards
AaronvanW has quit []
jcorgan has quit [Quit: ZNC - 1.6.0 - http://znc.in]
jcorgan has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 260 seconds]
Kexkey_ has joined #bitcoin-wizards
<stevenroose>
Q: what happened to good old SIGHASH_NOINPUT? I agree that segwit is infinitely better a malleability fix, but the slight tx throughput increase that comes with it turns out to be quite controversial. As is the complexity.
<stevenroose>
Having a softfork for a simple SIGHASH_NOINPUT might be a lot less controversial. And they would allow Lightning to be deployed on mainnet, right?
<othe>
i wouldn't call sth controversial that has been looked at for years or months, feels more like a narrow minded people issue than a technical issue
ninjahamstah has joined #bitcoin-wizards
NewLiberty_ has joined #bitcoin-wizards
<stevenroose>
othe, well yeah, it's both. technical complexity is not only the chance of introducing bugs, but also the fact that you are increasing the technical depth is total. Even though, I'm totally in favor of SW, I do think that it makes sense to favor solutions that make the protocol as whole as little more complex as possible.
binaryatrocity_ has quit [Remote host closed the connection]
binaryatrocity has joined #bitcoin-wizards
binaryatrocity has joined #bitcoin-wizards
binaryatrocity has quit [Changing host]
binaryatrocity has quit [Remote host closed the connection]
binaryatrocity has joined #bitcoin-wizards
binaryatrocity has joined #bitcoin-wizards
binaryatrocity has quit [Changing host]
binaryatrocity has quit [Remote host closed the connection]
JackH has quit [Ping timeout: 240 seconds]
q4 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
JackH has joined #bitcoin-wizards
NikopolSohru has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
JackH has quit [Ping timeout: 240 seconds]
<bsm117532>
I see a number of people discussing how a UASF could result in a hard fork. I don't see how this is the case, can someone explain? Since it's a soft fork, both old and new style blocks from miners are valid and can make one chain.
<bsm117532>
If only half the hashpower is mining segwit then segwit transactions would take twice as long to get mined, but I don't see any way this could result in a chain split.
<kanzure>
they mean if someone maliciously mines an invalid block, *and* hashrate mines on top of that block
<bsm117532>
A non-upgraded miner will only miss out on segwit txn fees. But to create a fork he'd have to write code to actively detect segwit blocks and not mine on top of them. That would be dumb.
<bsm117532>
kanzure: Why in the world would someone do that? That's a standard hashpower hard fork.
<kanzure>
no idea :)
<bsm117532>
(since a non-upgraded miner won't be able to detect segwit blocks without extra work)
<bsm117532>
So the opposition to UASF from Ver/Wu is that "some miner might do something really dumb that has nothing to do with UASF or the specific soft fork in question"?
JackH has joined #bitcoin-wizards
bityogi has joined #bitcoin-wizards
<kanzure>
this is increasingly not a -wizard topic
<bsm117532>
Well, whether UASF does/not result in a hard fork certainly is...
<stevenroose>
I really don't get UASF. Reading the BIP it seems to make no sense at all, so I just considered it irrelevant.
<stevenroose>
Why would you have the whole bip9 soft fork activation mechanism based on mining if you just specify a date when it will be activated anyway.
<stevenroose>
That's all UASF does (according to BIP): specify a date at which the SF is activated regardless of any support indicator.
<stevenroose>
I don't see how it is "user-defined" at all rather than developer-defined.
mdavid613 has joined #bitcoin-wizards
<riclas>
if users don't upgrade, they don't indicate support.
<bsm117532>
It's user defined if there exist users who submit the new-style transactions, and miners who decide to mine them.
<stevenroose>
Yeah so where is it different from a hard fork?
<stevenroose>
With BIP9 soft forks, you can safely upgrade your software because you know your client will only enable the SF when 95% of the miners will accept your txs
<stevenroose>
It's basically a "resort to hard fork after this deadline"
<bsm117532>
UASF is soft because both old and new style blocks are valid to old nodes, and can be mined by old nodes. It's not a hard fork at all, and can't result in a chain split AFAICT...
NewLiberty_ has quit [Read error: Connection reset by peer]
q4 has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
BashCo has quit [Remote host closed the connection]
NewLiberty has quit [Read error: Connection reset by peer]
BashCo has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 246 seconds]
NewLiberty has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
arubi has joined #bitcoin-wizards
nkhl has joined #bitcoin-wizards
NewLiberty_ has joined #bitcoin-wizards
cluckj has quit [Quit: Leaving]
NewLiberty has quit [Ping timeout: 240 seconds]
kaalikahn has quit [Ping timeout: 240 seconds]
kaalikahn has joined #bitcoin-wizards
nkhl has quit [Quit: Leaving]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
nkhl has joined #bitcoin-wizards
nkhl has quit [Remote host closed the connection]
nkhl has joined #bitcoin-wizards
<gmaxwell>
bsm117532: you're hearing people who are confused about the definition of a hardfork. I've encountered it many times... (usually when they go and say "segwit is a hardfork!") and other such stuff. The confused definition they have seemed to be using is "a hardfork is anything which could cause rejection of a block".
nkhl has quit [Remote host closed the connection]
nkhl has joined #bitcoin-wizards
<bsm117532>
gmaxwell: Ok, thanks for confirming that for me.
n1ce has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
n1ce has joined #bitcoin-wizards
comboy has quit [Ping timeout: 240 seconds]
comboy has joined #bitcoin-wizards
nkhl has quit [Ping timeout: 260 seconds]
NewLiberty_ has quit [Ping timeout: 246 seconds]
<bsm117532>
It might be interesting if a UASF was preceded by a window of time where the new-style transactions could be accepted into the mempool, but not mined. Thus miners would have a growing pool of txn fees they know they can claim on "flag day", and make the economically rational decision to mine them.
<stevenroose>
bsm117532, like greg says, it's a HF because it can cause a split. bip9 ensures 5% of less people on the old chain, which is rather minor. when the fractions are more or less equal, there will be a chain split, since old nodes can make transactions that are refused by the new ones. in case of segwit, f.e., old nodes can spend all segwit transactions as if they were anyone can spend txs, so new clients will fork off the old guys
<bsm117532>
stevenroose: that's opposite to what greg says. It's not a HF.
<bsm117532>
There are not two chains. There is one.
<bsm117532>
Old nodes cannot make transactions that are refused by new ones.
<bsm117532>
Oh I see...someone could try to claim segwit outputs as anyone-can-spend. Yes that would create a fork...
MaxSan has joined #bitcoin-wizards
<gmaxwell>
stevenroose: that is an incorrect definition of a hardfork.
<kanzure>
bsm117532: those are nonstandard transactions and will not get mined.
<gmaxwell>
bsm117532: segwit redemptions are non-standard under the old rules.
<stevenroose>
well, it's a chain split
<stevenroose>
gmaxwell, does consensus reject non-standard txs?
<bsm117532>
gmaxwell: nice. So then a chain split is impossible here...
<gmaxwell>
stevenroose: Yes, though one that would require specific intent to create... which anyone can do at any time. It is emphatically not a hardfork: it's compatible with existing nodes. We do ourselves no favors to swizzle all words to incomprehensibility.
<gmaxwell>
bsm117532: you mean a 'pure chance' split or similar I assume.
<kanzure>
consensus rejects invalid transactions. the nonstandardness is re: what miners mine by default.
ninjahamstah has quit []
<bsm117532>
gmaxwell: Yes. Absent an intentional act to create an invalid block by modifying the code, a chain split will not happen regarless of which version of core anyone is running. (AFAICT)
<kanzure>
you can mine a nonstandard-yet-valid transaction. in this instance we are talking about nonstandard and invalid. hence you would require intent.
<stevenroose>
kanzure gmaxwell, if I would mine a block with a non-standard tx, would it be rejected?
<kanzure>
is the non-standard transaction also invalid?
<stevenroose>
I guess it's not
<stevenroose>
imagine a tx that still threats the segwit opcode as a no_op?
<gmaxwell>
then no, ugh come on please. Take some time to actually understand these things?
<stevenroose>
bsm117532, you can't assume everyone is running Core
<bsm117532>
gmaxwell: what about the txn makes a segwit redemption (treated as anyone-can-spend) nonstandard and invalid?
<arubi>
why would redeeming a segwit script be invalid at any point (before or after a soft fork)? it's just <push> <push> from a non soft forked node's point of view?
<gmaxwell>
I regret to inform you that your use of 'anyone-can-spend' may be an indicator of brain cancern. "Anyone-can-spend" does not exist as a thing anywhere in the protocol, it's an informalism to refer to consenus unconstrained scriptpubkeys that somehow clueless people have mistaken as a protocol feature.
<gmaxwell>
bsm117532: In the protocol we have three main 'areas' reserved for forward extensions: Transaction version, use of nops, and the CLEANSTACK rule. So long as any future extension is invalid under one of these constraints it will be non-standard to older nodes. Segwit spends violate the third.
<gmaxwell>
Prior to the existane of CLEANSTACK there was an even more restrictive set of conditions that would have rejected segwit txn due to not matching a small set of templates.
<bsm117532>
gmaxwell: that's true for both P2WSH and P2WPKH?
<gmaxwell>
bsm117532: s/core // in your earlier message-- also "regardless of version" isn't strictly necessary, since there are older versions which would mine other no longer valid transactions, so compatiblity there only needs to exist with versions past that.
<gmaxwell>
bsm117532: yes, they look the same to older nodes. It's also true for the P2SH embeddings.
<gmaxwell>
e.g. there are versions prior to uh... 0.3.mumble that don't have the non-standardness restrictions... but you can't mine on them now anyways, even if you somehow got them in sync with the network.
<shesek>
I made a time-locked-weighted (via CSV) voting system this past weekend for a hackathon, would love to hear what you think :)
<bsm117532>
gmaxwell: thanks, I didn't know about the CLEANSTACK rule. I'll likely blag about UASF once certain restrictions are lifted by my company...
<gmaxwell>
shesek: do you have a theory that the locking of the funds will discourage third party custodians from inappropriately using their customer funds?