19 May 2020
rocket_fuel created group «CTV_Working_Group» with members rocket_fuel, Hiro Protagonist and Jeremy Rubin
rocket_fuel converted this group to a supergroup
rocket_fuel converted a basic group to this supergroup «CTV_Working_Group»
rocket_fuel changed group title to «OP_CTV Woking Group»
r
13:07
rocket_fuel
Invite Link: https://t.me/op_ctv
RS
13:08
Ruben Somsen
hey
r
13:08
rocket_fuel
Hi Ruben
13:08
Just trying to gather a circle of those interested in figuring out the roadmap for ctv functionality in bitcoin
HP
13:09
Hiro Protagonist
Thx for the invite. I’m not available right now but will follow along.
RS
13:09
Ruben Somsen
In reply to this message
I have no fully formed opinion on this, but I do generally like op_ctv, it seems to make a lot of sense
r
13:10
rocket_fuel
maybe i made a strong statement, how's the edit
RS
13:10
Ruben Somsen
in some form I agree the functionality should eventually make it in :)
JR
13:11
Jeremy Rubin
If i can suggest, "Just trying to gather a circle of those interested in figuring out the roadmap for ctv functionality in bitcoin"
r
13:12
rocket_fuel
edit #2
RS
13:12
Ruben Somsen
I'm just conservative forming opinions, I generally feel that's best until I feel like I have a full grasp of the implications
r
13:12
rocket_fuel
im not sure if this is the best forum, as telegram is mostly application layer people, but maybe we can get some steam going here first
JR
13:13
Jeremy Rubin
That sounds like a checklist item for a roadmap in any case :)
r
13:13
rocket_fuel
i wonder if we can make a bridge from telegram to the irc chat
RS
13:14
Ruben Somsen
In reply to this message
any time I've seen people try things like this, it just ends up working poorly
r
JR
13:14
Jeremy Rubin
That looks simpler to setup
r
13:14
rocket_fuel
In reply to this message
that is true
13:15
we could maybe have a separate chat that's just a read-only mirror of irc, or something
RS
13:20
Ruben Somsen
"Woking Group" as in "woke"? haha
JR
13:21
Jeremy Rubin
People gotta wake up to the benefits lol
RS
13:21
Ruben Somsen
Let's keep it in then :)
r
13:21
rocket_fuel
sry typo, running on no sleep
13:21
but seems to have turned out well
JR
13:21
Jeremy Rubin
(prob should be working group heh)
13:21
It's the new hodl
13:22
We have woking groups in bitcoin for getting people enlightened
rocket_fuel changed group title to «OP_CTV Working Group»
r
13:24
rocket_fuel
everyone's an admin now, knock yourself out
RS
13:25
Ruben Somsen
I got some scribbles on SNARK blockchains that I may or may not turn into a public document some day, but one of the designs I ended up with actually looks a lot like op_ctv
r
13:25
rocket_fuel
building up some momentum would be good, generate some noise, maybe that'll shake up the apathy
RS
13:25
Ruben Somsen
op_ctv sort of functions as a way to aggregate non-witness data
JR
13:26
Jeremy Rubin
Interesting; so like you can prove out efficiently that a specific txn gets created?
RS
13:26
Ruben Somsen
and one of my (preliminary) conclusions basically is that non-witness data is all that matters in a post SNARK world
JR
13:26
Jeremy Rubin
So i have had an idea
13:27
Where we go to Confidential Transactions
13:27
And at the same time do Segregated Inputs
13:27
And then all txns have a single input
RS
13:27
Ruben Somsen
single output, no?
JR
13:27
Jeremy Rubin
No
13:27
Segregated Inputs
13:27
So you spend a single input and commit to the other inputs to spend
RS
13:27
Ruben Somsen
ok then I'm skeptical, inputs are non-witness data
13:28
sorry
JR
13:28
Jeremy Rubin
But they don't affect the TXID
RS
13:28
Ruben Somsen
txids are
JR
13:28
Jeremy Rubin
And then the value propagates back through CT
RS
13:29
Ruben Somsen
I am not sure I follow
JR
13:29
Jeremy Rubin
one sec ill draw
RS
13:30
Ruben Somsen
if you don't reveal all inputs, how do others update their UTXO set?
JR
13:32
Jeremy Rubin
r
13:32
rocket_fuel
whats the best remote whiteboard, btw?
13:33
gliffy is ok for diagrams, but sucks for quick sketching
RS
13:33
Ruben Somsen
In reply to this message
what does it say in the top right box? can't read
JR
13:33
Jeremy Rubin
Uh the top ones are saying "sig witness"
13:33
So you have a "input witness" and a "sig witness"
13:34
The input witness is the inputs being spent
13:34
Upgraded nodes track this and mark those as being spent
13:34
Old nodes think those outputs are still spendable, but they aren't
13:34
(Remember, after a softfork monotonically fewer things are spendable)
RS
13:35
Ruben Somsen
hold on what is the goal, soft forking in CT?
JR
13:35
Jeremy Rubin
So the goal is that you can propagate value
13:35
without having the input be an explicit part of the txn
13:35
Not for privacy, just that it shifts how we do accounting.
RS
13:36
Ruben Somsen
not explicit as in not even part of the txid?
JR
13:36
Jeremy Rubin
It is part of the signatures! But not the txid
13:36
TXIDs just need to be unique
13:37
This lets you do cool things around adding new inputs to add value to sub protocols without disturbing the txid
13:37
Which means that LN-y apps work better
13:37
Because you can always just pick one input to be the basis of the txid
13:37
You can look at how Bram designed Chia, they do this
RS
13:38
Ruben Somsen
I don't fully follow, still, so let me ask a few more questions
r
13:38
rocket_fuel
maybe we should get bram in here then
RS
13:38
Ruben Somsen
why is there still one input not segregated?
JR
13:39
Jeremy Rubin
13:39
With CTV it becomes this BTW
13:40
And then you don't even really need to create those outputs in the normal block space
13:40
Then it becomes extension-block-y though
RS
13:40
Ruben Somsen
right
JR
13:40
Jeremy Rubin
You have to spend one output for it to be a soft fork
RS
13:41
Ruben Somsen
the ctv part I get, the segregated inputs still confuse me haha
JR
13:41
Jeremy Rubin
Think of it as you're picking which input you use to anti-replay your txid
13:41
There must be *some* base input for every txn
RS
13:41
Ruben Somsen
ok I see why you need one input at least for it to be a soft fork
JR
13:41
Jeremy Rubin
Otherwise TXIDs could collide
RS
13:41
Ruben Somsen
as a hard fork could you segregate them all?
JR
13:42
Jeremy Rubin
Mmmm...
13:42
Yes
RS
13:42
Ruben Somsen
right, every tx needs to be unique
JR
13:42
Jeremy Rubin
But then you'd make a HFTXID
13:42
that has to be unique
13:42
and it would be based on the hash of something you're spending most likely
RS
13:43
Ruben Somsen
OK I think it's finally clicking
JR
13:43
Jeremy Rubin
btw it doesn't need to be CT as mentioned. You just can't use the normal value field as otherwise there's no way to move funds from the segregate inputs
RS
13:43
Ruben Somsen
you're just saying the txid doesn't cover inputs
JR
13:43
Jeremy Rubin
Yep! Just covers the 0th one
RS
13:44
Ruben Somsen
OK I'lll have to think about the consequences of that, but I get it
JR
13:44
Jeremy Rubin
Think of it as a "me and my friends" model
13:44
Which UTXO is making this TXN? Me.
13:45
Who else is along for the ride? my friends, but that set can be unspecified or computed dynamically
13:45
E.g., from *my* script
13:45
All that matters is that all my friends agreed to be in the txn with me
13:45
And that the total amount is preserved
13:46
err invariant is preserved
RS
13:46
Ruben Somsen
I see, so dynamically you can add inputs that conform to whatever your script allows
JR
13:46
Jeremy Rubin
Yeah. Or at base, it's just a rule that my signature has to validate.
13:46
And when I signed I specified the set of other inputs
13:47
So if those aren't present, then my signature didn't work
RS
13:47
Ruben Somsen
right
JR
13:47
Jeremy Rubin
Interesting that means the signature hash algo doesn't have to change
13:48
Because sighash all would still be "correct", but what you're signing would change (sign a tx with the inputs added in)
RS
13:49
Ruben Somsen
hmm I'll have to let it sink in
13:50
but I see how it solves the malleability issues you've been running into with op_ctv
13:51
and I am starting to see better why it's valuable that the op_ctv transactions aren't malleable, but I'm still struggling with that as well a little bit
JR
13:52
Jeremy Rubin
yeah
13:52
They *can be* malleable if you use more than one input
RS
13:52
Ruben Somsen
is it related to CPFP to not want malleability?
JR
13:52
Jeremy Rubin
In which case if your sub-protocols have HTLCs not based on Eltoo
13:52
You're screwed
13:52
So Eltoo + CTV wouldn't care about this
13:52
But just CTV alone you need the restriction
RS
13:52
Ruben Somsen
right, I see how it screws over lightning without eltoo
JR
13:53
Jeremy Rubin
But if we had segregated inputs, you wouldn't need eltoo i think
13:53
Not quite sure, but you'd inherently always have txid stability
RS
13:54
Ruben Somsen
hmm, I see how it can make it easier to pay for fees in eltoo style, but I am not sure whether you can get the state overwriting functionality
JR
13:54
Jeremy Rubin
What's that?
RS
13:55
Ruben Somsen
I mean instead of invalidation you have state
JR
13:55
Jeremy Rubin
Ah
RS
13:55
Ruben Somsen
where one tx spends the next in order with cut-through
JR
13:55
Jeremy Rubin
I am not sure. You probably keep on using HTLCs
13:55
but TBH one way of doing this would be do have delegation instead of anyprevout
13:56
and then you can revoke by signing a CTV hash or smth
13:56
So you can always flow to the next upgraded state?
RS
13:57
Ruben Somsen
In reply to this message
you mean adding a second input to a tx that can be spent separately to invalidate the tx?
JR
13:57
Jeremy Rubin
I think that works you just need 3 timeout periods
13:57
No so you'd have an initial tx which is "Channel Dead reported by Bob"
13:57
Alice can respond with "But i have a newer state which is X Tx"
13:58
Bob can then respond with a "but actually Z" tx
13:58
You might not need that last one
13:59
Maybe I should write this up...
RS
14:00
Ruben Somsen
I see how it should be resolvable in a limited number of back and forths (if two participants), but I am not sure what this would look like script wise
14:00
and I also wonder whether this is applicable to channel factories
14:03
alright bed time for me
14:03
interesting discussion though, thanks for sharing
fiatjaf invited fiatjaf
r
14:58
rocket_fuel
Welcome fiatjaf!
f
15:01
fiatjaf
welcome
15:12
I'm here for the BMM
r
15:13
rocket_fuel
Awesome, we are all here for different reasons
HP
15:14
Hiro Protagonist
What’s BMM?
r
15:15
rocket_fuel
Blind merge mining. Fiatjaf has some ideas about sidechains with non-fungible tokens
f
15:15
fiatjaf
ideas are ruben's
HP
15:17
Hiro Protagonist
Ok. What’s the relationship between CTV and merge mining?
HP
15:43
Hiro Protagonist
Ok. That’s very straightforward.
JR
18:50
Jeremy Rubin
BTW CTV doesn't require CPFP for this use case as claimed in the thread @RubenSomsen
18:50
You can have a second anyone-can-pay input
f
18:53
fiatjaf
I'm just waiting for ruben to make his BMM chains with one-way peg so I can copy the code, delete the part where there's a peg and instead let BMM miners be paid in a non-trustless manner from outside
JR
19:06
Jeremy Rubin
btw this took about 10s on my compute @RubenSomsen
19:06
19:06
I think that's all you need for BMM
19:07
to use the seal you just spend and then put whatever you like in the witness data
r
19:24
rocket_fuel
In reply to this message
he's actually writing that?
f
19:25
fiatjaf
I think not
19:25
but I'm not in a hurry
19:25
someone will write it someday
JR
19:25
Jeremy Rubin
^^ see code above job done, right ;)
r
19:26
rocket_fuel
now we just need rhett to delet
19:26
In reply to this message
where is this from?
JR
19:26
Jeremy Rubin
I just wrote it up right now to share here
r
19:26
rocket_fuel
oic
19:27
In reply to this message
and then maybe even merge it into core 10 years later
JR
19:27
Jeremy Rubin
What's cool is you can make the script arbitrary
19:28
So you can have something where you have a BMM with a permissioned key or something
f
19:28
fiatjaf
In reply to this message
no sir, once OP_CTV is soft-forked in the BMM chain doesn't need to, it's optional
19:28
In reply to this message
I don't understand what is happening here so I'll not say anything
JR
19:28
Jeremy Rubin
Ah well ask away
19:29
All we're doing is essentially starting from a bottom transaction and then building 1million steps up
19:29
Each step being a txn that has 2 inputs and 1 output
f
19:30
fiatjaf
oh oh
19:30
that's without actual OP_CTV?
JR
19:31
Jeremy Rubin
with
f
19:31
fiatjaf
just simulating it by using a key to pregenerate the transactions
19:31
with, ok
19:31
but then the key owner can't hijack the string of transactions, can he?
JR
19:32
Jeremy Rubin
Ah
19:32
No I was saying you'd do something like:
19:32
<key> CHECKSIG <H> CHECKTEMPLATEVERIFY
19:33
so then it requires a key to authorize the step, which means that you can make sure that whatever network validators who have permissions to make blocks can make sure only *valid blocks* are issued
19:34
THis might be useful for bootstrapping; e.g. have a block signing key for the first year
19:34
Enough time to get a robust enough community around it
f
19:34
fiatjaf
oh, ok
19:34
I get it
19:34
now I also understand the script above
r
19:42
rocket_fuel
@jeremyrubin do you have a testnet with op_ctv enabled?
JR
19:43
Jeremy Rubin
I need to set it up... but I've been having trouble rebasing taproot which I've been told people would also really want if I do a testnet
19:43
Testnet is also kinda annoying because you have to mine it
19:44
kalle's signet stuff isn't quite ready IIRC
r
19:44
rocket_fuel
In reply to this message
like a fake miner?
JR
19:44
Jeremy Rubin
yeah exactly
r
19:45
rocket_fuel
it would be a good next step, i think, to have a functional testnet.
19:45
maybe even build random experimental crap on it
19:48
kalle's signet platform had no commits in 4 months? ded?
JR
19:48
Jeremy Rubin
I think no one has reviewed it
19:48
It's hard because the way he built it is designed to be really compatible with bitcoin mainnet
19:48
So he defines the signatures to take up space in the coinbase txn
19:49
so IIRC it means those are defined for mainnet too or something.
19:50
so I think the problem is that no one loves the design & it is kinda invasive, and no one is bothering to think through a better design. Kalle has spent a lot of time on it which suggests he thought through the different avenues.
RS
22:23
Ruben Somsen
In reply to this message
I remember you telling me this. You have to consume the entire input so that seems a bit awkward, but CPFP is awkward too so maybe it wins out.
22:24
A fourth (controversial) option: use the BMM chain to pay miners for inclusion of specific BTC transactions.
JR
22:26
Jeremy Rubin
yeah consuming the entire input isn't really that bad/weird as you can set up multiple in advance with the bids you want to make for fees; and you can also set up the input to be spent in the same block with a low-fee transaction and CPFP will pick it up
22:26
Err...
RS
22:26
Ruben Somsen
In reply to this message
this goes into extension block territory, so not great at all
22:28
>set up the input to be spent in the same block with a low-fee transaction and CPFP will pick it up
Not following that part
JR
22:29
Jeremy Rubin
22:30
above the line is confirmed txs, below unconf.
22:30
A is low fee
22:30
A is low fee by itself, but input A.1 goes into spend of B.0 and become a high fee package
22:31
So a rational miner mines A and (should be labelled) C
22:31
But not just A
22:31
So then if another BMM driver adds A'
22:31
which displaces A
22:31
then A doesn't get mined cuz it's low fee
RS
22:34
Ruben Somsen
I see
JR
22:36
Jeremy Rubin
22:36
maybe a better diagram
22:36
either M0 or Y0 drives B0 to C
22:37
but M and Y are both 0 fee
RS
22:37
Ruben Somsen
in BMM the fees you pay depend on what users pay BMM miners, so a low-fee transaction will probably never occur (unless the BMM chain is severely under-used)
JR
22:37
Jeremy Rubin
I would expect BMM fees to be high if it's valuable to be the merger of the block (tx selection)
RS
22:38
Ruben Somsen
right
JR
22:38
Jeremy Rubin
And this structure basically makes the BMM-ing an auction via mempool CPFP
22:38
But what's fun is that txn pinning comes in and makes that not work
22:38
CPFP is broken
RS
22:38
Ruben Somsen
yeah I see how CPFP plays into it
22:39
In reply to this message
you mean pinning?
JR
22:39
Jeremy Rubin
it's just a fundamentally flawed concept
22:39
I think we should backtest it and get rid of it
RS
22:39
Ruben Somsen
how would you describe the fundamental flaw
JR
22:40
Jeremy Rubin
It's ridiculously computationally complicated
22:40
So we can never have good rational CPFP
22:40
And any protocols that rely on it are insecure
22:40
we need a different algorithm and mempool architecture fundamentally
22:40
long term project
r
22:41
rocket_fuel
what was the original motivation for CPFP?
JR
22:41
Jeremy Rubin
Unstick stuck transactions, make mining more profitable
r
22:42
rocket_fuel
so the recipient can do the equivalent of RBF (that sender cannot do for whatever reason)?
22:42
thats all it is?
JR
22:42
Jeremy Rubin
RBF also probably has ta go
22:42
I hate to be the bearer of bad news on it, and I am endeavoring to prevent this because CPFP and RBF are really useful
22:43
We just don't have a great way of doing it without issues
RS
22:43
Ruben Somsen
I do agree they're both problematic, but at the same time a miner is objectively more profitable if they take the higher fees
JR
22:43
Jeremy Rubin
Well it depends on how often CPFP is being used
RS
22:44
Ruben Somsen
maybe they don't want to waste unlimited CPU figuring out what tx to take, but they will certainly want to do some work for it
JR
22:44
Jeremy Rubin
and CPFP actually precludes higher fees in many cases
22:44
because of pinning
22:45
And LN can't take off until pinning is solved; LN should increase base layer value; so fees will be higher if pinning is solved
RS
22:45
Ruben Somsen
does pinning also apply to eltoo?
JR
22:45
Jeremy Rubin
yes
22:45
diff layer
RS
22:46
Ruben Somsen
it's because the second output that can be added to the tx can be spent again, so that's how it can be pinned, right?
JR
22:46
Jeremy Rubin
no
22:46
Well yes
22:46
sorry forgot the context
22:48
btw there are different mempool architectures that can maybe solve some of this.
22:49
Am exploring :)
RS
22:49
Ruben Somsen
it seems like an important issue, fees make everything complicated
JR
22:49
Jeremy Rubin
it is and isn't
22:50
I was talking with Bryan Bishop at London Socratic today
22:50
And he made a great point
22:50
Which is that a lot of the issues that come up with CTV stuff is not really problems with CTV, it's problems with what the ecosystem is doing right now
22:51
(someone was asking how existing wallets handle CTV, and it's a question of how wallets handle unconfirmeds, and it's just a mess of different behaviors)
22:52
that the mempool is broken is true whether or not CTV gets merged
22:52
C/F my response to Matt's post, I've been trying to fix the mempool for like 9+ months now, but now people realized those issues are problematic for lightning even with the carve out
RS
22:53
Ruben Somsen
Lightning draws a lot of attention
22:55
In reply to this message
there is no way here to have L and X be the same UTXO? or do you reintroduce the problems we're discussing then?
JR
22:56
Jeremy Rubin
They can be! I don't know what the mempool does if you RBF something with a dependent chain
RS
22:56
Ruben Somsen
right that's what I am wondering
JR
22:57
Jeremy Rubin
There is literally not a single person in the world who can answer this question from memory
22:57
:)
22:57
I don't think mempool policy *should* be that complex, but it is
22:57
I can look at the code and test it but there are circumstances where it may or may not hold
22:58
E.g., what if L has 19 ancestors?
22:58
Completely different behavior
RS
22:58
Ruben Somsen
right
JR
22:58
Jeremy Rubin
haha but maybe we should start a "mempool complaining" thread
22:59
The first seen rule was bad economically & for relay, but it was *very* simple to understand.
RS
22:59
Ruben Somsen
it was actively being broken by miners though
JR
22:59
Jeremy Rubin
yep
23:00
Wait how so?
23:00
Broadcasting conflicts?
RS
23:00
Ruben Somsen
they were doing the equivalent of full RBF with custom software
JR
23:00
Jeremy Rubin
Ah
23:00
Yeah RBF is less bad than CPFP
23:01
(from a mempool perspective, I think RBF is a worse idea from a UX perspective)
RS
23:05
Ruben Somsen
In reply to this message
can't similar pinning issues occur here if m is a string of unconfirmed transactions, m0 pays for all of them, and then y0 comes in to replace it?
JR
23:07
Jeremy Rubin
m is a transaction idk what it means to be a string
RS
23:07
Ruben Somsen
sorry
23:07
multiple unconfirmed transactions
JR
23:07
Jeremy Rubin
In reply to this message
^^^ ?
RS
23:07
Ruben Somsen
ma > mb > mc > m0
23:08
right
23:08
but the context is different
23:08
there we were saying L and X are the same
23:08
I guess it doesn't matter
JR
23:08
Jeremy Rubin
Ah. It's the same issue
RS
23:08
Ruben Somsen
gotcha
20 May 2020
Oriol invited Oriol
O
00:49
Oriol
Hello
JR
00:50
Jeremy Rubin
hi
r
01:11
rocket_fuel
welcome @oriolpont !
O
01:18
Oriol
I'm Oriol, a timechain enthusiast, also a researcher on digital signal processing and Complex systems. I heard you're building Bitcoin's DeFi and I'd like to see how I can contribute.
r
01:23
rocket_fuel
well, for now we are just trying to get op_ctv on the roadmap
01:23
jeremy has some other projects he's building, you should DM him
O
02:29
Oriol
At cold: I've done a bit of non-Markovian modeling of econometric series, which are relevant to derivative pricing (premiums, rates), and at a more general level, I can review algorithms and code (I'm more a computational mathematician / physicist than a computer scientist, though).

