bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshs_ has quit [Ping timeout: 252 seconds]
saranshsharma has joined #bitcoin-core-dev
saranshs_ has joined #bitcoin-core-dev
saranshsharma has quit [Read error: Connection reset by peer]
AaronvanW has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<yanmaani>
In #10609, it says "getrawtransaction currently works with pruned nodes as long as the transaction has at least one unspent output. I believe this functionality is deprecated though."
<yanmaani>
Also, would it be OK to send in a PR that relied on this behaviour and, I suppose, un-deprecated it? Specifically for adding support for non-wallet inputs into fundrawtransaction, which is explicitly marked TODO.
<sipa>
i don't see what those have to do with each other
<sipa>
why does fundrawtransaction need to be able to look up a TX?
<yanmaani>
sipa: Because it has to know the size needed to spend an input.
<yanmaani>
If it's a wallet TX, this is fine. If it's a full TX, this is fine. But if it has just the vout, then it has to look up the full TX.
<sipa>
i don't understand
<yanmaani>
And the database will only have vout -> block. This means it wouldn't work on pruned.
<sipa>
why does the size of the TX that created a UTXO matter?
<yanmaani>
If I call FRT with a non-wallet input, it will currently error.
<yanmaani>
sipa: not the size, but the size to spend it.
<sipa>
that's the transaction you're constructing; nothing needs to be looked up...
<yanmaani>
sipa: if it's a non-wallet input, I don't think I have that info?
<sipa>
well maybe be a bit more concrete... what are you trying to do?
<sipa>
how are you going to instruct fundrawtransaction to include a non-wallet TX?
<yanmaani>
sipa: add support for non-wallet inputs in fundrawtransaction
<yanmaani>
by passing in a transaction that contains a non-wallet input
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
<yanmaani>
something that I can do right now, but will unconditionally give "insufficient funds" error.
<sipa>
i'm rather confused
<sipa>
you can't pass in a transaction, you need to somehow make it find a UTXO to spend
<sipa>
the simplest way would be giving txid:vout
<sipa>
or giving it a UTXO directly, even
<yanmaani>
sipa: fundrawtransaction takes a transaction passed in.
<sipa>
oh, i see
<yanmaani>
If some of these transactions are not ours, it should still be able to fund it. E.g. transaction with 1btc in (from non-wallet), 2btc out, it should be able to add 0.999 or whatever.
<meshcollider>
yanmaani: you might be interested in #17211
<gribble>
https://github.com/bitcoin/bitcoin/issues/17211 | Allow fundrawtransaction and walletcreatefundedpsbt to take external inputs by achow101 · Pull Request #17211 · bitcoin/bitcoin · GitHub
<yanmaani>
so see line 462 on src/wallet/spend.cpp
<sipa>
i still don't see what this has to do with looking up transactions though
saranshs_ has quit [Ping timeout: 265 seconds]
<meshcollider>
I think 17211 probably addresses what you're trying to do
<yanmaani>
meshcollider: yeah, I think so too. Do you know if it works if I send in an already-signed input?
<yanmaani>
e.g. 1btc external input, with signature, and then 2btc out. Or would I need to take the signture in and out?
saranshsharma has joined #bitcoin-core-dev
<sipa>
if you add extra inputs or outputs (which is what FRT does), it'll invalidate any signatures that are already there
<achow101>
yanmaani: including non-wallet inputs in fundrawtransaction needs more than just being able to look up the transcation. In fact, looking up the transaction is completely unnecessary - the UTXO set is enough. The problem with non-wallet inputs is that data specific to the owning wallet is missing. This data is things like scripts and pubkeys. These cannot be retrieved from previous transactions. 17211 solves that by allowing users to provide
<achow101>
that data.
<yanmaani>
sipa: yes, but still hopefully use them for calc?
<achow101>
yanmaani: you can't pass in scriptSigs or scriptWitnesses
<achow101>
they will be clobbered
<yanmaani>
achow101: Oh, so it can't use them for fee calc?
<yanmaani>
like, if I give it a half-signed tx, you'd think it could figure out that "hmm, it uses 89 bytes to spend it here, maybe it costs 89 bytes to spend??"
<yanmaani>
(and then discard that siggy anyway, but still use the information in it)
<achow101>
they will be ignored
<achow101>
entirely
<yanmaani>
mmm, even in 17211?
<achow101>
yes
<yanmaani>
still works tho, i suppose, just have to pass in separately.
<achow101>
with variable signatures sizes, there is no guarantee that any signatures will have the same size afterwards
<yanmaani>
variable signature sizes?
<achow101>
the signature size can vary
<achow101>
DER allows signatures to have a variable size. This size will be dependent on all inputs to the signature algorithm, so if any of those change (e.g. the tx changes), then the size will not be known until the signatures is computed
<achow101>
(taproot fixes that problem, but at the same time, if all solving data is present, then it will be possible to predict the same size anyways)
<yanmaani>
achow101: but what about SIGHASH_SINGLE etc?
<yanmaani>
then the inputs will be known in advance
<sipa>
SIGHASH_ANYONECANPAY signature in theory stay valid when adding inputs
<achow101>
fundrawtransaction may still add a change output
<yanmaani>
if I have a tx, 1btc in, 2btc out, and I sign "this goes in and 2btc to here" with key A, then add 0.999btc and sign with multiple
<sipa>
and SIGHASH_SINGLE/NONE signature stay valid when adding outputs
<yanmaani>
achow101: yeah, but that won't have any bearing on the existing sigs.
darosior0 has joined #bitcoin-core-dev
<achow101>
yanmaani: depending on your sighash, outputs will have an effect on the message that is signed
<sipa>
but fundrawtransaction will also insert change output in a random place if needed, which would break SIGHASH_SINGLE too
<yanmaani>
sipa: couldn't it just insert the extra input in the same place?
<achow101>
(when I said inputs, I meant "signed messsage", not tx inputs)
tinova4 has joined #bitcoin-core-dev
<sipa>
yanmaani: it could do lots of things, but doesn't
<yanmaani>
achow101: yeah, but if it's a sighash where adding new outputs won't affect anything?
gnaf_ has joined #bitcoin-core-dev
<yanmaani>
sipa: right, but a poor man's (smaller) version of 17211 that only works with already signed inputs with the correct sighash, would not be of interest?
<achow101>
non SIGHASH_ALL sighashes are not generally optimized for due to the extra complexity and the fact that few people use them
real_or_random_ has joined #bitcoin-core-dev
belcher_ has joined #bitcoin-core-dev
<achow101>
yanmaani: I would nack it
midnight_ has joined #bitcoin-core-dev
<yanmaani>
achow101: because it's intrinsically bad or just because 17211 already does it better?
ryanofsky_ has joined #bitcoin-core-dev
michaelfolkson2 has joined #bitcoin-core-dev
saranshs_ has joined #bitcoin-core-dev
Keele_ has joined #bitcoin-core-dev
face_ has joined #bitcoin-core-dev
da2ce7 has joined #bitcoin-core-dev
cfields has joined #bitcoin-core-dev
<achow101>
both
Henry151_ has joined #bitcoin-core-dev
_cold has joined #bitcoin-core-dev
<achow101>
as noted above, the size given existing signatures is not guaranteed after the transaction is modified. I think there is exactly one case where the signature would not change and it also requires fundrawtransaction to do a very specific modification
<achow101>
because it needs a very specific set of circumstances, such a feature would not be particularly useful, and figuring the exact changes that were made that would allow for the signature to not change would be somewhat complex and difficult to review.
saranshsharma has quit [*.net *.split]
belcher has quit [*.net *.split]
gnaf has quit [*.net *.split]
cfields_ has quit [*.net *.split]
ryanofsky has quit [*.net *.split]
Henry151 has quit [*.net *.split]
Keele has quit [*.net *.split]
michaelfolkson has quit [*.net *.split]
da2ce7_ has quit [*.net *.split]
jonatack has quit [*.net *.split]
cold has quit [*.net *.split]
midnight has quit [*.net *.split]
face has quit [*.net *.split]
darosior has quit [*.net *.split]
tinova has quit [*.net *.split]
real_or_random has quit [*.net *.split]
ryanofsky_ is now known as ryanofsky
tinova4 is now known as tinova
darosior0 is now known as darosior
TallTim_ has joined #bitcoin-core-dev
ravish0007_ has joined #bitcoin-core-dev
ravish0007 has quit [Ping timeout: 252 seconds]
Henry151_ has quit [Ping timeout: 252 seconds]
TallTim has quit [Ping timeout: 252 seconds]
mikehu44 has quit [Ping timeout: 252 seconds]
DeanGuss has quit [Ping timeout: 252 seconds]
Victorsueca has quit [Ping timeout: 252 seconds]
Henry151 has joined #bitcoin-core-dev
DeanGuss has joined #bitcoin-core-dev
DeanGuss has quit [Changing host]
DeanGuss has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 252 seconds]
mikehu44 has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
darosior has quit [Ping timeout: 252 seconds]
darosior has joined #bitcoin-core-dev
meshcoll- has joined #bitcoin-core-dev
haakon_ has joined #bitcoin-core-dev
gleb77 has joined #bitcoin-core-dev
berndj-blackout has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
meshcollider has quit [Ping timeout: 252 seconds]
haakon has quit [Ping timeout: 252 seconds]
sugarpuff__ has joined #bitcoin-core-dev
amiti has quit [Ping timeout: 252 seconds]
berndj has quit [Ping timeout: 252 seconds]
kanzure has quit [Ping timeout: 252 seconds]
sugarpuff_ has quit [Ping timeout: 252 seconds]
sugarpuff__ is now known as sugarpuff_
gleb7 has quit [Ping timeout: 252 seconds]
gleb77 is now known as gleb7
amiti has joined #bitcoin-core-dev
kanzure has joined #bitcoin-core-dev
nanotube has quit [Ping timeout: 252 seconds]
nanotube has joined #bitcoin-core-dev
upekkha has quit [Ping timeout: 252 seconds]
greypw25 has joined #bitcoin-core-dev
upekkha has joined #bitcoin-core-dev
berndj-blackout is now known as berndj
jonasschnelli_ has joined #bitcoin-core-dev
michaelfolkson has joined #bitcoin-core-dev
schmidty_ has joined #bitcoin-core-dev
gribble has quit [Ping timeout: 252 seconds]
TallTim_ has quit [Read error: Connection reset by peer]
Jaamg has quit [Ping timeout: 252 seconds]
greypw2 has quit [Ping timeout: 252 seconds]
jonasschnelli has quit [Ping timeout: 252 seconds]
jkczyz has quit [Ping timeout: 252 seconds]
schmidty has quit [Ping timeout: 252 seconds]
michaelfolkson2 has quit [Ping timeout: 252 seconds]
tinova has quit [Quit: Ping timeout (120 seconds)]
schmidty_ is now known as schmidty
dvd has quit [Ping timeout: 252 seconds]
tinova has joined #bitcoin-core-dev
dvd has joined #bitcoin-core-dev
jkczyz has joined #bitcoin-core-dev
TallTim__ has joined #bitcoin-core-dev
saranshs_ has quit [Ping timeout: 252 seconds]
Jaamg_ has joined #bitcoin-core-dev
c_arc has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
Henry151 has quit [Ping timeout: 252 seconds]
paulo has joined #bitcoin-core-dev
<yanmaani>
achow101: that's a fair point. What about allowing it to fund regardless, but accepting that users are obliged to manually specify change position etc if they use this feature?
Henry151 has joined #bitcoin-core-dev
<yanmaani>
and then just saying that if users put in the wrong params, they break the signature
<achow101>
there's more to it than just the change position
<achow101>
inputs are shuffled too
<achow101>
so if any inputs are added, they may be added in any position
<yanmaani>
isn't there a param to regulate that?
<achow101>
no
meshcoll- has quit [Ping timeout: 252 seconds]
<yanmaani>
there is "don't add inputs". i mean you could use it like
meshcollider has joined #bitcoin-core-dev
<yanmaani>
1) fund
<yanmaani>
2) shuffle inputs back into the right order
<yanmaani>
3) fund again, select "Don't add inputs"
<yanmaani>
so then all that's needed is making sure the change won't destroy anything, in theory?
<yanmaani>
like putting it after the concerned outputs
<achow101>
no, that's not necessarily safe
<achow101>
a sighash_single input with no corresponding output could be clobbered by that, and there's no way around it if a change output must be added
<achow101>
e.g. 3 inputs, 2 outputs, with the last being sighash single. if a change output must be added, the sighash will necessarily change because of the way sighash_single works
<achow101>
regardless of the position of the change output
<achow101>
yanmaani: what are you trying to do that this complexity makes sense to do?
<yanmaani>
Wait, a "a sighash_single input with no corresponding output", how is that even valid?
<yanmaani>
is it just signing ... nothing?
saranshsharma has joined #bitcoin-core-dev
<achow101>
it signs the number "1" (expanded to 256 bits)
<yanmaani>
oh, and is that valid?
laanwj has quit [Ping timeout: 252 seconds]
<yanmaani>
if so, you would just have to not allow sighash_single
<achow101>
yes, it's kind of a bug
laanwj has joined #bitcoin-core-dev
saranshsharma has quit [Read error: Connection reset by peer]
<achow101>
I don't think going through the effort to implement this is any less than just trying to get 17211 through
<yanmaani>
or, you could, but error if you have to add new outputs.
<yanmaani>
yeah, at that point you're not really dealing with a "smaller, easier" version really
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
prayank: I agree more should be discussed openly even when it is uncomfortable and more time consuming. I definitely feel some are pushing consistently to not have any discussion in public and that makes me uncomfortable
<michaelfolkson>
prayank: Having said that I don't think storing up a list of feedback for an individual and drop it when they are proposed as a maintainer isn't the best way to provide feedback
<michaelfolkson>
*is the best way
<michaelfolkson>
If you don't like something someone has done you should feel free to raise it here or on the mailing list at the time
mikehu44 has quit [Read error: Connection reset by peer]
mikehu44 has joined #bitcoin-core-dev
<michaelfolkson>
I'd like fanquake to engage here with prayank on the specific concerns he's raised. And prayank to provide specific details of the PR numbers etc so he can take a look at them
mikehu44 has quit [Read error: Connection reset by peer]
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
Although this is proposed to fight spam it is a significant increase in permissions over the repo. It is a shame GitHub doesn't have more finegrained permissions
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
On the Taproot activation params issue I think it is unfair to pin that responsibility on one maintainer because he merged it. No other maintainer has commented afaik that they disagreed with the merge decision
<michaelfolkson>
If another maintainer had commented that they had disagreed with the merge decision then we would be in a different place. But they haven't and so in that sense I think it can be perceived as a maintainer team decision rather than an individual maintainer decision
<michaelfolkson>
Anyone is free to disagree with that decision but using that as a reason to not give someone more permissions seems unfair to me
mikehu44 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
<darosior>
+1 on giving more permissions to fanquake.
<darosior>
These accusations on Taproot activation strike me as backed by the belief that maintainers would decide the network rules. Correct me if i'm wrong but code is integrated to the repo after being evaluated on a technical basis, not a political one. The PR was reviewed and acknowledged as technically right by contributors knowledgeable in this area.
<darosior>
Another (pretty confused) objection was raised. I would like to ask the objector to first clarify any *objective* concern they might have and second to explain how the proposed increase in permission would make any concern worse (if there is any valid one in the first place).
<darosior>
As such i think this makes any objection to giving a maintainer more permission based on the merge of this PR invalid.
Henrik has joined #bitcoin-core-dev
Henrik has quit [Client Quit]
mikehu44 has joined #bitcoin-core-dev
<michaelfolkson>
darosior: I wouldn't say "political" but there is definitely a community consensus element to decisions like activation params
<michaelfolkson>
Some decisions have technical arguments on both sides. Doesn't mean that that is somehow political and avoiding technical discussion
<michaelfolkson>
There is also assessing the ACKs, NACKs on a PR which has a lot of subtlety when deciding on whether or when to merge a PR. Again I wouldn't call that political but you can if you want
<michaelfolkson>
For example you are free to disagree with Luke but it would be hard to claim he is not a contributor knowledgeable in the area of soft fork activation
mikehu44 has quit [Ping timeout: 252 seconds]
<michaelfolkson>
And for the record I don't have a problem with the activation params merge decision. I thought it was the slightly inferior solution and thought Luke had strong arguments but based on reviews I don't think it was wrong to merge it
<darosior>
On your last point: i certainly don't claim this, fwiw. His disapproval of 21686 wasn't based on any technical basis?
<darosior>
But i don't want to rehash this again tbf :)
<michaelfolkson>
darosior: "His disapproval of 21686 wasn't based on any technical basis?" I think it was more community consensus but then that community consensus was built up initially around a technical solution (BIP 8). And he thought BIP 8 was superior that what was merged
<michaelfolkson>
darosior: But yeah rehashing history :)
Henrik has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
I'm also a +1 on fanquake permissions
mikehu44 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
mikehu44 has quit [Read error: Connection reset by peer]
<jarolrod>
fanquake is a very active maintainer for a decent amount of time now. fanquake is almost always the first to get rid of spam issues and comments. I don't understand opposition to allow him to deal with spam users.
<fjahr>
+1 for giving required permissions to block spammers to fanquake. I think he is doing great work as a maintainer.
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Henrik has joined #bitcoin-core-dev
<TallTim>
Slow sunday question - Is Taproot "active" at blockheight 709,632 - I realize its locked in...
<TallTim>
Given that we're approx 703,390 now
<sipa>
6 weeks
<TallTim>
roger that
<sipa>
+- nov 16th
<michaelfolkson>
jarolrod: This isn't specific to fanquake but this is a significant increase in permissions due to lack of granularity in GitHub permissions. I don't think there is a problem to have a discussion on concerns people have
<michaelfolkson>
If there was a GitHub permission to just deal with spam this would be a no brainer
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]