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
indolering has quit []
ajbiz11 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
AaronvanW has quit [Remote host closed the connection]
DougieBot5000_ is now known as DougieBot5000
ccdle12 has joined #bitcoin-wizards
ruby32 has joined #bitcoin-wizards
ruby32 has quit [Remote host closed the connection]
<jeremyrubin>
Rather than leaking the key directly, you can sign a txn which agrees to burn it/release to fee with the old UTXO
musalbas has joined #bitcoin-wizards
<jeremyrubin>
I think this form of pinning is a little bit better than what you're describing
<gmaxwell>
you seem to be just ignoring that it's a private cost for a diffuse public benefit?-- so everyone is incentivized to defect...
<jeremyrubin>
I'm not ignoring, I'm just making sure we're on the same page with how you might do it
AaronvanW has quit [Ping timeout: 246 seconds]
<jeremyrubin>
I think that the private cost is small
<jeremyrubin>
And the benefit is large
<jeremyrubin>
If you are a company, and this is a standard business practice, it lets you wash hands of liability for dealing with forks after a N block re-org
<gmaxwell>
lol
<jeremyrubin>
it also should honestly signal that you won't accept a reorg predating your signing of that, which helps 'lock in' finality of transactions preceding that point
<gmaxwell>
that is the most absurd thing I've heard this week, and thats saying a lot since I read a bunch of rbtc. To strawman it just a little, thats like saying a business can wash their hands of liability for a robbery by rigging their building to self destruct if one happens.
<jeremyrubin>
Well I hope to keep on surprising you then
<jeremyrubin>
It's a commitment to hard fork
<jeremyrubin>
because you're basically saying that unwinding beyond that point is unthinkable for your business
<jeremyrubin>
and rather than just *state* it, you give an honest signal
<gmaxwell>
to whatever (probably limited) extent any such commitment would have value at all, you could obtain it simply by making it and following through.. not dorky boobytraps required.
<jeremyrubin>
No, the dorky boobytraps guarantee that you'll have no economics on the reorg chain
<jeremyrubin>
so your switching cost would be much higher
<jeremyrubin>
rather than getting coins on both chains
Apocalyptic has joined #bitcoin-wizards
<jeremyrubin>
If you don't release the pinning txn, then you maintain your optionality
<gmaxwell>
Yes, I understand that. But this has nothing to do with your liability for mismanging customer funds. "Sorry, you can't blame me that I sprained your dogs leg. Our policy is to incenerate all pets where the surgery goes poorly, thus guarenteeing that the dog will only live on in your memory as a happy, healthy, animal."
<jeremyrubin>
Let's not use whimsical analogies
* jeremyrubin
remind me to not let greg near my dog
<jeremyrubin>
The idea is that you've effectively staked your operations on a specific chain history. This allows others to coordinate, knowing how much value has staked at a reorg height
<jeremyrubin>
In terms of limiting liability, IANAL but I can ask one and let you know what they say
<gmaxwell>
as an aside, your revised idea doesn't work at all on technical grounds regardless.
<gmaxwell>
because the reorg can just prohibit those transactions. (though I think this is not an interesting comment, because the whole idea is profoundly confused, but it's hard to resist pointing out a simple technical fault)
<jeremyrubin>
Well, prohibiting those txns is hard
<jeremyrubin>
But pinning the reorg to include those txns in the reorg sounds like a good outcome!
<jeremyrubin>
Either include my TXN as is, not at all, or burn it
<jeremyrubin>
I suppose technically they could accept any restrictions
<jeremyrubin>
and allow double spends only
<jeremyrubin>
I am unsure if a reorg can coordinate that much though
<gmaxwell>
how is it "hard" to ignore transactions when already you are assuming that miners are violating honest consensus by ignoring the most work chain?
<gmaxwell>
unrelated, the fact that your interaction with binance is being promoted by binanace and the media as "Bitcoin core developers" advised them to do that nonsense, has strongly disinclined me from ever working with you again.
<gmaxwell>
And I am almost certantly not alone in this.
<jeremyrubin>
I have no control over that media narrative
<jeremyrubin>
I didn't represent myself to them at any time as
<jeremyrubin>
hi I'm here from the bitcoin core to do this
<gmaxwell>
Sure you do, your twitter profile prominently states "Bitcoin Core" -- this isn't somethign that even sipa does.
<gmaxwell>
All the stellar materials talking about you describe you as "bitcoin core developer"
<gmaxwell>
Certantly _binance_ paid attention to it because they believed they were getting advice from "bitcoin core"
<jeremyrubin>
How do you suppose I tell people that I have previously worked on bitcoin software development and actively follow activity in the repository?
ccdle12 has quit [Remote host closed the connection]
<gmaxwell>
I don't claim to have all the answers. But strangely this problem never seems to arise for sipa; where on account of something he said companies are announcing they are considering trying to undermine the honest operation of the system at the advice of bitcoin developers.
<jeremyrubin>
Bitcoin.org lists me as a Bitcoin Core COntributor
<jeremyrubin>
maybe you should get that taken down (I don't know who runs it)
<jeremyrubin>
Maybe if I were a founder of blockstream they'd list that instead?
<gmaxwell>
I guess the advice I'd give is that if you want to stay in good standing with others, you may have to do some legwork to combat that sort of misunderstanding, and to smooth irritation in the community when people feel they've suffered on account of it.
<jeremyrubin>
also pieter's bio used to be "@pwuille. Bitcoin developer. Blockstream co-founder. Puny person. Mountain View, CA "
<jeremyrubin>
I somehow missed the memo that we shouldn't say we work on bitcoin
<gmaxwell>
It would be more accurate and better for you to say "Bitcoin developer"!
<jeremyrubin>
I thought Bitcoin Core Contrib (which is what is in my bio and what I usually say) is most accurate
<gmaxwell>
Be socially aware enough to know when you're being listened to because someone is talking to you because they think you're speaking as an authority... and defuse misunderstandings.
jimmysong_ has joined #bitcoin-wizards
jimmysong has quit [Ping timeout: 255 seconds]
<jeremyrubin>
I dunno, I seem to recall similar sort of position-signalling around UASF from certain quantities
<jeremyrubin>
So I'm just not certain how much i can actually effectuate change on that
<jeremyrubin>
but as a show of good faith, I'll ammend my twitter bio
<gmaxwell>
Thanks! I mean, no one can ask you to do more than make an earnest effort, same as anyone else.
<gmaxwell>
and that goes all around, if you think other people's words are being stuck in your mouth and it makes you uncomfortable, speak up.
<gmaxwell>
To some extent your suffer from bad expirences I've had with other people, that isn't your fault. :)
<jeremyrubin>
Yeah, I hope you (and others) no that at no point do I *ever* in conversation speak on behalf of core developers
<jeremyrubin>
I always disambiguate if people say core team
<gmaxwell>
it's not at all easy, people really want to deal with authorities and it breaks their brains when there isn't one readily available.
<jeremyrubin>
in talking with CZ, he didn't seem to have any pretenses that he was speaking with me (and other bitcoin-adjacent developers) as an individual
<jeremyrubin>
^^ Ooops I inverted that one
<gmaxwell>
understood
<jeremyrubin>
He didn't have any pretenses that I was there as an emissary of core
<gmaxwell>
I think thats actually unlikely, but I can see why you could have believed that.
<gmaxwell>
(and difficult to control other than with the hurestic that its very rare that a business leader that you don't know personally or have a relationship otherwise (e.g. as a contractor, customer, etc) is ever going to bother talking to you unless they think you're representing something they have an interest in. In some venues there are actions you can take to deformalize communication to avoid
<gmaxwell>
confusion but the limited bandwidth of twitter might not leave a lot of options for that)
<gmaxwell>
unfortunately this isn't changed by having a really good idea, since outside of engineering venues ideas are usually judged by who presents them, not by their merit. :) (and even in engineering venues, most of the time)
<jeremyrubin>
Well, to be fair by the time I talked with him directly it was in a telegram group with 10 other folks who had been chatting for a bit about the options
<jeremyrubin>
Including other engineering voices
<jeremyrubin>
Not sure what was said at that point
<gmaxwell>
Also to be clear: this is not at all a problem for just you. It's generally an unsolved thing in our industry. strangely it seems to be much worse for us than in other open projects I've been around, ... I am not sure why.
<jeremyrubin>
FWIW I'm fairly certain CZ did understand fairly well the incentives and optics. He was pretty dead-set on using it as a pure attrition with the attacker
<jeremyrubin>
I think part of the issue is just language imprecision; there aren't great terminologies
<gmaxwell>
not so sure about that, perhaps he had the same understanding as /you/. But the "decided not to do it" vs "decided it would be ineffective" suggests to me that there was not actually a strong understanding of the politics.
<gmaxwell>
If they'd attempted it, the reorg wouldn't have happened
<gmaxwell>
There is a lot of hashpower that would not participate at any price.
<gmaxwell>
(at least not after the first couple blocks)
<jeremyrubin>
Also reading thru the backlog, I specifically asked them to hop on IRC to chat with you specifically
<jeremyrubin>
not sure if anyone did
<gmaxwell>
and I know as soon as those tweets went up multiple users indpendantly wrote patches to pin the chain (I know because I had one code review request and another person asking me about it).
<gmaxwell>
Nah.
<gmaxwell>
(I told the users that the whole thing appeared to be silly, that I thought it wasn't going anywhere, and that I thought feeding the drama would be a poor idea. I don't think anyone posted any?-- but they would have if it went forward)
StopAndDecrypt has joined #bitcoin-wizards
StopAndDecrypt has quit [Client Quit]
StopAndDecrypt has joined #bitcoin-wizards
<gmaxwell>
On the plus side, this probably renewed interest in anti-fork-creation logic in miner firmware (like what BFGminer does).
<jeremyrubin>
Yeah I think 'decided not to do it' was not how I would have worded it. 'Decided not to attempt incentivizing' or something is better, but it's 280 char twitter
<gmaxwell>
yeah that would be fair.
<jeremyrubin>
But from what I can tell, binance team were well aware that most likely the attacker would counteroffer by releasing absurd fees
<gmaxwell>
the 'decided to no do it' is whats blowing a lot of people up, because it's read as implying that they could just push a button and do it.
<gmaxwell>
jeremyrubin: I don't know if you caught my comment but the attacker had a significant advantage, he could keep well over 1000 BTC and still significantly outbid binance, even ignoring the hashpower that wouldn't participate and the politics.
<gmaxwell>
because all the blocks already on the attacker side directly decrement what he has to pay in order to be paying more.
<jeremyrubin>
Yeah... I have a mixed feeling on that given that Coinbase and others are blacklisting the attacker's coins
<jeremyrubin>
Not sure how easy it will be to spend those coins
<gmaxwell>
lol well maybe they'll just get donated to BU like the kraken stolen coins. :P
<jeremyrubin>
lol
<gmaxwell>
There are a lot of strategies that attackers can use, though in the past we haven't seen them use them.
<gmaxwell>
Probably the electrum thefts will be interesting to watch for that.
<jeremyrubin>
I do still think that having software which handles these reorgs up to say 6 blocks would be interesting
<jeremyrubin>
It probably hurts bitcoin QoS, but would make custodians use more robust practices...
<jeremyrubin>
trial by fire
<gmaxwell>
I expect the next wave of mining firmware will refuse to self fork, largely taking the ability away from pools to do this.
<gmaxwell>
bfgminer has done it for years, but there wasn't much reason for people to bother implementing it.
<jeremyrubin>
huh... so the miner has some state?
<jeremyrubin>
But what happens if your block gets orphaned?
<gmaxwell>
Nothing, the new block you work on will have equal or greater work.
<gmaxwell>
The thing in bfgminer doesn't prevent reorging, it prevents reorging to a chain with less work from the same source.
<jeremyrubin>
Ah i see
<gmaxwell>
in a natural fork you're still always moving to a chain with more work.
<jeremyrubin>
This seems bad if you want to use a miner on mainnet then testnet
<luke-jr>
well, it prevents going back to a recent block
<gmaxwell>
nah, just needs to keep the two seperate.
<luke-jr>
it might not be sufficient for a deep reorg
<gmaxwell>
luke-jr: yea, it could be made stronger with explicit work tracking.
<luke-jr>
jeremyrubin: BFGMiner understands that there are multiple chains possible
<luke-jr>
jeremyrubin: since it supports GPU mining, I needed to have a way for it to switch between different algorithms even ;)
<jeremyrubin>
Hm. I think users would want to be able to switch between bcc and btc as well...
<luke-jr>
jeremyrubin: sure, it can do that too
<luke-jr>
point is it's aware of multiple chains
<gmaxwell>
no reason it couldn't. I believe the bfgminer code right now will just work for this.
<jeremyrubin>
so then how is it precluding reorgs?
<luke-jr>
and pools can even specify which chain they're using (which could be an issue, but it needs to be manually enabled by the user)
<luke-jr>
jeremyrubin: so long as a pool is assigned to a specific blockchain (the default), it can't go back to an older block
<gmaxwell>
jeremyrubin: because the way its currently implemented it only detects a reorg that goes back to a common block that its already moved past.
<luke-jr>
gmaxwell: his point, I think, was that the reorg could "appear" to be a new chain
<gmaxwell>
jeremyrubin: so it'll mine a fork once one exists, but it won't help create one. You start trying to create a fork, all those miners failover to another pool.
<jeremyrubin>
Where's this firmware sitting?
<jeremyrubin>
I thought you meant it's like on the boards
<gmaxwell>
jeremyrubin: this is the code that runs in the mining devices.
<gmaxwell>
(they run linux)
<luke-jr>
it's a software setting; I have no clue what various web interfaces do - I guess probably don't expose it
<jeremyrubin>
Ah ok
<jeremyrubin>
so people can just flash different firmware
<gmaxwell>
sure. or even just restart it, it doesn't persist this state.
<gmaxwell>
But now if you want to convince people to attack the stability of bitcoin, you don't just need to convince a half dozen pool operators, _also_ need to convince far more parties running mining farms.
<jeremyrubin>
gotcha. I'm groovy with that
<gmaxwell>
the same protection stops all sorts of ugly abuses, not just your "but I really ment well when I rounded up and gassed the blocks" anti theft reorg. :)
<gmaxwell>
so even if people are ambilivent to "get paid more to reorg" it's still worth running this protection.
<jeremyrubin>
Yeah. I don't like the idea of miners somehow low level firmware locked to mine most work chain
<jeremyrubin>
but a high level firmware to enforce a more rational mining setup sounds fine
<jeremyrubin>
If users want to participate in a reorg, they can use firmware which can calculate their payouts
<luke-jr>
well, it's only most-work, if you helped mine to that point ;)
<luke-jr>
ie, you can't reorg out your own blocks
<luke-jr>
[04:47:57] <jeremyrubin> If users want to participate in a reorg, they can use firmware which can calculate their payouts <-- on that note, Core's policy to implement all economically preferrential policies *ought* to include going along with these reorgs..
<luke-jr>
just saying ;)
<jeremyrubin>
I'm not sure exactly what you're expressing sentiment for happening
<gmaxwell>
luke-jr: you can't actually economically justify a reorg except with really exceptional logic in any case.
<luke-jr>
gmaxwell: if there's conflicted transactions outvaluing the subsidy of a new block..
<luke-jr>
(yes, this logic requires you to assume the remaining 50+% will also go along with it, but that's true of any policy)
<jeremyrubin>
luke-jr: I agree that it makes sense to implement the logic to act aggresively rationally with respect to reorgs
<gmaxwell>
luke-jr: it's not true of all polices though. e.g. taking the highest fee txn makes you money even if other miners use a different policy.
<jeremyrubin>
luke-jr: I would think having it be configurable to 6 blocks or something
<luke-jr>
gmaxwell: but the current policy *assumes* other miners *won't* be trying to reorg - if they are, you lose
<gmaxwell>
luke-jr: if they're trying to reorg you would lose regardless, creating your own new fork doesn't make you a winner.
<luke-jr>
jeremyrubin: I disagree with the economically-preferrential-only Core policy in general, just pointing out this would fit in it
<jeremyrubin>
luke-jr is right I think
<gmaxwell>
to get what you you're going for requires tracking and validating multiple tips. which regardless of other arguments isn't worth the risk/complexity/cost.
<jeremyrubin>
You don't want to build on top of something you think miners will abandon
<jeremyrubin>
Even if it is the most work
<luke-jr>
gmaxwell: sure, my point is that no matter what policy you implement, you have to assume other miners are using the same one; and this one could be it
<jeremyrubin>
gmaxwell: I think the logic can be handled as a policy on top of core, running multiple nodes
<gmaxwell>
luke-jr: you're missing my point. Even if other miners are creating a fork, creating your _own_ fork will not help you.
<jeremyrubin>
gmaxwell: they should gladly accept your block?
<luke-jr>
gmaxwell: it could very well coordinate the fork
<luke-jr>
jeremyrubin: yep, especially if they need it to make 50+$
<luke-jr>
%
<gmaxwell>
in any case, a reorg of 6 blocks would already be devistating to the network, many (most?) exchanges accept 3 blocks as final now.
<gmaxwell>
jeremyrubin: no, not if they have another fork of their own.
<jeremyrubin>
too many forks
<jeremyrubin>
So you mine on their fork
<jeremyrubin>
and they have another fork of it?
<luke-jr>
gmaxwell: they can adapt, just like everyone else has had to with big blocks
<gmaxwell>
yes, but doing that requires that you know it exists. The network doesn't relay it, you won't have fetched it or validated it even if it did.
<luke-jr>
gmaxwell: if Core implements it, everyone knows
<gmaxwell>
even single block reorgs have become very rare now, we're seeing less than one a month last I looked.
<gmaxwell>
luke-jr: yes, sure, but right now there is no reason to implement it.
<gmaxwell>
luke-jr: similar to not RBFing non-optin transactions.
<luke-jr>
gmaxwell: it fits into the enforced policies Core has been implementing for other parts
StopAndDecrypt has quit [Excess Flood]
<luke-jr>
hmm, I suppose the opt-out of RBF is a counter-example
StopAndDecrypt has joined #bitcoin-wizards
StopAndDecrypt has quit [Changing host]
StopAndDecrypt has joined #bitcoin-wizards
<jeremyrubin>
I think opt-out RBF should go away
<jeremyrubin>
makes it easier for hackers ;)
<luke-jr>
gmaxwell: I'm not suggesting we *should* do this, I'm trying to use it as an example that the pressure to only do economically-preferrential things in Core is a mistake
<gmaxwell>
luke-jr: I would agree with your "fits in" _if_ the practice already existed. Creating the practice where it doesn't exist doesn't fit in.
<luke-jr>
it does exist; hence the removal of blockmaxsize, coin-age priority, etc
<gmaxwell>
also it would be extradonarily expensive to do (in terms of development cost, dos risk, etc) even ignoring the desirability of it
<luke-jr>
expensive for the implementors (ie, us), not the miners
<gmaxwell>
luke-jr: you disagree but we did extensive testing on priority mining.
<luke-jr>
(I think a lot of the complexity would actually provide useful functionality otherwise, BTW)
<gmaxwell>
luke-jr: also resource expensive, and getting knocked out due to a dos attack (which miners are frequently targeted with is chea)
<luke-jr>
gmaxwell: the testing didn't support the removal..
<luke-jr>
gmaxwell: I could dig out other examples too - like the one forbidding address reuse per block
<gmaxwell>
I think it did.
<gmaxwell>
(also the total lack of wallets that made any any real use of it in coin selection, in spite it being useful and usable for _years_-- bitcoinj's fifo doesnt' count as it made really bad use of it, needlessly burning up priority like a fee wallet never taking change :))
<luke-jr>
gmaxwell: the testing only ever showed that there were no "free" transactions being priority-mined; insofar as selection of non-"free" transactions, it was always effective
<luke-jr>
special use by wallets isn't needed for it
tromp has joined #bitcoin-wizards
<luke-jr>
and then with its removal, we had spam effective in halting transactions below their fee floor; Bitfury experimented with insane "fit as many txs per block" policies that could have been better off just using blockprioritysize; etc
<jeremyrubin>
luke-jr: I think that if you're against economic-maximization in core, you shouldn't argue that not all policies should be economic, you should find a model where they are economical
<jeremyrubin>
luke-jr: there are rich toolsets avail for modeling things that otherwise don't seem likely (like altruism)
<luke-jr>
jeremyrubin: that requires softforks/hardforks, and is a lot more complex to model
<jeremyrubin>
No I'm just talking about modeling
<jeremyrubin>
so no hardfork/soft
<luke-jr>
jeremyrubin: for example, with segwit we balanced the weight of inputs and outputs, and broke incentives in other places
<jeremyrubin>
You can still make an economic model
<luke-jr>
I have no idea what you're suggesting then.
<luke-jr>
the economic model is fixed by the protocol rules
<jeremyrubin>
no
<jeremyrubin>
I mean like a simulation
<jeremyrubin>
(but not neccesarily simulated)
<jeremyrubin>
You can then prove a result about the rule you prefer, giving evidence that it is a preferable rule
<luke-jr>
jeremyrubin: we had real-world data showing coin-age priority was helpful
<gmaxwell>
I don't agree we had that.
<jeremyrubin>
real world data is anecdata
<jeremyrubin>
;)
tromp has quit [Ping timeout: 245 seconds]
<jeremyrubin>
A richer theoretical model of coin priority should tell you if it will continue to be useful
<gmaxwell>
I think we had real world data showing that longtime bitcoin users like luke and myself could use it to make free or really cheap transactions, while most ordinary users didn't benefit at all... which to the extent it did anything created an incentives misalignment between developers and end users.
<jeremyrubin>
and will give a precise language to statements like 'helpful'
<luke-jr>
gmaxwell: unless you were doing transactions every block, a lot of people benefitted
<gmaxwell>
the priority rule required 1 BTC stationary for one day. per input+output...
<luke-jr>
which was much less back then, and multiple days reduced it
<luke-jr>
(in fact, that suggests further than it wasn't all a few people taking advantage of it)
<jeremyrubin>
luke-jr: you should talk to eric budish I thinl
<luke-jr>
IIRC, that was just for gratis transactions anyway, not priority mining policies
<luke-jr>
jeremyrubin: does he have a nickname?
<gmaxwell>
luke-jr: bitcoin was at like $3k when priority was turned off by default, IIRC.
<jeremyrubin>
actually maybe not eric I'm thinking of
<jeremyrubin>
Jacob Leshno is who I meant (they're colleagues)
<luke-jr>
speaking of which, I need to actually start on my talk for MCC :x
AaronvanW has joined #bitcoin-wizards
<jeremyrubin>
email sent, did my best to summarize
<luke-jr>
jeremyrubin: thanks
spinza has quit [Quit: Coyote finally caught up with me...]
pinheadmz has quit [Quit: pinheadmz]
spinza has joined #bitcoin-wizards
Guest43444 has quit []
AaronvanW has quit [Ping timeout: 258 seconds]
jungnam has joined #bitcoin-wizards
pinheadmz has joined #bitcoin-wizards
jeremyrubin has quit [Ping timeout: 255 seconds]
tromp has joined #bitcoin-wizards
jeremyrubin has joined #bitcoin-wizards
tromp has quit [Ping timeout: 255 seconds]
tromp has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
enemabandit has joined #bitcoin-wizards
Dean_Guss has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Ping timeout: 248 seconds]
ccdle12 has joined #bitcoin-wizards
laptop500 has joined #bitcoin-wizards
setpill has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 245 seconds]
justanotheruser has quit [Ping timeout: 268 seconds]
jimmyrizzle has joined #bitcoin-wizards
ccdle12_ has joined #bitcoin-wizards
ccdle12 has quit [Read error: Connection reset by peer]
jungnam has quit []
jb55 has quit [Ping timeout: 248 seconds]
ccdle12_ has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
sunetoft has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
sunetoft has quit [Remote host closed the connection]
yoleaux has quit [Ping timeout: 258 seconds]
yoleaux has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
aljungberg has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
michaelfolkson has joined #bitcoin-wizards
Deinogalerix21 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
Deinogalerix21 has quit [Quit: WeeChat 2.4]
<drexl>
gmaxwell, luke-jr: what would happen if everyone was running this bfgminer code during the 2013 leveldb bug fork?
<gmaxwell>
nothing bad.
<gmaxwell>
it it inhibits going back and undoing work you already accepted, not switching to a tip with more work.
fkinglag has quit [Read error: Connection reset by peer]
fkinglag has joined #bitcoin-wizards
jimmyrizzle has left #bitcoin-wizards [#bitcoin-wizards]
mryandao has quit [Remote host closed the connection]
mryandao has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
enemabandit has quit [Remote host closed the connection]
enemabandit has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 255 seconds]
drexl has quit [Quit: drexl]
aljungberg has quit []
quaid1 has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 244 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
michaelfolkson has quit [Quit: Sleep mode]
michaelfolkson has joined #bitcoin-wizards
kokoska69 has joined #bitcoin-wizards
kokoska69 has quit [Client Quit]
ccdle12 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
justanotheruser has joined #bitcoin-wizards
ccdle12 has quit [Read error: Connection reset by peer]
ccdle12 has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
leakypat has joined #bitcoin-wizards
leakypat has quit [Client Quit]
ccdle12_ has joined #bitcoin-wizards
ccdle12 has quit [Read error: Connection reset by peer]
pinheadmz has joined #bitcoin-wizards
drexl has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
michaelsdunn1 has joined #bitcoin-wizards
ccdle12_ has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
jimmyrizzle has joined #bitcoin-wizards
quaid1 has quit []
quaid1 has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
setpill has quit [Quit: o/]
sdaftuar has quit [Remote host closed the connection]
jnewbery has quit [Quit: leaving]
vtnerd_ has quit [Ping timeout: 246 seconds]
vtnerd has joined #bitcoin-wizards
Dean_Guss has quit [Ping timeout: 256 seconds]
enemabandit has quit [Ping timeout: 268 seconds]
roconnor has quit [Ping timeout: 248 seconds]
CubicEarth has quit [Ping timeout: 268 seconds]
jimmyrizzle has quit [Remote host closed the connection]
<luke-jr>
gmaxwell: but to address the 2013 issue, pools DID need to go back..
<luke-jr>
drexl: I don't think the BFGMiner implementation actually protects more than a few blocks back, but if it did, individual miners would have had to act instead of just the pool operator
CubicEarth has joined #bitcoin-wizards
<drexl>
yes so if something like that happens again and such a protection is in place it will amplify the damage
roconnor has joined #bitcoin-wizards
michaelfolkson has quit [Quit: Sleep mode]
Chris_Stewart_5 has quit [Ping timeout: 268 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
StopAndDecrypt has quit []
StopAndDecrypt has joined #bitcoin-wizards
quaid1 has quit []
roconnor has quit [Ping timeout: 245 seconds]
gribble has quit [Remote host closed the connection]
<Chris_Stewart_5>
re: harding 's comment over in bitcoin-core-dev, it does raise an interesting question of how invasive we want to be in changing semantics of Script itself.
<Chris_Stewart_5>
IIRC, the segwit v0 didn't actually change any op codes in script? Just the pre-processing logic?
<Chris_Stewart_5>
If we were to change the semantics of an op code on a witversion basis, we need version checks inside of 'EvalScript' itself then no?
gdude2002 has joined #bitcoin-wizards
<harding>
Chris_Stewart_5: I think an alternative without changing old semantics would be just to redefine a couple of the OP_SUCCESSn opcodes to OP_CLTV++ and OP_CSV++ that would be identical to their original versions but which consumed their parameter instead of passing it through.
<Chris_Stewart_5>
ah, so provisioning a new byte instead of re-purposing the old OP_CLTV/CSV byte? I think i like that better
<gmaxwell>
that would be safer, but perhaps needlessly incompatible.
<gmaxwell>
harding: got any example where the opcode limit would matter? if you did, might be a reason to just increase the limit.
<gmaxwell>
it isn't as though any single leaf should have a bunch of those opcodes, only one or two.
<Chris_Stewart_5>
so in the uncooperative cases, we still need limits like sig checks, op code, push size etc in Taproot?
gribble has joined #bitcoin-wizards
nkohen has joined #bitcoin-wizards
<harding>
gmaxwell: nope, I can't think of any examples. Having a few billion possible script leaves makes it hard to even contrive an example where you'd need more that a few OP_CSVs.
instagibbs has quit [Ping timeout: 258 seconds]
gie has joined #bitcoin-wizards
instagibbs has joined #bitcoin-wizards
roconnor has joined #bitcoin-wizards
spinza has quit [Quit: Coyote finally caught up with me...]
wallet42 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
nkohen has quit [Quit: Leaving]
michaelsdunn1 has quit [Remote host closed the connection]
gdude2002 has quit []
tss1 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 268 seconds]
Tralfaz has joined #bitcoin-wizards
Tralfaz has left #bitcoin-wizards [#bitcoin-wizards]
victorSN has quit [Remote host closed the connection]
rockhouse has quit [Remote host closed the connection]
jnewbery has joined #bitcoin-wizards
emzy has quit [Ping timeout: 258 seconds]
spinza has quit [Quit: Coyote finally caught up with me...]
tromp has quit [Read error: Connection reset by peer]