Let me read what's been posted on the website and the convos here, so that I have a clearer idea of the goals.
02:29
In reply to this message
🆗
JR
02:29
Jeremy Rubin
You might be interested in looking at https://utxos.org
02:30
Also given your background you may enjoy this simulation on congestion control https://github.com/JeremyRubin/CTVSims/tree/master/batch-splitting
02:31
w.r.t. derivatives pricing there's some stuff... but a bit less relevant at base layer. but you'd get a kick out of https://powswap.com
O
02:38
Oriol
👍I'll read those later today
rocket_fuel invited Giacomo Zucco
GZ
12:43
Giacomo Zucco
Hello everybody
r
12:43
rocket_fuel
Hi !
RS
12:46
Ruben Somsen
In reply to this message
Hey Giacomo :) I believe you're the person I have the most Telegram groups in common with haha
HP
12:46
Hiro Protagonist
Hello Giacomo.
GZ
12:48
Giacomo Zucco
In reply to this message
Ahahahah. I'm your stalker.
RS
12:48
Ruben Somsen
A real stalker would be listening to my podcast ;)
GZ
12:49
Giacomo Zucco
In reply to this message
You can't prove I don't!!!!
RS
12:49
Ruben Somsen
touché
f
14:25
fiatjaf
why can't each node have different mempool policies?
JR
14:25
Jeremy Rubin
They can!
14:26
Doesn't quite make sense how we have it set up now because normal nodes do some extra work to be able to mine blocks if they wanted to
14:27
14:28
In reply to this message
longer term I think it's conceivable that we have a more hetergeneous mix of node policies, but that has a negative impact on relaying
14:28
One thing that's useful to frame it as is what the *ideal* mempool would be, and then what tradeoffs we're making from there
14:29
Ideal mempool is every txn ever seen by your node and does a knapsack solver to get the optimal block out.
GZ
14:31
Giacomo Zucco
In reply to this message
Hi!
JR
14:32
Jeremy Rubin
But knapsack is np-hard and all txns seen is large N so kinda provably won't ever get that idealized mempool
f
14:32
fiatjaf
when you say CPFP and RBF must go you mean go from where? you mean that kind of trick should stop being allowed on the mempool of bitcoin core? or you mean forbidding it entirely?
JR
14:33
Jeremy Rubin
to be 100% clear; we need some form of that API. But the implementation of CPFP and RBF are problematic from an algorithmic complexity PoV and end up having some nasty side effects that I'm working on fixing, so even short of adding new features I would put it at 50/50 odds that CPFP and RBF could need to be removed entirely.
14:34
need to be ==> someone learns how to exploit them to cause network disruption, only recourse is disabling
14:35
I do have a proposal (not yet written up) for how you can fix this BTW
14:36
but it requires breaking some invariants people like around TXs so might not be popular
14:36
Essentially it's a new opcode which is OP_IN_BLOCK_WITH_TXID_VERIFY
14:37
Then if you want to 'unstick' something you just spend to such an output, which necessitates that a miner has to mine the TXID arg at the same time as your tx to claim the fee
14:37
Then you only accept these txs if they bump the feerate of the target tx and evict them at the same time
f
14:38
fiatjaf
but if fees are very expensive in general, wouldn't that be an unnecessary waste?
14:39
in other words, I don't understand why RBF is bad
14:39
RBF seems so simple and cheap
JR
14:39
Jeremy Rubin
RBF is less bad than CPFP
14:39
But it's bad in terms of DoS vectors
14:39
because when you RBF something with a lot of children it's expensive
14:40
100000x less bad than CPFP, but still bad
f
14:40
fiatjaf
so if you remove CPFP from the equation RBF instantly becomes simple and easy again?
14:40
(I don't know what I'm talking about)
JR
14:40
Jeremy Rubin
No
14:41
So the issue is that because we have anti-dos measures things like RBF and CPFP are *ALWAYS* pinning vulnerable
f
14:41
fiatjaf
currently bitcoin core does heavy calculations trying to decide what transactions to accept on mempool considering CPFP?
14:41
ok, I have no idea of what is "pinning", where can I read about it?
14:45
(btw advocating against this makes me feel like the parent telling kids the halloween candy may have razor blades so they can't eat it ;) )
14:45
I'm not anti-candy I'm anti-razorblades
Maxim Orlovsky invited Maxim Orlovsky
r
15:13
rocket_fuel
Hi Maxim, welcome!
f
15:53
fiatjaf
"BIP125 RBF rule #3 requires a replacement transaction pay a higher absolute fee (not just feerate) than the transaction being replaced and any of its children."
15:53
why on earth? this rule seems completely wrong
15:53
the RBF BIP doesn't explain
JR
15:54
Jeremy Rubin
Wait that makes a lot of sense!
15:54
Because why replace a high fee package with a low fee one
f
15:54
fiatjaf
because why not?
15:55
if the transaction is smaller and thus has a bigger relative fee
JR
15:55
Jeremy Rubin
In reply to this message
Bips aren't living documents they don't get updated. Cpfp came after
f
15:56
fiatjaf
right, but I was looking for explanations for the rule 3
15:56
why would it exist
MO
15:56
Maxim Orlovsky
In reply to this message
hi and thank you for the invitation! Glad to see here everyone
JR
16:14
Jeremy Rubin
You require both to be monotonic because miners prefer higher overall fee. Higher relative fee can be used to cause nodes to decrease mempool quality.
16:14
Would you rather pick up a piece of gold dust or a dollar coin?
16:15
The simplest rule is to just make both monotonic
f
16:17
fiatjaf
In reply to this message
I don't get this, this implies miners prefer a block with a single transaction that pays 1000sat than a block with 500 transactions each paying 3sat?
JR
16:17
Jeremy Rubin
Anyways... I kinda want to be done discussing mempool stuff if that's ok. It's a little off topic for this group IMO and I can only explain what the policies are I'm not really defending them (in fact I think theyre bad because they're complex and don't do what people want leading to insecure apps w bad mempool assumptions)
16:19
In reply to this message
Not a block, a mempool. The 1000 sat one pays more and it's likely there is a lot of stuff in the mempool not just three txns. I agree rationally you want the higher feerate one if the mempool is full, but you end up having to analyze the entire mempool to make these decisions and even then it's only probabilistic against future txns
16:19
So the obvious answer is just to request both be monotonic for inclusion
16:20
Otherwise you are looking at some complex logic in mempool and therefore dos
16:20
If I have a low fee txn that is very big
16:20
I can keep on making it smaller paying the same fee
16:21
But increasing relative fee
16:21
And this costs the network a lot
16:21
So even if you don't implement the optimized version you can cost the Network the opportunity cost of relaying non spam txns
16:21
So you require both have to increase so ensure you're not spamming
16:23
In reply to this message
Happy to follow up discuss this one in dm
f
16:56
fiatjaf
ok
16:56
I think I get it
16:56
thank you
eragmus invited eragmus
r
18:50
rocket_fuel
hi @eragmus , welcome
Michael Tidwell invited Michael Tidwell
r
22:10
rocket_fuel
rocket_fuel pinned this message
21 May 2020
r
09:59
rocket_fuel
preaching to the choir. i can't convince anyone on the LN chats that high fees could be fatal to LN
10:00
"market will sort it out", "peeps will pay $100 if they wanna use bitcoin"
10:00
"i'll wait for a week to confirm"
JR
10:01
Jeremy Rubin
I do think that can happen, but you need to split confirmation and redemption for that to work reasonably
r
10:02
rocket_fuel
for $100, and a week wait, I'll just get the amex centurion instead
10:02
instead of LN
10:02
im sure amex can figure out btc collateralized loans given enough time
10:02
In reply to this message
and you need transaction aggregation as well.
10:03
this is just a preview due to a hashrate drop, but we'll get to such a state permanently one day, and may not take that long to get there.
JR
10:04
Jeremy Rubin
In reply to this message
💯
10:05
It does make me feel a bit doomsday but this is why I think deploying ctv soon is ridiculously high priority
r
10:05
rocket_fuel
same
10:05
btw, based on my conversations people are only superficially aware of op_ctv
10:06
mindshare penetration is low
JR
10:07
Jeremy Rubin
Hmm. What venues reach people?
r
10:07
rocket_fuel
it depends
10:07
i'd do some media circus, but this may put off core contributors
10:08
rochard recommended van wirdum, but he already wrote something on op_ctv
JR
10:08
Jeremy Rubin
Yup!
r
10:08
rocket_fuel
thats why i made this group, to make it a hub, plenty crypto projects on here
JR
10:08
Jeremy Rubin
It was a good one too. I think I can do another circus as my tooling project matures
r
10:08
rocket_fuel
you'd think LN guys would be more interested, but no
RS
10:09
Ruben Somsen
In reply to this message
ctv can spread the load, but eventually all transactions must appear on-chain
r
10:09
rocket_fuel
In reply to this message
if you can aggregate into channel factories non-interactively, that would be a huge boost
JR
10:09
Jeremy Rubin
Yep
10:10
So not all utxos have to show up
r
10:10
rocket_fuel
it would actually make LN viable, i don't think it's viable otherwise other than a enforcement automation tool for semi-trusted parties, aka banks
JR
10:10
Jeremy Rubin
But even if they do show up, spreading load is valuable for preventing Volatility in fees which drives away users
r
10:11
rocket_fuel
@jeremyrubin not sure whats the best way to reach everyone, but i'd say an education campaign should be a bit more coordinated, and preferably it shouldn't be just yourself
JR
10:11
Jeremy Rubin
It is better to converge on a flag average
r
10:11
rocket_fuel
the more different faces people see talk about it - the better
RS
10:11
Ruben Somsen
yeah spreading the load is hugely important, it's pretty terrible how fees spike now
JR
10:12
Jeremy Rubin
Who wants to hit the pods or something here
r
10:12
rocket_fuel
i nominate @RubenSomsen
RS
10:14
Ruben Somsen
I think Jeremy should go on some podcasts
r
10:14
rocket_fuel
he's been doing that
RS
10:14
Ruben Somsen
you could come on the Unhashed Podcast, though we don't have a lot of reach haha
r
10:14
rocket_fuel
im not sure why penetration and recognition of its benefits is low
10:15
perhaps better messaging needs to be constructed
JR
10:15
Jeremy Rubin
I will say the Rona has hurt this
10:15
Was going to do something at Bitcoin 2020 and consensus
r
10:15
rocket_fuel
op_ctv offers many possibilities, and that may sort of dilute the core value prop, at least perceptually
10:16
In reply to this message
consensus went ahead digitally?
RS
10:16
Ruben Somsen
Part of the struggle with technical proposals is getting people to invest the time in understanding it
10:16
Presentations help a lot with that
r
10:16
rocket_fuel
In reply to this message
you have to spoonfeed them, no other way around it
RS
10:16
Ruben Somsen
it wasn't until I saw Jeremy explain ctv for the third time at a conference that it started to click haha
JR
10:16
Jeremy Rubin
I should do Udi's vr
RS
10:17
Ruben Somsen
In reply to this message
I'm going on that next month, maybe you can get scheduled in as well
r
10:17
rocket_fuel
but i think its probably best to concentrate on a few pressing core issues, rather than throwing everything in at once
10:17
and present only relevant ideas, based on the audience
10:17
reception from LN groups is a bit disappointing
10:19
In reply to this message
maybe seize the moment while fees are high and have coindesk put out an article "fees high? ctv fixes this."
10:19
rochard also recommended reaching out to Leigh Cuen
10:19
maybe even pierre can help?
10:19
as long as he's not restricted by kraken in some way
JR
10:20
Jeremy Rubin
I've talked to them :)
r
10:20
rocket_fuel
what they say?
JR
10:20
Jeremy Rubin
Them ==> kraken
r
10:20
rocket_fuel
what would kraken do here?
JR
10:21
Jeremy Rubin
Will dm
10:21
Can't say here yet
r
10:21
rocket_fuel
im talking about pierre specifically, as his day job is shilling corn
JR
10:21
Jeremy Rubin
I can ask him if he wants to make some content
10:22
I'll talk to Leigh too were good friends so it makes coverage a bit hard but shes savvy
r
10:22
rocket_fuel
while fees are high-ish now, it would be good time for a quick blitz
JR
10:22
Jeremy Rubin
Yeah you're probably right. I just don't want people to get on the angry for promotion of a solution
r
10:24
rocket_fuel
well, that'll be one step from denial, and only one step away from acceptance
10:24
luke told me nobody is looking forward dealing with miners, i dont think miners would object though.
10:30
In reply to this message
the wirdum article is already out, the cat is out of the bag
Jeremy Rubin invited Leigh Cuen
BtcGalaxy invited BtcGalaxy
B
13:06
BtcGalaxy
hi
r
13:06
rocket_fuel
hi hi
JR
13:10
Jeremy Rubin
Hi!
Jeremy Rubin invited Eric Lombrozo
r
14:08
rocket_fuel
Eric Lombrozo?
Jeremy Rubin invited Aaron Van Wirdum
Jeremy Rubin invited Alex L
Jeremy Rubin invited Alex Leishman
Jeremy Rubin invited Ethan Heilman
r
14:11
rocket_fuel
This channel is now officially the A-list
Jeremy Rubin invited Jonas
Jeremy Rubin invited David V
Jeremy Rubin invited Taro Watanabe
Jeremy Rubin invited Eric Meltzer
E
15:01
Ethan Heilman
Hello!
HP
15:02
Hiro Protagonist
Hi
E
15:04
Eric Lombrozo
I remember a time once when soft forks were relatively easy to coordinate and could easily fly under the radar. Nowadays you'll probably need a serious crisis before it even becomes tenable.
15:05
Thanks for bringing me into the discussion, Jeremy. Not trying to sound discouraging, btw. 😝
HP
15:06
Hiro Protagonist
Do you think that having 30% of the world economy shut down qualifies as sufficient crisis?
DV
15:07
David V
existential threat to bitcoin would get a fork through I'm sure
E
15:07
Eric Lombrozo
I mean a crisis with the Bitcoin network. An existential threat, especially
DV
15:07
David V
Bitcoin is going super strong right now, I don't really feel any pressure to take risks with the network
E
15:07
Eric Lombrozo
It can't just be a would-be-nice-to-have thing
DV
15:08
David V
a SF is a big political risk imo, threatens Bitcoin's credibility if there's a big fight
JR
15:08
Jeremy Rubin
Sounds like a self fulfilling prophecy though
DV
15:08
David V
yeah, pretty much
15:09
don't get me wrong, I'm not in strong opposition to the fork, I'm just pointing out that there doesn't seem to be any downhill slope that gets us to one
HP
15:09
Hiro Protagonist
Satoshi was Hari Seldon (for you Asimov fans). He set a deterministic thing in motion that would solve problems at future crisis moments.
JR
15:09
Jeremy Rubin
Part of the goal of bip-119 is to head off some of the scaling pressure
E
15:09
Eric Lombrozo
The scaling bottleneck is more social than technical right now
JR
15:10
Jeremy Rubin
Block demand has been spiking a lot recently
E
15:12
Eric Lombrozo
The way I see it, there are three main risk categories:

1) technical risks (bugs, introduced vulnerabilities in the code)

