<sipa>
which has now been updated to have no observable changes; it only adds the V2Transport class, and reuses the transport-can-talk-to-transport fuzz test from the previous PR
<achow101>
this is everything in bip324 but without actually using it?
<sipa>
almost everything, yes
<sipa>
except service flags, connection/reconnection logic, rpc stuff, ...
<sipa>
and more high-level tests
<PaperSword>
Is there any way I could help with this? Testing?
<achow101>
is there a way to turn it on to test with it?
<sipa>
for some of that, i just opened #28331, which is functionally complete and testavle
realies has quit [Read error: Connection reset by peer]
realies9 is now known as realies
<achow101>
would that be considered the last pr in this project?
<sipa>
there is also stratospher's bip324 implementation in test framework, and tests using it
<sipa>
which i plan to leave out of 28331, but my plan is to work now on adding unit and functional tests (which don't require bip324 in python) to 28331
andrew_mo_ has quit [Ping timeout: 252 seconds]
<lightlike>
so it might be realistic that it could make it into v26 ? at least optionally?
<achow101>
cool to see that we're nearing completion
<sipa>
so i think 28331 will probably be my last big PR relating to bip324
<sipa>
i'm probably going to start running 28331 on my own nodes, so others can test with
andrew_mo_ has joined #bitcoin-core-dev
<sipa>
lightlike: maybe it could be default off in v26
<lightlike>
that would be great!
<sipa>
but otherwise complete
<fanquake>
5 weeks left to get changes in to make that happen
Guest59 has joined #bitcoin-core-dev
<luke-jr>
off = won't be used even if the peer insists?
<sipa>
fanquake: 2 Weeks(tm) for PR, doable right?
<fanquake>
doable
<sipa>
luke-jr: what 28331 implements is a -v2transport option; without it, no v2 is used ever
jamesob443688173 has joined #bitcoin-core-dev
<luke-jr>
would be nice to have a mode where it's used if the peer requests it
<sipa>
with it, it's used on inbound when the peer seems to be using it, and on outbound when service flag present
<sipa>
luke-jr: that's doable
<sipa>
just use it on inbound
jamesob has joined #bitcoin-core-dev
Guest59 has quit [Client Quit]
<sipa>
ok, i think details can be discussed on the PRs
<sipa>
any other questions? otherwise end of my topic
<furszy>
so the node connects to bip324 peers because of a change in the desirable services flags?
<real_or_random>
oops, wrong channel. I wanted to post this in #secp256k1. but it's fun here too
<sipa>
:D
<preimage>
nice
realies2 has joined #bitcoin-core-dev
realies has quit [Quit: Ping timeout (120 seconds)]
realies2 is now known as realies
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_m_ has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
PaperSword has quit [Quit: PaperSword]
mudsip has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
mudsip has quit []
andrew_m_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
bitdex has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 245 seconds]
jon_atack has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
vysn has joined #bitcoin-core-dev
test_ has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
test__ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 246 seconds]
<PaperSword>
Is Solver safe to use for consensus critical code, example using Solver to determine a TX type for isUnspenable?
flooded has joined #bitcoin-core-dev
<sipa>
it's certainly not designed for that
<sipa>
and "tx type" isn't something that has meaning in consensus either
test_ has quit [Ping timeout: 252 seconds]
test_ has joined #bitcoin-core-dev
<PaperSword>
Sorry for my use of improper langauge, outpoint script type
<sipa>
that too does not exist in consensus
<sipa>
they're all just scripts
test__ has quit [Ping timeout: 258 seconds]
<sipa>
at least there is no distinction between e.g. P2MS, P2PK, P2PKH for example, from the perspective of consensus rules
<sipa>
it just executes the script
<PaperSword>
Thank you, but for example OP_RETURN as a script is provably unspendable. What would I call the act of Core determining that it's unspendable in order to prune. I thought of it as a 'type'
<PaperSword>
So is consensus the wrong term? The script/script.cpp is part of lib_consensus that is why I am asking
flooded has quit [Ping timeout: 246 seconds]
<sipa>
there is CScript::IsUnspendable
<PaperSword>
Yep that is what I am working with
<PaperSword>
Currently the conditions are OP_RETURN and Script size
<sipa>
right
<sipa>
i would nack any use of Solver inside IsUnspendable for that, i think
<sipa>
because that function is for policy/utility use, not consensus, and isn't designed with the same level of accuracy in mind
<sipa>
for experimenting of course, go wild
<PaperSword>
I made a really rough implementation that used Solver to determine if there is a P2MS or P2PK, the validiated the pubkeys in vSolutions using idFullyValid() if the script cant reach threshold to sign it's marked as unspendable thus pruning it from the UTXO set
ZeroMaster has quit [Ping timeout: 245 seconds]
<PaperSword>
Right now I am just messing around... still the idea has me a bit captivated. Also working out the potential issues of a reduced UTXO set size even if those entries were provably unspendable.
<PaperSword>
pretty sure it would be considered a soft-fork?
<sipa>
i certainly hope not
<sipa>
if it is, you're doing something wrong
<sipa>
as pruning unspendable things should be unobservable - spending them is already impossible
<PaperSword>
My thought if there is a modification to the OP Code later on...
<sipa>
irrelevant
<PaperSword>
Becuase the miners are what matter in that case?
<sipa>
no
<PaperSword>
okay
<PaperSword>
I will ponder this
<sipa>
because you have not made any change to consensus, period
<sipa>
(if you're doing it right)
<sipa>
the exact same set of potential blocks are valid and invalid, with or without your extra pruning
<PaperSword>
because the outpoints are provably unspenable.
<PaperSword>
as such no script could ever satisfy those conditions now or ever
<sipa>
right; if they're known to be unspendable at creation time, they don't need to be kept, because literally no valid block in the future could spend them
<sipa>
that's what provably unspendable means
<sipa>
so them being in the UTXO set or not is not observable by any future block
<PaperSword>
Just an off shoot is there any condition where an output is unspendable in theory but due to a bug is spendable?
<sipa>
then it's not unspendable
<sipa>
doesn't matter what the cause is
<sipa>
the consensus rules are what the network implements, not what we think it ought to be
<PaperSword>
Agreed
<sipa>
so to get a patch that prunes additional unspendable outputs accepted, you better be very convincing that such outputs are absolutely unequivocally unconditionally unspendable already
<sipa>
but there certainly have been "bugs" if you can call them that way in consensus rules; e.g. the fact that OP_CHECKMULTISIG pops one additional argument from the stack is almost certainly unintentional (and early, likely just unknown)
<PaperSword>
Of course, that has been the hardest part of this for me. In my mind it makes sense, but in practice there are always additional caveats to consider
<PaperSword>
Thank you for your insights, references, and thoughts :D
<sipa>
np
Zenton has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
vysn has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<PaperSword>
Okay one last followup, is isFullyValid() exhaustive?
brunoerg has quit [Ping timeout: 240 seconds]
<sipa>
in what sense?
<sipa>
i assume yes; it's true in case there exists a corresponding valid private key for that public key (which may be unfindable computationally)
BlueMatt_ has quit [Quit: Quit]
BlueMatt has joined #bitcoin-core-dev
<PaperSword>
That is the sense, that if fullyvalid returns false, then with certainty it's not a valid public key.
<PaperSword>
returns false for given pubkey*
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
<PaperSword>
I understand it's not possible to go from pub->priv, but for an example lets say a user creates a p2pk script, does a value of 10,000,000,000, broadcasts, has mined into block. He then realizes that while inputing his pubkey into the python script he wrote that there was an 'E' instead of 'F'. He then wants to see if there is any way of maybe in the future recovering his money. So he runs
<PaperSword>
isFullyValid() on his pubkey... and it returns false. Would it be provably certain he can not recover his funds?
andrew_mo_ has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
<sipa>
yes
<PaperSword>
Sweet! Now to break the news to a friend.
<sipa>
it returns false when the pubkey cannot be parsed by libsecp
<sipa>
that parsing happens also at signature verification time
brunoerg has quit [Ping timeout: 256 seconds]
<sipa>
and if it fails there, the signature is considered invalid
<PaperSword>
That is what I assumed, but wanted to verify; seems it runs isValid, if true it does a second check with secp256k1_ec_pubkey_parse(secp256k1_context_static, &pubkey, vch, size())
<PaperSword>
So using that logic, isFullyValid would be more consensus appropriate, than solver
andrew_mo_ has joined #bitcoin-core-dev
<PaperSword>
If you are inclined to answer this one as well, I have looked at BIP173 which you authored. You state that "string is at most 90 characters long..." then detail the spec of at min 1 hrp char, 1 separator, and 6 data chars. As such is the minimum length implied from the spec as 8 base32 chars?
andrew_mo_ has quit [Ping timeout: 252 seconds]
<sipa>
yes
<sipa>
but bip173 has tighter range requirements than just the bech32 ones
<sipa>
as witness programs are between 2 and 40 bytes in length
<PaperSword>
Mostly was wondering for the case of LocateErrors function in bech32.cpp, which you also authored ironically. As per the update to the witness program size I saw that when Macro Falke updated the possible errors for DecodeDestination
<PaperSword>
Currently using a short bech32 string just throws invalid separator position, also I think looking at blame you didn't author the LocateErrors and that came later on.
<PaperSword>
Marco Falke updated decode destination to handle the the witness program size properly and if there are errors handle them correctly*
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.0.3]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]