< kallewoof>
I'm amazed you guys let that go on for as long as it did.
< wumpus>
i was baffled, as in "it couldn't be *this* bad, right"
< wumpus>
despite all the rumors about toxicity in bitcoin development we have really very little drama compared to other large projects
< luke-jr>
heh
< luke-jr>
I wonder if it had gone further, if he would have demanded that payment is required for merging, via copyright stuff
< luke-jr>
(which tbh wouldn't be an entirely terrible idea for open source, but it just isn't acceptable in the current practice)
< luke-jr>
(thinking, if contributors and reviewers could put a $ amount on PRs, and then users paid to get them merged when ready)
< luke-jr>
s/$/BTC/ obviously
< wumpus>
there's the implicit requirement to submit a patch to an open source project, that it is available under the same license
< wumpus>
so in any case, such a thing would have to be coordinated outside of github, beforehand
< wumpus>
e.g. do a closed-source demo of something, and only if you have >X mBTC/$ in donations, release it as open source
< wumpus>
I've seen this done for some music-related software, never for cryptocurrency things though :)
< wumpus>
it works better if a development model revolves around plugins instead of patches
< luke-jr>
wumpus: I think it wouldn't work for us regardless, simply because of the review bottleneck
< wumpus>
right
< wumpus>
pay for review would be interesting, though also very corruption prone
< luke-jr>
pay-for-review doesn't seem too unreasonable right now even, actually
< luke-jr>
I wouldn't have any complaint with users posting bounties to get PRs they like reviewed sooner
< wumpus>
I'd again prefer this to be coordinated outside github
< provoostenator>
I put a few bounties on Bountysource a while ago, that seems the right way to coordinate these kinds of things, although I've only had limited success.
< provoostenator>
And it doesn't help that they were eaten up by some ICO with too much money.
< maitra>
bitcoind in regtest mode giving out empty responses to libbitcoinrpc RPC calls. Can someone help mw out here??
< maitra>
while switching back to testnet works fine. Valid JSONs are returned.
< sipa>
rafalcpp: if there were force pushes it's possible the code is no longer there
< gmaxwell>
achow101: Is it really the case that there is no way in the rpc to take the scriptpubkey and amount from scantxoutset and use that to create/populate a PSBT?
< achow101>
probably not. I haven't looked at scantxoutset yet
< gmaxwell>
it returns output that looks like listunspent
< sipa>
createpsbt ?
< gmaxwell>
but what I mean is that the createpsbt ignores scriptpubkey and amount, even if you provide them.
< sipa>
oh, i see
< achow101>
right now it only updates from the wallet
< achow101>
there's an open pr to update from the node
< achow101>
I can add to that updating from user provided data
< gmaxwell>
yea, at least just make it so create doesn't ignore them would be nice.
< sipa>
gmaxwell: it would lead to hard to analyse problems if it was a non-witness output being spent
< gmaxwell>
sipa: how so?
< sipa>
gmaxwell: for those it needs the full tx being spent, not just amount and sPK
< gmaxwell>
There is no way to bypass that?
< sipa>
no
< sipa>
signers need that information
< achow101>
gmaxwell: no, otherwise you could be tricked into signing something else
< gmaxwell>
oh jesus. I am not going to be tricked into signing something else.
< gmaxwell>
I understand how the bitcoin protocol works. I'm surprised that there isn't any way to bypass checking the inputs.
< gmaxwell>
esp since the existing raw transaction flow provides no way to do that at all.
< sipa>
heh, i guess there could be a "yes_i_verified_things_myself" option that skips the check in signing
< gmaxwell>
(no way for the offline signer to check the fee)
< sipa>
but you still need an updator first that understands the script being spent from
< sipa>
so just adding amount/sPK isn't enough
< achow101>
gmaxwell: sipa and I concluded that it was always safe to produce a segwit signature. so the problem is really with non-segwit
< achow101>
so if all of your inputs were segwit, you could bypass that check
< sipa>
my idea was to add an RPC that takes a list of descriptors, and updates using those from the UTXO set
< sipa>
which would only work for segwit inputs still
< gmaxwell>
Thats a good idea. You should still update non-segwit. Its up to the signer to decide if it has enough information.
< achow101>
gmaxwell: we can't because we cant always fetch full transactions
< gmaxwell>
...
< gmaxwell>
If you are updating from the UTXO set you can't provide full transactions. Absolutely. So don't.
< sipa>
gmaxwell: if you want to sign without checking, you don't need any information at all in the psby
< gmaxwell>
you need the scriptpubkeys.
< sipa>
righr
< gmaxwell>
I was hoping that this would replace an existing raw transaction workflow, but it not only doesn't but it seems not what you and achow are arguing with me.
< sipa>
but there is no way to add that information in the psbt without providing a full tx
< sipa>
there is a field for input data to a non-segwit input
< sipa>
and one for input to a segwit input
< sipa>
tbe first is a full tx, the second is amount/sPK
< gmaxwell>
Then PSBT as they are today cannot replace raw transactions.
< sipa>
you could fill segwit info from utxo data, even for non-segwit inputs
< sipa>
but i expect various pieces of software will break
< gmaxwell>
hm. it could correctly distinguish segwit from not based on the spk.
< gmaxwell>
Thats ugly.
< gmaxwell>
Better would be to just add a field type for non-sw utxo information, I think.
< sipa>
no
< sipa>
with a p2sh embedded segwit you can't tell
< gmaxwell>
oh, indeed.
< sipa>
i'm really scared about workflows that rely on unverifiable data
< gmaxwell>
In any case, for what I'm doing for the moment, my choices now are: download 200GB of blockchain OR give up on using PSBT and just use a plain raw tx workflow.
< gmaxwell>
So obviously I'm going to do the latter.
< sipa>
i'm sure there is another way
< gmaxwell>
I suppose I could also go to the system that already has the blockchain and do a 6 hour rescan to add the relevant inputs to the wallet.
< achow101>
gmaxwell: I don't quite follow what you are trying to do
< gmaxwell>
achow101: sweep a key that is on an offline machine. There isn't any risk of 'send the coins to fees' because I know apriori how much coins are there.
< sipa>
gmaxwell: well, right now, the implementation in bitcoin core isn't sufficient for non-wallet operation
< sipa>
just having utxo data isn't enough; you also meed an updator which knows the pubkeys used, the redeemscripts, ...
< sipa>
that could be provided by a descriptor, but isn't implemented yet
< gmaxwell>
this is easy to do with rawtx + scantxoutset (or rawtx + a block explorer), I was expect PSBT to simpify it at least slightly.
< sipa>
i'm sure it will, once there are a few extra RPCs
< achow101>
gmaxwell: it's only easy to do since you verified that the spk and amounts are correct. that's not something we can easily generalize
< gmaxwell>
I don't see how based on the above conversation?
< sipa>
gmaxwell: for segwit inputs, at least
< sipa>
there could also be a signer that lets you bypass safety checks
< sipa>
but i'm scared about that
< gmaxwell>
you managed to fail to be scared about that for years with that being the only way to use signrawtransaction. :)
< sipa>
gmaxwell: fair
< sipa>
though i think psbt aims at being convenient for slightly less sophisticated users
< gmaxwell>
well the alternative is implement stuff to take the uxto data and then go fetch pruned blocks from the network to get the inputs.
< gmaxwell>
so then at least there is a way to easily get the inputs.
< achow101>
ew
< sipa>
i don't think there is any harm in letting createpsbt take the amount/sPK and pass them through and create a segwit tx input field with those
< sipa>
which would be enough for an unsafe signer with knowledge of scripts/pubkeys to sign
< gmaxwell>
but as I'm saying, because of limitations in PSBT, even with being willing to modify the software to remove a check there is no way for this to replace raw tx in my existing workflow. I wouldn't _mind_ it putting the inputs in there, but there is no efficent way to get them on a pruned node.
< sipa>
gmaxwell: if the checks are dropped, it would work fine, no?
< sipa>
you wouldn't expect it to work in other software, though
< gmaxwell>
Yes, if you could pass along the data and bypass the checks it would work fine. Though a way of fetching the information on a pruned node would be more general (e.g. would work with hardware wallets that don't have a bypass)
< andytoshi>
i think PSBT should have an extension to support gmaxwell's workflow .. even if the new field names have "unsafe" in them or something
< andytoshi>
or maybe this is purely about core RPC, and not PSBT itself
< gmaxwell>
sadly it sounds like PSBT needs an extension if its to accomidate this.
< gmaxwell>
('this' being unchecked signing)
< andytoshi>
right .. it would be good if there was an "amount_unsafe" field or something that you could fill in, and if signers had good reason to trust it, they could use it
< sipa>
there is no need for amount data
< sipa>
only scriptPubKey
< jonasschnelli>
kanzure: is there an issue with the bitcoin-dev mailing? I sent an email 7h, but got nothing back from the list
< gmaxwell>
they can use the amount_unsafe data to display/check fees.
< sipa>
gmaxwell: that seems unwise
< sipa>
the only reason the data is there is so it can be verified
< sipa>
if you bypass that, and are willing to vouch you yourself did sufficient checking, that doesn't seem needed
< andytoshi>
sipa: it does if you want a hardware wallet that does fee-checking, and its only means of communication is by PSBT
< andytoshi>
otherwise you need an extra transport to pass it pre-verified daa
< andytoshi>
data
< sipa>
andytoshi: it can't fee check if the amount isn't verified
< gmaxwell>
sipa: the 'checking' of that part was done at an earlier stage.
< andytoshi>
it sounds like gmax verified it when he made the transactions, and then didn't keep the transactions around..
< sipa>
i'm confused
< sipa>
if you verified the fee data outside the hsm already, why do you need to tell it the amount?
< gmaxwell>
sipa: only UI convience wise.
< sipa>
gmaxwell: again, that seems unwise if it's unverified
< sipa>
i think the hw signer should just say "unverifiable data, agree to sign anyway?"
< andytoshi>
and the user can use a pocket calculator for the fee?
< gmaxwell>
In any case, I don't have a specific need for an unverifyed sign. I just need EITHER an unverfied sign, or a easy way to provide using a pruned node input tx for arbritary scriptpubkey that exist in the utxo set.
< sipa>
andytoshi: the user must have checked the fee already outside, before passing it to the signer anyway
< sipa>
andytoshi: so no, not a pocket calculator; just trusting himself which he's already doing in an unverified setting
< gmaxwell>
e.g. the 'security upgrade' of getting the inputs is fine, so long as it doesn't cost an N hour download the whole blockchain/recan.
< sipa>
gmaxwell: how do you imagine that to work?
< gmaxwell>
sipa: the utxo has heights. get the inputs from the blocks, if we have them, otherwise go fetch the blocks.
< andytoshi>
sipa: i don't feel strongly about this, but it's annoying that the user is being forced to compute the fee herself and verify this when she has a hw signer that is perfectly capable of addition
< sipa>
ah, i see
< gmaxwell>
Aside, AFAICT walletprocesspsbt doesn't even show the fees. nor does decodepsbt... so using bitcoin core rpc as your HSM doesn't even provide any security improvement from having the inputs present? or am I missing it?
< achow101>
gmaxwell: decodepsbt does if all inputs are there
< sipa>
andytoshi: in this setting the user must have done far more complex things already
< gmaxwell>
achow101: oh okay, still nothing forces you to call decode on it.
< achow101>
walletcreatefundedpsbt also gives you the fee.
< gmaxwell>
achow101: yes, and? that is something that I'm running on the online host...
< andytoshi>
sipa: ok, fair enough
< sipa>
in any case, the only way to exploit the file format right now to do this is to create a segwit inout field (even for non-segwit inputs), which also stores the amount
< sipa>
i just think it's a bad idea to show a user information which is not verifiable - it's fine if they're willing to do verification elsewhere and let them override security checks
< gmaxwell>
well one could also set the amount to the max value.
< gmaxwell>
AFAIK there would never need to be a reason to override if we could reliably provide the inputs without absurd burdens, but right now we can't do that.
< sipa>
but that also means you don't need to shwow it again:; they analysed it and trust it already
< gmaxwell>
why did signrawtransactionwithkey permute the arguments.
< achow101>
inputs are optional for with key, but were optional in signraw
< achow101>
keys were optional in signraw
< gmaxwell>
just resulted in a couple minutes of confusion dealing with uninformative "JSON value is not a string as expected" after changing a script due to deprication.
< gmaxwell>
Okay, makes sense I guess.
< kanzure>
sipa: apologies. mailing list is in moderation mode since someone figured out how to spoof emails from bitcoin developers. emails were delayed due to my travel.