2) consensus failures (forks, balkanization)

3) precedent (normalization of consensus changes by trusted parties)
15:17
If the base layer is to ultimately ossify, 3 is a major problem just by itself
JR
15:18
Jeremy Rubin
Yeah I think the ossification angle is a big probelm
15:19
The core being "does bitcoin have all the foundations fixed up and feature set to succeed"
15:19
And I think the answer is presently no
DV
15:19
David V
but does OP_CTV fall into the category of things that are required to turn that 'no' into a 'yes'?
15:20
The best way to mitigate precedent risk is to ensure that every fork has a clear and present justification on the road to ossification
r
15:20
rocket_fuel
In reply to this message
Not enough people buying right now you mean? How is it social?
E
15:20
Eric Lombrozo
Hard to change habits and behavior at scale
JR
15:21
Jeremy Rubin
David, I think so?
DV
15:21
David V
In reply to this message
I guess we have to clarify the places where you feel Bitcoin is not set to be finalized
JR
15:21
Jeremy Rubin
Well it's not really about me I 'spose
15:22
so doesn't matter what I think
15:22
It's more objectively can Bitcoin do X, where X is something the community currently expects.
E
15:23
Eric Lombrozo
Not sure the community's expectations carry that much weight here.
JR
15:23
Jeremy Rubin
Well I'm just saying it doesn't matter what I think is unfinished
15:23
vs what the community thinks is
15:23
E.g. from earlier, CPFP/RBF have all sorts of problems with mempool pinning and other attacks. So we probably need some changes to make the Mempool API improved to function correctly for apps like LN.
E
15:24
Eric Lombrozo
From a purely practical standpoint, Bitcoin is based on selfish incentives much more than ideology.
15:24
If the incentives align, it works. If not, it fails
JR
15:24
Jeremy Rubin
(I think some of those changes end up being consensus layer BTW even though mempool is not)
r
15:24
rocket_fuel
In reply to this message
Isn’t community demand an expression of self interest in pursuit of profit?
15:25
I don’t see incentive misalignment in ctv.
E
15:27
Eric Lombrozo
Some incentive misalignment is direct. For instance, an economic tradeoff
15:27
But some is more indirect
15:28
For instance, battles over future influence over protocol and network
Jeremy Rubin invited Jimmy Song
James Prestwich invited James Prestwich
E
15:30
Eric Lombrozo
Fact is we lack a socially scalable process for BIPs and SF activation
15:30
It works when few are involved. But as more become involved, it works less well
r
15:30
rocket_fuel
That’s true of any process that involves humans, really
15:30
Not unique to SF in bitcoin
E
15:31
Eric Lombrozo
But the BIP process in particular is VERY unscalable. Making proposals is cheap, reviewing them is hard
15:32
Reviewing them without relying on a trusted in-group, EXTREMELY hard
15:34
This makes it a good DoS attack vector
B
15:34
BtcGalaxy
I think the malicious part of bitcoin that is against progress was pretty much removed with bcash
15:34
from there on soft forks should be easy to accept by the community
E
15:34
Eric Lombrozo
Doubtful
15:35
Every soft fork introduces serious risks and potential vulnerabilities
HP
15:35
Hiro Protagonist
It doesn’t hurt to have a villain to drum up support.
r
15:35
rocket_fuel
In reply to this message
Jeremy doesn’t seem like the type to DDOS
E
15:35
Eric Lombrozo
No, but others are the type
B
15:35
BtcGalaxy
In reply to this message
agree, but the malicious part that always rejects everything is now not present
r
15:35
rocket_fuel
Overall the BIP process and review is hard of course
15:36
But this working group is focused on the merits of CTV
E
15:36
Eric Lombrozo
Point is it is not a sustainable process. At some point it will either have to stop or be replaced
r
15:36
rocket_fuel
We can’t solve all the issues at once
B
15:36
BtcGalaxy
In reply to this message
right now, this is just reduced to a technical review, no more political attacks
r
15:36
rocket_fuel
In reply to this message
It will get replaced, but we are not at that point just yet
15:37
In reply to this message
I also don’t see the political contention over CTV
15:37
Seems like a purely technical upgrade to me, quite optional as well
E
15:37
Eric Lombrozo
I didn't see political contention over SegWit at first either
B
15:37
BtcGalaxy
In reply to this message
you don't see it because there isn't: malicious political attackers moved on with bcash
JR
15:38
Jeremy Rubin
@CodeShark one question is if all this is inevitable for proposing a change then isn't the right thing to do to propose a change?
B
15:38
BtcGalaxy
In reply to this message
community wasn't divided yet
JR
15:38
Jeremy Rubin
If there's truly no non-controversial way of proceeding
15:38
Then that's just the way forward
E
15:39
Eric Lombrozo
Nothing wrong with making the proposal. But it will be politically contentious no matter what. We're way past the days when we can assume that won't happen
B
15:39
BtcGalaxy
In reply to this message
controversial is needed, but must be purely technical. Technical controversies can be overcome by rationality. Problem is when it is politically controversial. And we are lucky that might be reduced right now.
E
15:40
Eric Lombrozo
Of the risks I listed, 1 is probably the easiest to mitigate
JR
15:41
Jeremy Rubin
I think it's fair to say that the group is focused on them in the order listed :)
15:41
I mean it depends what people care about of course
15:42
But I think it's important to get a chunk of folks technically convinced of safety/soundness, convinced on higher order goals of bitcoin being further enhanced, and then worry about the balkanization/BIP process stuff independently
15:42
As you say the social stuff will always have it's difficulties we can only hope to narrow a proposal to something technically sound
E
15:44
Eric Lombrozo
I just don't want you to invest too much into solving 1 only to later discover issues in 2 or 3 that kill it
r
15:45
rocket_fuel
In reply to this message
Segwit was just something that became focal point because they needed to find something to disagree with.
B
15:45
BtcGalaxy
In reply to this message
don't be so negative and conservative. Past problems don't mean automatic problems in the future
E
15:45
Eric Lombrozo
My concerns flipped after SegWit. Now I consider 3 to be the most dangerous
r
15:46
rocket_fuel
In reply to this message
Who is the opposition here? Miners?
B
15:46
BtcGalaxy
In reply to this message
things have changed. Bad actors moved away.
E
15:46
Eric Lombrozo
Bad actors would love to return. And much nastier ones than the CSW amd roger types
15:46
*and
JR
15:47
Jeremy Rubin
I think there's a big tradeoff around the ossification. Personally I think Bitcoin is still too unfinished to worry about "no new changes". How can changes be promoted regularly while Bitcoin is young but making it clear there isn't a regular update process being built?
B
15:47
BtcGalaxy
In reply to this message
I don't see how, unless they all change their identities which means they have 0 support to start with.
E
15:47
Eric Lombrozo
The bad actors during SegWit were noobs compared to the enemies we will be facing in the future
r
15:47
rocket_fuel
In reply to this message
That’s a possibility. What about right now? I doubt many would object, and on the contrary, many would want to see it. What if ossification is the corner where bad actors wanted to push you into?
B
15:48
BtcGalaxy
In reply to this message
like whom? who are the new actors that are so dungerous?
r
15:49
rocket_fuel
In reply to this message
He’s talking about APT-level threats.
JR
15:49
Jeremy Rubin
I think ossification is more likely a threat than backdoor features
r
15:49
rocket_fuel
Threats like that don’t need us to propose something to attack, though. I’m skeptical there is an APT actor biding their time and waiting on Jeremy to submit a BIP.
B
15:50
BtcGalaxy
oh come one, are we going to stop fearing govs?
r
15:50
rocket_fuel
In reply to this message
I actually think that was attackers goal, to burn everyone out and slow it down
JR
15:51
Jeremy Rubin
I don't think anyones is saying *that*, just that a backdoor isn't particularly as effective for Bitcoin as slowing progress
15:51
Because you can patch a backdoor, it's an auditable system
r
15:51
rocket_fuel
I didn’t stick out my head too too much under my government name during UASF, but it seems plenty of those that did burned out
JR
15:53
Jeremy Rubin
I am reminded a bit of Pascal's Wager but for government interference
E
15:53
Eric Lombrozo
It may help to put together several soft fork proposals and then work on an activation strategy for all of them combined that also considers permanently sunsetting the process
JR
15:53
Jeremy Rubin
X could be government interference, so don't do X. But ~X could be govt interference, so we must do X.
E
15:56
Eric Lombrozo
Even if the people involved in soft forks now are competent and not corrupt, they will not be there forever. Without some provision for permanently stopping the process at some point, it seems reasonable that people should be extremely wary of it by default
JR
15:56
Jeremy Rubin
I have proof they aren't competent
E
15:56
Ethan Heilman
Whats the status with Taproot?
E
15:56
Eric Lombrozo
Haha
JR
15:56
Jeremy Rubin
Your honor, I take the stand as witness
r
15:56
rocket_fuel
Raise your right hand
JP
15:57
James Prestwich
In reply to this message
is your goal to demonstrate that you are not competent, and you are involved in a soft fork, qed?
E
15:57
Eric Lombrozo
Don't forget that soft forks are literally benevolent 51% attacks
JR
15:58
Jeremy Rubin
I think wariness is good, but that absolute rejectionism is not a better default than optimistic trusted-expert acceptance
r
15:58
rocket_fuel
In reply to this message
You mean honest mining?
JP
15:58
James Prestwich
In reply to this message
no deployment plan
Jeremy Rubin invited James OB
JR
15:59
Jeremy Rubin
Also the Taproot spec has been changing a bit lately, and those changes haven't had real review yet...
E
15:59
Eric Lombrozo
Normalizing soft fork activation amounts to normalizing a serious 51% attack vector
DV
15:59
David V
In my mind, Bitcoin is mature enough at this point that the only things it is "missing" is anything that might protect it from a credible existential threat in the future
15:59
Of which I can think of 3:
r
16:00
rocket_fuel
In reply to this message
We will have at least two future soft forks.
DV
16:00
David V
1. Hashrate retiring
2. Block reward disappearing
3. Governance is taken over
16:00
Everything else is either not existential, or is the "oh fuck" variety like suddenly DLP is solved
E
16:01
Eric Lombrozo
What about privacy issues? Or is that part of 3?
JR
16:01
Jeremy Rubin
Privacy improvements?
16:01
+1
DV
16:01
David V
I don't see privacy issues as an existential threat to Bitocin
16:01
Nor one that can feasible solved on Bitcoin
JR
16:01
Jeremy Rubin
I also think custodial issues are an existential threat that slot under 3
DV
16:01
David V
Imo that challenge needs to be solved by some other network
JR
16:01
Jeremy Rubin
E.g., maj of coins held on coinbase is a real threat
DV
16:01
David V
In reply to this message
Yeah I could get behind that
r
16:02
rocket_fuel
Block reward disappearing is an existential threat?
DV
16:02
David V
Custodial / no full nodes type issues
16:02
In reply to this message
Imo yes
JR
16:02
Jeremy Rubin
So of those I think CTV helps with 1 2 and 3
16:02
:)
DV
16:02
David V
If Bitcoin has no block reward (including txn fees) it dies
r
16:02
rocket_fuel
In reply to this message
Would smoothing our fees not be helpful then?
16:02
Call it 2.a
16:02
Maybe it doesn’t solve all of 2, but certainly helps
JR
16:02
Jeremy Rubin
I think 1 and 2 are kinda the same David nah?
DV
16:03
David V
No
16:03
Hmm
16:03
One a concern about what to do with dead / retired hardware, and one is a concern about what to do when you can't fund any hardware at all
16:03
I think the solution spaces for each are different
16:04
Trivial example, you can solve 1 by rotating the hashing algorithm, but you can't solve 2 by rotating the hashing algorithm
JR
16:04
Jeremy Rubin
===> category which is just "mining economic breakdowns"
DV
16:04
David V
(Not that I endorse rotating the hashing algorithm, just reaching for an example)
r
16:04
rocket_fuel
You cannot solve 2 at all.
DV
16:04
David V
In reply to this message
Permanent issuance
r
16:04
rocket_fuel
2 requires users interest, and by losing users - you lose bitcoin
JR
16:04
Jeremy Rubin
Or just big HODLrs mine
r
16:04
rocket_fuel
In reply to this message
Yep, totally turned Doge into an SOV
JR
16:04
Jeremy Rubin
to protect the sanctity of their hodlings
DV
16:04
David V
In reply to this message
2 can fail even if you have users who are interested
16:05
It is possible for the market cap to be 1 trillion and the transaction fee cost to be $1
16:05
Or $0.01
r
16:05
rocket_fuel
That would be losing transactional interest, which supports security.
DV
16:06
David V
Yeah but with permanent issuance you can have security _without_ transaction interest
r
16:06
rocket_fuel
It will never be this bad though, payment processors and custodians will be required to roll the keys in order to comply with common infosec certifications, that alone might be sufficient to keep some levels of fees
JR
16:08
Jeremy Rubin
David an interesting solution to 2 is to add things which are "miner extractable value" contracts
16:08
Thinks like ZK contingent payments
16:09
Ethereum effectively has a perpetual motion machine of interest to mine to front run those contracts.
DV
16:09
David V
the incentives get super sloppy under that model though
E
16:09
Eric Lombrozo
If several proposals could be reviewed and ready to deploy, perhaps some existential threat could make it attractive to deploy several of them at once
DV
16:09
David V
there's a good chance this bites ethereum pretty badly at some point imo
JP
16:10
James Prestwich
MEV weakens incentives to extend the chain
DV
16:10
David V
for example, what happens if the computational power to compute the MEV of a series of transactions is more than you can complete in the space of 2 or 3 hours, and then by the time you've figured it out it's high enough to justify a full reorg?
JR
16:11
Jeremy Rubin
BTW this is already a problem in Bitcoin for fee sniping and halvings and stuff
DV
16:12
David V
fee sniping I believe has a workable solution?
JR
16:12
Jeremy Rubin
no not really
DV
16:12
David V
which basically amounts to 'leave enough for the next guy that sniping doesn't make sense'
JR
16:12
Jeremy Rubin
No, because that guy has to leave enough for the next guy too
DV
16:12
David V
right
JR
16:12
Jeremy Rubin
Pretty soon you're mining the mempool in reverse order
DV
16:12
David V
it's incentive compatible all the way through though
JR
16:12
Jeremy Rubin
just so you don't get unwound
16:12
Lowest fee first
16:12
😂
DV
16:12
David V
no
16:12
there's an optimal amount you leave on the table
16:13
and no reason that amount can't be left in the form of a brand new anyone-can-spend
16:15
As the number of pirates grows then the number who are doomed at allocating grows
16:15
So this disincentivizes mining at all
DV
16:16
David V
I don't think the mining game here boils down to the pirate game?
16:17
btw this is the most wizardly conversation I've had in years, quite refreshing
JR
16:17
Jeremy Rubin
:)
16:17
I think it does more or less?
16:17
I mean there are *new* transactions, offering new booty at any given point.
DV
16:18
David V
each block costs a certain amount to unwind
16:18
I'm not sure that fixes the abstraction, but imagine you have to overthrow 1 gold coin each time you overthrow 1 priate
JR
16:19
Jeremy Rubin
I think you can model that within the game
16:19
By choosing distributions where every pirate must get at least one coin
16:19
then by voting to kill you have to burn some money
DV
16:20
David V
by requiring money to be burned with each kill, the large number of pirates version gets solved
JR
16:20
Jeremy Rubin
Also the bigger issue is the pirates game is typically finite
DV
16:20
David V
anyone who isn't in the first 100 proposers is never going to get any money anyway
JR
16:20
Jeremy Rubin
Which is why there even/odd things
16:20
And mining is infinite
Chun Wang invited Chun Wang
E
16:21
Eric Meltzer
oh cool
16:21
thanks for adding me to this Jeremy
JR
16:21
Jeremy Rubin
Welcome Chun!
16:21
Welcome Eric!
CW
16:21
Chun Wang
Welcome Eric!
JR
16:21
Jeremy Rubin
We were just talking about what changes to Bitcoin have to accomplish for them to be considered
16:22
David claims 3 high level issues
16:22
In reply to this message
.
16:23
And we're talking about if fee smoothing is important/doable at a miner coordination layer, or if it's a 3 Booty Problem
E
16:23
Eric Meltzer
i'm barely qualified to comment compared to most of the people in this room but my sense has always been that Bitcoin as a community is VERY risk averse, so much more important than "what does this get us" is "what is the downside risk" for any new change
DV
16:23
David V
In reply to this message
this one too
E
16:23
Eric Meltzer
we can backtest that to see if it explains things that did and didnt make it into btc
CW
16:23
Chun Wang
Please add block withholding prevention
DV
16:24
David V
do you feel like block withholding is an independent exestential risk to bitcoin today?
CW
16:24
Chun Wang
Yes, as always.
DV
16:25
David V
really? My gut disagrees with you
E
16:25
Eric Meltzer
handshake has something intended to fix that
16:25
"Proof-of-work hashing involves a reserialization of the block header including a maskHash designed to prevent block withholding attacks."
CW
16:25
Chun Wang
Big bad guys can collapse current PoW operations with 1% or less hashrate.
E
16:25
Eric Meltzer
im not exactly sure how it works though and i couldnt find a quick explanation in the gh issues
DV
16:25
David V
I know how it works :P
JR
16:25
Jeremy Rubin
@wheatpond i've never been able to understand it so I assume it doesn't
E
16:25
Eric Meltzer
In reply to this message
😂
CW
16:25
Chun Wang
Just check how handshake gets it done
JR
16:26
Jeremy Rubin
In reply to this message
does it work?
DV
16:26
David V
yes
16:26
I'm trying to recall the exact attack
16:26
ahh yeah ok
16:27
@hibitcoin we're talking about block discarding, not block witholding, right?
16:27
where a miner finds a full block and then throws it out rather than presents it to the pool?
CW
16:27
Chun Wang
Depends the word you choose
16:28
I mean pool client discard submit to pool for those shares generate blocks
DV
16:28
David V
yeah
16:28
you can solve this by splitting the block up into 2 solvable pieces
JR
16:28
Jeremy Rubin
Ok I'm going to be slightly moderatorial and refocus back to BIP-119 :) David can finish explaining how it works then let's jump back.
DV
16:28
David V
👍
CW
16:29
Chun Wang
The other version of withholding no big threat given SPV well practised in real world
DV
16:29
David V
So the block has 2 parts, one which is solved by the miner and must have a difficulty of X, and then a second part which involves the pool revealing a secret. This is something the pool must commit to in advance of sending the work to the miner
16:29
so the pool can't work or roll this, basically they've got one shot on each share to meet their difficulty requiremetn
16:30
this prevents the miner from knowing if their share is a valid block or not
CW
16:30
Chun Wang
Hide the secret in the last tx should be simple and enough
DV
16:30
David V
bunch of ways to do this, unfortuantely for Bitcoin it's a hardfork
JR
16:30
Jeremy Rubin
Yeah @hibitcoin I think we can get a fix to this w/o hf
CW
16:30
Chun Wang
softfork possible
JR
16:30
Jeremy Rubin
Lopping off a signature from the segwit data works
DV
16:30
David V
is it soft fork possible?
JR
16:31
Jeremy Rubin
err'
16:31
maybe not because the miner can still tell
DV
16:31
David V
the problem is that if you soft fork, the block itself still needs to meet a difficulty requirement
16:31
I guess you can introduce a secondary difficulty requirement, and then slowly phase the network over so that the primary difficulty requirement becomes the new "share" requirement
CW
16:31
Chun Wang
at lower diff
DV
16:31
David V
but calling that a soft fork is imo mental gymnastics
CW
16:31
Chun Wang
exactly ^^
DV
16:32
David V
like technically yes, but old nodes are pretty trivially vulnerable to deep reorgs
CW
16:32
Chun Wang
we call extblk softfork too
JR
16:32
Jeremy Rubin
Ok let's... cap this one. Chun I promise to spend some cycles thinking about it and report back :)
16:33
I do think that another longer term question is if mining pools continue to exist at all. @hibitcoin curious on your thoughts on that.
DV
16:34
David V
could hashrate futures replace the need for mining pools?
JR
16:34
Jeremy Rubin
Because a perfectly decentralized pool has a bunch of negative tradeoffs but it doesn't suffer from block witholding.
CW
16:34
Chun Wang
what u gonna replace it with?
16:34
p2pool? pos?
16:34
poa? lol
DV
16:34
David V
potentially even hashrate marketplaces
16:34
hrm nvm not for Bitcoin that doesn't solve the discarding problem
JR
16:35
Jeremy Rubin
The issue with "perfectly decentralized pools" is that you have to be mining blocks regularly to benefit, so small miners can't benefit that mich
CW
16:37
Chun Wang
decentralized pool also suffer from 51% attacks if designed like p2pool
JR
16:38
Jeremy Rubin
Maybe it's a throwaway question, but I think it's worth thinking about if solving block withholding is too specific to pooled architectures where the right angle for Bitcoin longer term is building non-pooled designs. Hence being curious if it were possible to reduce variance without pools, what other value add there is (e.g., better tx selection)
CW
16:38
Chun Wang
would see if it gets succeed in altcoin first
JR
16:39
Jeremy Rubin
Yeah of course, just thinking theoretically. Pooling works for Bitcoin for now.
CW
16:39
Chun Wang
you need something significant better to convince miners switch from pools
JR
16:39
Jeremy Rubin
100%
CW
16:39
Chun Wang
miners are here for profit
16:39
that’s why p2pool failed
16:40
the real world is not academic
JR
16:41
Jeremy Rubin
Have you seen withholding attacks in the wild?
CW
16:41
Chun Wang
hashrate futures are interesting
16:42
not sure if we can build some easy to use product for miner use
16:42
yes
16:42
pretty bad and constant on our zcash pool
JR
16:42
Jeremy Rubin
This is actually an area where CTV helps BTW
16:43
Makes it simpler to open up decentralized hashrate futures on BTC
r
16:43
rocket_fuel
would it make sense to activate op_ctv on a bitcoin-based alt first?
JR
16:43
Jeremy Rubin
I mean I would *love* to get it done on LTC
r
16:43
rocket_fuel
dont even need to run a testnet, test right in production
CW
16:44
Chun Wang
you gonna find AI classifier collect all data from ip to mouse movement to tell who’s the attacker :)
r
16:44
rocket_fuel
nobody really cares about ltc
JR
16:44
Jeremy Rubin
it's just the closest to BTC
r
16:44
rocket_fuel
lets get charlie lee in here
16:44
so useful to have alts with BDFLs
E
16:44
Eric Lombrozo
The activation path on BTC may turn out to be very different, but at least the tech can be tried out (risk category 1)
JR
16:45
Jeremy Rubin
Feel free to add him I don't have his handle here
E
16:46
Eric Meltzer
In reply to this message
do people agree/disagree with this?
16:46
imo it changes the optimal approach of anyone wanting to add something to btc alot
16:46
from justifying via benefits to explaining why the risk is insanely minimal/nonexistent
JR
16:46
Jeremy Rubin
I disagree
E
16:46
Eric Lombrozo
I am almost convinced at this point that the activation path for BTC will require a widespread perception that there is an existential threat
JR
16:46
Jeremy Rubin
Only because I implemented CTV in the risk minimized version at first
16:47
and majority of devs told me to make the design a bit more risky to gain features
16:47
so at least with CTV the minimal risk side I think is roughly already delivered
16:48
but that also could just be suggestions to change the design within the scope of a risk band
E
16:48
Eric Lombrozo
If CTV doesn't resolve a perceived crisis, it will have to piggyback off the activation of something else
JR
16:49
Jeremy Rubin
@CodeShark what's solving a crisis right now?
16:49
And I don't want to be a doomsday salesman but I do believe this is true for CTV
E
16:49
Eric Lombrozo
Right now things are fairly peaceful on the Bitcoin network itself
JR
16:49
Jeremy Rubin
But I don't want to be seen as FUDDING to get a change done
E
16:50
Eric Lombrozo
Right, it would have to be prepared in advance of the crisis
JR
16:50
Jeremy Rubin
And I think trying to get changes done during a crisis makes us much more vulnerable to mob-rule fascist-led bad decisionmaking
Charlie Lee invited Charlie Lee
r
16:51
rocket_fuel
arise chikun
JR
16:51
Jeremy Rubin
Hi Charlie!
CL
16:51
Charlie Lee
Hey guys
E
16:51
Eric Lombrozo
Hi charlie
JR
16:52
Jeremy Rubin
We're talking in here about BIP-119 (see https://utxos.org) and what it might take to get it through on BTC.
16:53
And were curious for your perspective on what doing a CTV fork would look like for LTC
E
16:53
Eric Lombrozo
In reply to this message
This seems to be a fundamental issue with governance generally. People generally don't care until it's late, and then they overreact
JR
16:54
Jeremy Rubin
I mean i guess one tangible outcome is at least agreement within an in-group that it's not unreasonable to pose CTV as a mitigation to an impending crisis?
16:54
And there are a few of these impending crises that I think CTV helps with
16:55
So even if it takes till crisis manifest to get it done, we've at least set it up as a reviewed default option change that can be rolled out
r
16:55
rocket_fuel
In reply to this message
that's what roadmaps are for
E
16:55
Eric Lombrozo
It may be possible to craft a coherent narrative in that respect, but you'll have to dumb down your explanation of it to something that fits in a single tweet
16:56
Most people will never bother to even attempt to understand how CTV actually works
JR
16:56
Jeremy Rubin
Can I use polls for an extra 100 chars?
16:56
;)
E
16:56
Eric Lombrozo
Hah
JR
16:56
Jeremy Rubin
It's hard to distill to a single tweet.
r
16:56
rocket_fuel
In reply to this message
more risky how?
JR
16:56
Jeremy Rubin
Can you describe Segwit as such?
16:57
Or CLTV, CSV, etc?
r
16:57
rocket_fuel
In reply to this message
take a screenshot, post the image
JR
16:57
Jeremy Rubin
Or just a different era?
E
16:57
Eric Lombrozo
Let me restate
JR
16:57
Jeremy Rubin
I mean I think a similar change is like why do people upgrade to 3g to 4g to 5g phones
16:58
I honestly have no fucking clue why one is better than the next but number go up must be better
16:58
So do I just call it Bitcoin2.0 and call it a day ;)
E
16:58
Eric Lombrozo
You obviously cannot explain something like this in a single tweet. Effective campaigns are actually not really about explaining anything
r
16:58
rocket_fuel
Segwit 2.0
E
16:59
Eric Lombrozo
No, I think we should retire that brand...lol
JR
16:59
Jeremy Rubin
I mean Segregated Outputs is a legitimate name for it :p
r
16:59
rocket_fuel
In reply to this message
you aren't going to convince developers with slogans
JR
16:59
Jeremy Rubin
If we want to talk piggy backing.
16:59
But I think we never should have used that word in core
r
16:59
rocket_fuel
i think jeremy's right in that an in-group buy-in is needed first.
JR
16:59
Jeremy Rubin
I think it's mostly not in the codebase though.
r
16:59
rocket_fuel
proving it live on LTC would be another good step
E
16:59
Eric Lombrozo
The strategy to convince developers is very different than the one to convince the general public
r
17:00
rocket_fuel
In reply to this message
gen public doesn't even know about CTV, even somewhat bitcoin-y people
17:00
very superficially at best
17:00
(and even then its rare)
JR
17:00
Jeremy Rubin
I mean do we just brand it as a risk-free block size increase to non-devs?
r
17:01
rocket_fuel
maybe define groups we are positioning this to in the first place
17:01
are LN people devs or not dev
JR
17:01
Jeremy Rubin
It doesn't capture the benefits for self-sovereignty and custody though.
r
17:01
rocket_fuel
i'd imagine it would be at least: "core devs", "ln devs", "app devs", "wallet devs", "gen pub/john doe"
E
17:01
Eric Lombrozo
The appeal to the general public would have to be that CTV will prevent a particular horrible scenario that people fear.
Jc Crown invited Jc Crown
E
17:02
Eric Lombrozo
And the general public will defer to trusted authorities
JR
17:02
Jeremy Rubin
CTV prevents people from stealing your bitcoin.
17:02
:)
E
17:02
Eric Lombrozo
It would have to be a somewhat concrete threat. Even if unlikely, they have to imagine the horror of being in that situation
17:03
Sorta like the horror of dying from covid
r
17:03
rocket_fuel
In reply to this message
vaults/custody improvements is a good angle, imo, for gen pub.
17:03
also fee stability
17:03
more predictability in fees is always good
E
17:03
Eric Lombrozo
But none of these are existential threats
r
17:03
rocket_fuel
channel factories/htlc etc might be too technical
E
17:03
Eric Lombrozo
Most people just won't give a fuck
DV
17:04
David V
In reply to this message
zcash might do it
r
17:04
rocket_fuel
In reply to this message
most gen pub doesn't care about crypto, if you really want to go there
E
17:04
Eric Lombrozo
They care when their own bottom line is on the line
r
17:04
rocket_fuel
In reply to this message
key management is pretty existential, dont you think? unless losing your stash is nbd
JP
17:05
James Prestwich
In reply to this message
zcash won't do anything that expands Script
E
17:05
Eric Lombrozo
The problem is that hypothetical risks are ignored by people unless they have a more concrete example
r
17:05
rocket_fuel
In reply to this message
why is that?
17:05
In reply to this message
we've got 7 dollar fees right now.
17:05
we are way past hypotheticals here
17:06
unless by existential you mean "nobody uses bitcoin anymore" - then yeah we got some time to kill
JP
17:06
James Prestwich
In reply to this message
long-standing policy. goal is to deprecate non-shielded txns eventually, so why spend resources on them?
JR
17:06
Jeremy Rubin
In reply to this message
not sure that's true? Summoning 1 madars...
Jeremy Rubin invited Madars Virza
DV
17:06
David V
In reply to this message
oh I meant the pool thing lol
17:06
that's my mistake
E
17:06
Eric Lombrozo
Most of the market is still speculation, not low value purchases. The Bitcoin economy can bare even larger fees without serious existential risk
DV
17:07
David V
In reply to this message
can / needs to
r
17:07
rocket_fuel
In reply to this message
you still have to send to exchanges and from exchanges
DV
17:07
David V
if Bitcoin can't handle $30 fees per txn it's going to die anyway
E
17:07
Eric Lombrozo
*bear
JP
17:07
James Prestwich
In reply to this message
zcash doesn't have CSV for on-chain pool future stuff
17:07
or nsequence locks
JR
17:07
Jeremy Rubin
I think that's false David
17:07
The value per TX just has to be $30
r
17:07
rocket_fuel
In reply to this message
depends on how you define "transaction"
17:08
30 bucks for 100 channels open? I think we'll be ok. $30 bucks to open HTLC? might as well go full custodial
DV
17:08
David V
In reply to this message
depends on who you are
r
17:08
rocket_fuel
meh, $30 i thinkis OK still.
JR
17:08
Jeremy Rubin
(CTV helps make L2 stuff more efficient btw)
DV
17:08
David V
In reply to this message
I don't understand this
r
17:09
rocket_fuel
at $100, it becomes expensive enough even for $100k-1M txns
JP
17:10
James Prestwich
In reply to this message
transactions are made for some economic purpose, which can be assigned a marginal value for the sender(s). is that marginal value > the marginal price?
17:10
we're not just making transactions for funsies over here
17:10
(well, not usually)
JR
17:11
Jeremy Rubin
In reply to this message
Ok so if you're looking at a tx object with a $30 fee, it obviously prices out a lot of low value tx stuff that we currently do. But if Txs become more efficient, then you either decrease fees or increase value per tx. The value per tx should be greater than the fee, otherwise you wouldn't care to do it at all.
DV
17:11
David V
yeah but how does that get you mining security?
17:12
At the end of the day, some actual amount of money has to be funding mining security
r
17:12
rocket_fuel
In reply to this message
i wouldnt worry so much about mining security and fees. custodians must constantly rotate between hot wallet and cold
17:12
they don't have a choice
JR
17:12
Jeremy Rubin
So all I'm saying is that to sustain higher tx fees base layer we need to make them more efficient by actually making them more valuable. Otherwise solutions will compete e.g. custodial platforms
17:12
Which is a challenge to self-sovereignty and self custody
r
17:12
rocket_fuel
and at the amounts they roll, they are not very sensitive to prices
DV
17:12
David V
In reply to this message
sure, I agree with that
17:12
more valuable transactions = more able to tolerate high fees
JR
17:13
Jeremy Rubin
Lightning helps with that, CTV helps with that, CTV helps lightning with that
17:13
Non interactive channel opens makes it trivial to piggyback channel opens on every tx you make w/o any overhead.
17:14
It also allows you to mitigate the cost of transacting by waiting for a lower fee window
17:14
without giving up your confirmation window
17:14
(decongesting effect)
17:23
In reply to this message
I have to ask, what are your txs for then?
CL
17:29
Charlie Lee
Hey guys, I caught up a bit on this channel. So what's the current position on CTV by the various parties. Who in the core devs are for or against? How about ln devs?

I assume this can be done with a softfork and we can use BIP8 or BIP9, right? What are the downsides other than more complexity?
JR
17:32
Jeremy Rubin
So I don't think there are any core devs opposed to it on technical grounds -- I've talked with most and there's no serious objections, some residual concerns that people are thinking through. Greg has mentioned that he doesn't like how I'm advocating for the proposal though, and thinks there might be something more flexible. More flexibility has been echoed by Matt Corallo. I think I've mostly addressed their feedback on those. Other than that people seem positive. Among LN devs there's more excitement but people are less involved with core stuff. Laolu thinks it's great and gave some presentations discussing it.
r
17:33
rocket_fuel
In reply to this message
Charlie, I think there is a general apathy around it, no major objections from what it seems
JR
17:33
Jeremy Rubin
It can be done with BIP8/9 or whatever you like, just a NOP4 -> Verify upgrade
r
17:34
rocket_fuel
In reply to this message
I'd say the same mechanism should be leveraged that will be proposed for bitcoin, if possible
17:34
that way you have the deployment method covered as well
17:34
fewer things to nitpick
JR
17:34
Jeremy Rubin
good point. Hard to do as there's been a bit of a thing brewing of people wanting a new fork mechanism
r
17:36
rocket_fuel
why hard? nobody will go for bip8? (that woud be my preference)
JR
17:36
Jeremy Rubin
No matt wants to do his new plan, some people like it, others don't, others want bip 9, some want bip8, yet others think we just go back to flag days
r
17:37
rocket_fuel
jeez
17:37
then even more important to try the method on litecoin, im sure it cannot hurt to say "it worked"
JR
17:38
Jeremy Rubin
@coblee the main criticisms early on have mostly been addressed. Originally i had a more conservative design which Russel O'Connor had some issues with, but I addressed those like 9 month ago and the spec hasn't changed for a while now.
17:40
I think a good amount of the apathy is sort of a self-fulfilling prophecy type thing. Most of my in person convos are good (and people get pretty excited about it, e.g. at the workshop I hosted) but people are negative on getting changes into core
Guy Swann invited Guy Swann
JR
17:40
Jeremy Rubin
Hence maybe being a good opportunity for Litecoin to lead on deployment
CL
17:40
Charlie Lee
In reply to this message
What's Matt's new plan for upgrades?
JR
17:41
Jeremy Rubin
It's basically do BIP-9, if it fails, have a 6 month period, then do another BIP-9 or BIP-8
r
17:42
rocket_fuel
lol let people vote, and then if they vote wrong, just flag date anyway lol?
JR
17:42
Jeremy Rubin
My issue with it is it pushes the timeline for activation out for years and adds a defined period *after* the initial signalling rather than *before*. So the Game Theory I've looked at suggests that miners will just want to hold out till the 6 month period comes up to get influence in that period
r
17:42
rocket_fuel
why not just bip8 right away, whats his justification?
JR
17:42
Jeremy Rubin
let me find the mailing list post
HP
17:43
Hiro Protagonist
It’s not a vote. It’s a signal that they have made the preparations.
CL
17:43
Charlie Lee
In reply to this message
As you know, I'm always on board with having Litecoin help Bitcoin wherever we can. Just need to make sure the proposal is well peer reviewed. Implement in a way that keeps merges with Bitcoin simple if Bitcoin ends up not adopting it.
17:44
For Litecoin, I think a BIP8 with 1 year activation should work for something non-controversial like this. Give miners and exchanges 1 year to upgrade.
JR
17:44
Jeremy Rubin
yeah it can be minimally like 100-200 LOC + tests. If Bitcoin doesn't adopt it the issue would be that you have used the opcode as a NOP, but fortunately the CTV spec includes versioning for the argument
HP
17:44
Hiro Protagonist
Does litecoin ever have issues with the mempool filling up?
CL
17:44
Charlie Lee
In reply to this message
No
JR
17:45
Jeremy Rubin
I think the congestion control is less compelling for LTC, but the vault architecture stuff is better
CL
17:45
Charlie Lee
Not unless there's a spam attack
JR
17:45
Jeremy Rubin
I have some code for this, Bryan Bishop has stuff that's more formally released built on CTV
r
17:45
rocket_fuel
In reply to this message
unfairly cheap LN channels
CL
17:45
Charlie Lee
In reply to this message
Similar for SegWit. Litecoin didn't need SegWit for the block size increase.
HP
17:45
Hiro Protagonist
Spam attack is indistinguishable from stress test.
JR
17:46
Jeremy Rubin
This is a vault protocol that can be deployed using CTV, I'm working on a more general framework to develop and deploy similar stuff
HP
17:48
Hiro Protagonist
What is there so far in the way of a wallet that will be CTV aware?
JR
17:48
Jeremy Rubin
The patch to add basic CTV support is actually not too bad for a Core wallet.
17:48
I got the nasty part of it done because it was actually fixing a bug in core
17:53
@coblee I can try to prepare a LTC patchset and tests for you to look at if that helps
CL
17:56
Charlie Lee
So the process of getting something like this on Litecoin goes like this:
1) Get buy in from the Litecoin dev team. I can bring this up. I think they will be on board.
2) Get buy in from the community. For better or worse, the community generally goes along with what I recommend.
3) Help with implementation and testing.
JR
17:57
Jeremy Rubin
Cool. I'm happy to join a dev call or join an IRC or wherever to answer any questions from the LTC team.
r
18:20
rocket_fuel
excellent
CL
20:09
Charlie Lee
Is utxos.org the best play to learn about this?
r
20:10
rocket_fuel
its a good start. there is also a bip review workshop: https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/
20:10
pinned message has a bunch of links too: https://pastebin.com/3Q8MSwky
CL
20:12
Charlie Lee
Thx
JR
20:17
Jeremy Rubin
20:17
Chaincode podcast is good too
20:17
For a primer
DV
20:27
David V
In reply to this message
it's power to veto
20:27
whether or not it's supposed to be that way, that's one way for miners to see it
CL
20:28
Charlie Lee
With BIP8, it will UASF at the end of the activation period. So it's no longer a vote to veto. It's just a time for them to be prepared. If miners signal early, it will activate earlier.
22 May 2020
J
01:22
Jonas
Thanks for inviting...
I guess I have little to contribute in this discussion. Make probably not much sense for me to stick around here.
Alex L removed Alex L
Jonas removed Jonas
HP
03:42
Hiro Protagonist
In reply to this message
That’s what they thought it was until we showed them that a UASF could boycott their blocks and work if they tried to exercise a veto. Miners crumpled like a cheap tent in the face of that.
GS
04:08
Guy Swann
In reply to this message
If anyone else wants to come on Bitcoin Audible and talk about this I'd love to get into it.
O
06:13
Oriol
In reply to this message
This is correct, for miner-only activation. As long as an "economic significant" share of transaction recipients soft-fork too, then it's no longer upgraded miners 51%-attacking their unupgraded counterparts.

In that sense, I'm a bit surprised to see that the proposal for CTV is for a BIP-9 activation and not BIP-8.
HP
06:23
Hiro Protagonist
I actually think that in practice there’s no difference which activation proposal is put forward, because if it gets to the point where the actual functionality of the soft fork itself is merged, it will have meant that the devs and users want it. And if the devs and users want it, the miners cannot stop it. It adds excitement, drama, engagement and lots of emotion if the miners try to resist, but they cannot resist. BIP148 is a trump card that the miners simply cannot and will not fight.
JR
09:50
Jeremy Rubin
In reply to this message
Be sure to read the specific language there. The deployment params are given for completeness but the actual deployment is TBD.
r
11:04
rocket_fuel
In reply to this message
If exchanges/otc decide not to support it - who knows what the outcome will be, i don’t think it’s going to be that simple. Bitfinex helped a lot with UASF.
JC
11:05
Jc Crown
Segwit is easy not to support if you're an exchange
11:05
Particularly when it was new
r
11:06
rocket_fuel
Not to support the UASF. It wasn’t just users, exchanges and miners were also split.
11:06
Anyway we are not going there, this isn’t going to be a UASF.
CL
11:08
Charlie Lee
yes, exchanges have a lot of power. More than miners.
r
11:15
rocket_fuel
At the time of UASF it was the most powerful nodes, and I think a few exchanges that threw their support behind it - were the precipitating factor of the final outcome
CL
11:23
Charlie Lee
Agreed. Had to convince exchanges to adopt UASF or at least provide both forks so that there’s price discovery. Exchanges might be convinced if they think their traders want the soft fork, but consensus is hard to determine.
JR
11:37
Jeremy Rubin
I think there was a larger amount of material difference between segwit and non segwit as well as the fact that there were competing ideas of how we should fork
11:38
That doesn't really exist at this time
JC
11:41
Jc Crown
I was going to nitpick but you're right of course, exchanges get a "big vote"
r
11:46
rocket_fuel
In reply to this message
I don’t think there is any real opposition aside from self-imposed ossification
23 May 2020
Trills KD invited Trills KD
JR
12:49
Jeremy Rubin
In reply to this message
Yep
12:49
JP
12:51
James Prestwich
hi I'm james
JR
12:51
Jeremy Rubin
You wrote the thing @rocket_fuel linked haha
Jeremy Rubin invited Hasu
HP
12:52
Hiro Protagonist
Hi James.
Jeremy Rubin invited Brandon Curtis
r
13:22
rocket_fuel
Nice didn’t notice James was here
13:29
Hi James!
JP
13:33
James Prestwich
👋
Jeremy Rubin invited Alex Bosworth