< phantomcircuit>
BlueMatt, so what there's just some queue that's being consumed much much slower than produced?
< BlueMatt>
phantomcircuit: yes, cause cs_main
< phantomcircuit>
BlueMatt, wait it's a queue of shared pointers?
< BlueMatt>
phantomcircuit: yes?
< phantomcircuit>
oh to the full CBlock yeah ok so it's the full block staying in memory nvm
< BlueMatt>
yupyup
< * luke-jr>
peers at our transaction list CSV export not adding up to the right balance
< sipa>
poll: when applying validateaddress to a (known) native witness multisig address, should it (A) not show the keys in it (B) show the keys in it as pubkeys (C) show the keys in it as legacy addresses (like P2SH multisig now) or (D) show the keys in it as native segwit addresses
< luke-jr>
I think B? C and D are ugly.
< sipa>
luke-jr: i agree
< sipa>
though in the case of B, should be also do that for non-segwit?
< luke-jr>
probably; can it do so compatibly?
< sipa>
yeah, would need to be in a separate key
< sipa>
"pubkeys" instead of "addresses"
< luke-jr>
ah
< phantomcircuit>
BlueMatt, is promise being used elsewhere?
< mryandao>
hmm, i'm trying to compile an older version of core (v0.7.0rc3), checked out the branch and did a clean, but there's no build instructions :(
< warren>
Does anyone use gitian with qemu-kvm instead of lxc?
< warren>
MarcoFalke: have you tested your gitian instructions on Fedora 27? both with qemu-kvm and lxc?
< warren>
Does anyone using gitian with qemu-kvm particularly on Ubuntu or Debian?
< Randolf>
warren: You might also ask in the #qemu channel, just in case someone there can be helpful too. :)
< warren>
Randolf: no, this is very gitian and bitcoin specific
< Randolf>
Oh, okay.
< Randolf>
I was merely thinking of a potentially wider audience. :)
< warren>
The Bitcoin gitian instructions say to use only lxc but the way I've used it for the past few years is with qemu-kvm instead
< Randolf>
Cool!
< Randolf>
Having more than one way to do things is always a plus.
< warren>
Randolf: the way we qemu or lxc is very different from what most other people are familiar with
< Randolf>
I'm familiar with qemu, and have implemented it for various clients (primarily to run MS-Windows on NetBSD hosts), but lxc is something I should probably look into then.
< Randolf>
...and also qemu-kvm.
< warren>
qemu-kvm is just hardware accelerated qemu
< warren>
using kvm as a hypervisor, I think is the terminology
< warren>
But base-trusty-amd64.qcow2 generated on Fedora 25+ seems to be broken in some way that gets stuck with 100% CPU during qemu startup. If I copy a base-trusty-amd64.qcow2 image generated from Ubuntu onto my Fedora machine then gitian works.
< warren>
So curious if MarcoFalke tested the qemu method of gitian
< warren>
My packaged python-vm-builder is different than the "pip" method he uses to install it from Ubuntu
< Randolf>
Does qcow (as opposed to qcow2) also exhibit the same problematic behaviour?
< warren>
I don't think that's the issue. It's something installed or configured in the image file when it is generated.
< Randolf>
Oh.
< warren>
gitian qemu-kvm works just fine if I copy that base image from an Ubuntu machine
< Randolf>
(Thanks for the link, by the way. I've opened it and will read it soon.)
< warren>
something is wrong with that tool on Fedora, it worked in Fedora 24 last i know
< warren>
I suspect it's grub2 or something not installing in the image file
< TD-Linux>
have you tried both efi and bios boot with qemu?
< AdilibA>
i want to share a scalling solution that i was thinking about it lately
< AdilibA>
Is anyone there?
< AdilibA>
The solution i was thinking about is by adding compression work in addition to minning work
< AdilibA>
Add the compression limit is the block size
< AdilibA>
I was searching for a compression that is luck based like mining, and isuggest the decomposition of the data to a permutable list of Superior Highly Composite Numbers.
< Provoostenator>
AdilibA: I think this is more appropriate for e.g. #bitcoin-wizards or the bitcoin-dev mailinglist. Unless you have a proof-of-concept patch ready to go specifically for the Bitcoin Core client (which this channel is about).
< morcos>
adiabat: can you email me or othwerise send me that fee_estimates.dat. i think it makes sense that happened, but just will take a look to confirm
< BlueMatt>
phantomcircuit: promise? you mean std::promise, or the shared_ptr to the block?
< bitcoin-git>
[bitcoin] promag opened pull request #11864: wallet: Make fund transaction atomic (master...2017-12-atomic-fundtransaction) https://github.com/bitcoin/bitcoin/pull/11864
< bitcoin-git>
bitcoin/master 6ba8f30 Gregory Sanders: don't attempt mempool entry for wallet transactions on startup if already in mempool
< bitcoin-git>
bitcoin/master 6697a70 Gregory Sanders: add test for unconfirmed balance between restarts
< bitcoin-git>
bitcoin/master 8ab6c0b Wladimir J. van der Laan: Merge #11839: don't attempt mempool entry for wallet transactions on startup if alr…...
< cluelessperson>
I have a serious question. What are thoughts on seperating the Bitcoin Core wallet and Bitcoin Core node?
< cluelessperson>
Reason I suggest it? 1. Layman cannot be trusted/bothered to run their own nodes by default. 2. I think it will healthily promote SPV development.
< cluelessperson>
3. When someone uses multiple wallets, as some users do, they have difficulty switching between the wallets and rescanning, which takes a lot of time
< wumpus>
isn't there a PR that adds SPV functionality to the wallet?
< wumpus>
I don't think bringing this up as a discussion topic yet again is productiv
< wumpus>
it's been discussed zillions of times since 2012 or so
< wumpus>
every time the conclusion was that yes, it's desirable, if you want it, work toward it
< cluelessperson>
I understand the frustration. It just keeps coming up for me because I keep getting morons that can't seem to understand how it works in #bitcoin
< wumpus>
feel free to work on it
< cluelessperson>
I'll do what I can.
< cluelessperson>
my skill sets are limited, I'm sorry
< cluelessperson>
I ask for broader shoulders
< wumpus>
#10794 is jonasschnelli's PR in that direction
< Provoostenator>
There's several pull requests that make small steps in this direction, mostly just improving the code quality and separating stuff better.
< cluelessperson>
Provoostenator: unfortunately, I'm not a coding expert, and I don't know C++. I have no power here.
< cluelessperson>
I wish I could actually help
< cluelessperson>
I'm stuck with documentation and community support. DEVOPs and the like
< Provoostenator>
Well, both can be learned.
< Provoostenator>
And these other contributions also help, as they take work off the shoulders of developers.
< Provoostenator>
Or you could stalk your friends with C++ skills and manipulate them into becoming interested in Bitcoin, quitting their current job and helping out :-)
< cluelessperson>
Provoostenator: I'm trying but I have no path forward
< cluelessperson>
I'm taking college classes, but not sure where this is leading honestly
< alcipir>
How long does it take for a seasoned web developer to get into C++?
< Randolf>
alcipir: It probably depends partly on which languages they already know. For example, if they haven't done anything with Object Oriented Programming, then that will be a learning curve for them too.
< alcipir>
Hm, I've been doing object-oriented PHP for years now, although I don't like it as a language
< alcipir>
also know a bit of Java and C#
< alcipir>
but C++ seems pretty daunting at first, seems like it changes a lot over time
< Randolf>
alcipir: I suspect that the folks in the #c++ channel can probably be very helpful to getting you started based on what you already have a background in. :)
< Randolf>
alcipir: My suggestion is to learn C++ first, and then learn about programming Bitcoin/blockchain. The reason is that both have learning curves that are probably better-studied separately.
< alcipir>
I see, thanks for the tip :)
< Randolf>
You're welcome.
< Provoostenator>
acipir: that's roughly my background as well, although I did dabble in C(++) 15 years ago and worked a lot with ObjectiveC. Here's some book recommendations depending on your background: https://stackoverflow.com/a/388282
< sipa>
i think the discussion is getting a bit offtopic
< alcipir>
thanks Provoostenator, and sorry for the offtopic discussion
< michagogo>
Why do we still have a "Pay only the required fee of 1 satoshi/byte" checkbox?
< michagogo>
I mean, now that we have RBF, it's probably not quite as bad as it used to be, but it still seems like it's likely to be misleading
< michagogo>
Yeah, it's under the Custom radio button and not under Recommended, but it feels like it's saying that that's okay and has a chance at working
< wumpus>
I don't know, feel free to file a PR to remove it and see if there's interest / pushback
< wumpus>
by far most people will simply use the recommended fee (which is the default), and those that don't generally know better what they're doing, so I doubt it matters much
< gmaxwell>
re: for wallet encryption, I think you can just sign the current best batch when each rpc comes in, so you don't need
< gmaxwell>
to keep the key around. The downside is that it can't use the fee-estimation at the point of send, but that seems like
< gmaxwell>
a small loss.
< gmaxwell>
Interface wise, you'll need to return some kind of identifier that the wallet can use to tell you if a payment was made.
< gmaxwell>
BlueMatt: I don't think there is a reason to make the standard rpcs do this, just add new ones: "bundlesend" (works
< gmaxwell>
like sendmany, but takes a maximum waittime argument) "bundleabort" (can cancel a transaction using a handle returned
< gmaxwell>
by bundlesend) "bundleforce" (forces the current bundle to send now) or something... and a behavior that sends N
< gmaxwell>
seconds after the last addition, or when the first timeout is hit.
< gmaxwell>
unless it would really be a burden to change the rpc calls their software is making... but I think thats unavoidable
< gmaxwell>
since you can't return a txid.
< gmaxwell>
For a while I've wanted a standardized signed payment confirmation code, basically a signature with some well known key
< gmaxwell>
that says "I promise to pay X btc to address Y", which would be a potential candidate for what gets returned, but
< gmaxwell>
perhaps too much scope creep.
< gmaxwell>
One thing perhaps to keep in mind is that the names of the RPCs should be short and easy because probably we'd like to make the bundle based method the default and standard method.
< BlueMatt>
yes, thats probably scope creep
< BlueMatt>
but, generally, I think these could be added quite simply to large benefit of some users
< gmaxwell>
One reason some large users have given me for not using their own aggregation (parties easily big enough do implement their own) was that they want txids to give to users that they can immediately look up on block explorers.
< BlueMatt>
worth reaching out to people who use bitcoin core's wallet in reasonable volume to ask what they'd want from such an interface
< jonasschnelli>
The key links to btcplt.org (Bitcoin Platinum)
< BlueMatt>
gmaxwell: yea, that really sucks, dunno how to get away from it except for rbf, sadly
< gmaxwell>
BlueMatt: with the signed code I just suggested.
< BlueMatt>
gmaxwell: an independantly-really-useful project which someone should do is go test what the ux is on wallets when you receive rbf txn
< jonasschnelli>
Not sure if we want a key leading to the Bitcoin Platinum project in our repository,... could be missued for advertising?
< BlueMatt>
gmaxwell: yes, but block explorers wont support that for...20 years
< gmaxwell>
BlueMatt: meh, bc.i had sorta support for bech32 addresses when segwit activated.
< gmaxwell>
some kind of signmessage thing wouldn't be a big deal to support, doesn't require a blockchain to back it.
< BlueMatt>
gmaxwell: I'm super skeptical, but would love to be proven wrong....
< BlueMatt>
true, could signmessage magic
< gmaxwell>
I mean, any of us could also put up little dumb js pages for that.
< Provoostenator>
jonasschnelli: would it make sense to ask for plain text keys instead of binary ones, so this sort of thing is easier to spot? (regardless of whether this domain matters)
< gmaxwell>
It would just be a reciept that a person could save and use to prove to others when their counterparty doesn't make good on a promise to pay.
< BlueMatt>
(obviiously getting wallets to have reasonable ux when receiving rbf txn would be independantly incredibly helpful - how many wallets spend unconfirmed/unconfirmable/conflicting txn if you receive a rbf-bumped tx?)
< jonasschnelli>
Provoostenator: no... I don't think so...
< jonasschnelli>
Provoostenator: there is always an email (or pretty much always) attached...
< BlueMatt>
gmaxwell: true....I suppose if we put up a page for it that may also be sufficient, I guess people dont care *what* block explorer shows it, as long as they can link to one that does
< gmaxwell>
BlueMatt: yes and we should keep RBF in mind when doing the batch interface, the batch interface should be specified so that it's okay for it to RBF anything you put through it.
< Provoostenator>
Nvm, you can't see the email in a .asc file either; just need to import it to see.
< BlueMatt>
yes
< gmaxwell>
BlueMatt: batch interface's spec should be "will get a payment made of the specified amounts to the specified addresses accomplished eventually"
< BlueMatt>
one thing we should do is reach out to "industry" folks regarding potential apis here (batching/whether they'd be happy with a signmessage-equivalent?)
< gmaxwell>
well I think they've never thought of these things, so we'd have to propose them.
< BlueMatt>
yes, thats my point :p
< gmaxwell>
oh, rpc I missed: bundletxid takes a bundle handle and tells you the txid it eventually issued.. maybe also if it was confirmed and in what block.
< BlueMatt>
well bundletx verbose=X
< gmaxwell>
rpcs that return all txn like listtransactions kinda stink.
< BlueMatt>
i mean get the tx for the bundle in raw (or hex, or txid) form
< gmaxwell>
ah.
< sipa>
is there a need to support multiple bundles simultaneously?
< BlueMatt>
little reason not to, but probably not?
< sipa>
my thinking was that there'd just be a single set of output/amount pairs that are in flight
< sipa>
and any time you update it, a new transaction is created
< sipa>
which is guaranteed to conflict with earlier transactions
< BlueMatt>
you mean and not announce them?
< gmaxwell>
the guarenteed to conflict will result in suboptimal coin selection.
< BlueMatt>
rbf would have to be optional given receiving rbf txn right now sucks
< sipa>
gmaxwell: sure
< gmaxwell>
BlueMatt: I described above creating the tx at RPC not announce time.
< adiabat>
related to pre-signing a bunch of txs with increasing fee rates, what if you have incremental locktimes on them?
< gmaxwell>
sipa: why bother with a guarentee to conflict, if you give the user no access to the txn itself until announce time?
< BlueMatt>
i see no reason to not wait, except for wallet encryption, but I'd prefer to decrypt-at-send-time than at-add-output time, no?
< adiabat>
would it then be possible to have nodes relay the txs even if they're not-yet-minable?
< sipa>
gmaxwell: well it would need to conflict at least with broadcasted transactions
< gmaxwell>
adiabat: setting locktimes on precreated replacements is the obvious thing to do, suggested every time it has come up.
< adiabat>
gmaxwell: ok what's the catch...?
< gmaxwell>
adiabat: relaying a non-mingable transaction is an immediate and nasty DOS vector... what value do you see in that?
< BlueMatt>
some people dont want to do rbf cause the client-side wallets may handle it like garbage
< sipa>
gmaxwell: in my earlier descriptions of this idea there was no separation between creation of the transaction and broadcastng
< gmaxwell>
adiabat: there is no catch, if bitcoin core ever does replacement fully I assume it'll presign with locktimes.
< sipa>
but it does make sense - you may want to perform multiple updates frequently, but only occasionally issue a new transaction
< adiabat>
gmaxwell: value is that wallets can fire-and-forget; DoS is the issue but feels like it could be managed
< Provoostenator>
BlueMatt: I suspect that if enough wallets start actually using RBF, other wallets will stop handling them like garbage. It's often a matter of educating UX folks and developers.
< BlueMatt>
Provoostenator: agreed, but also a chicken-and-egg issue there
< gmaxwell>
adiabat: best of luck with that.
< BlueMatt>
sipa: wait, how do you propose it working if you create a new tx every time you add an output and broadcast immediately and *dont* use rbf?
< adiabat>
gmaxwell: heh :) Yeah it's hard to not get banned
< BlueMatt>
(hell, even with rbf you have lots of annoying corner-cases)
< sipa>
BlueMatt: of course it would RBF
< BlueMatt>
sipa: the whole point was to make rbf optional..........
< sipa>
maybe we're talking about something unrelated then :)
< BlueMatt>
see discussion above...
< BlueMatt>
a tx bundle api would have to have rbf be optional
< sipa>
meh
< gmaxwell>
sipa: the point of this discussion was to enable parties to sendmany.
< BlueMatt>
if you have rbf on you can get instant-sends that just get replaced, but no one (right now) would use it if its only rbf
< gmaxwell>
Right now too many people use txid as an effective unique key for a payment.. you utterly break stuff by rbfing.
< BlueMatt>
sipa: feel free to go help user-level wallets fix their rbf-receive ux
< sipa>
fair
< BlueMatt>
rbf appears to work pretty sell *sending* to services, but a service sending rbf to a user-side wallet....bad ux
< sipa>
i guess i was thinking about a longer term thing for when RBFing is not an issue anymore, and people have stopped relying on txids for unconfirmed transactions
< BlueMatt>
no, I'm talking about building an api now...not something no one will use
< sipa>
okay, ignore e
< adiabat>
gmaxwell: apologies if off-topic or already discussed- what if policy was accept future locktimed tx but only if it's a fee bump of existing mempool tx?
< BlueMatt>
adiabat: doesnt ln have like a model where folks run servers which auto-broadcast in the future? just piggy back on them
< BlueMatt>
no need to relay it in bitcoin p2p net?
< adiabat>
yup, asking because I'm working on similar stuff
< adiabat>
Hmm... OK so maybe code LN stuff to accept not-yet-OK RBF txs instead?
< sipa>
accepting things into your mempool which can't confirm soon undermines its DoS protection
< gmaxwell>
adiabat: that gives an attacker zero-cost n-fold inflation node node bandwidth/cpu/memory... (make the initial one enough to confirm right away, make N bumps)
< BlueMatt>
yea, I mean I'd strongly suggest if you're gonna run a network of servers/users providing services to montior and announce txn later to add an option to broadcast *anything* later
< sipa>
as we rely on assuming that everything in the mempool will eventually be either confirmed or replaced with something paying a higher fee
< BlueMatt>
then its a generic service
< adiabat>
right, for small N might be doable if nodes opt-in
< Provoostenator>
BlueMatt: good point to distinguish between "merchant" services and consumer wallets when it comes to RBF. Although I think it's very useful for sending money between people who reasonable trust eachother; "let me know if you need me to bump this"
< gmaxwell>
adiabat: I think it's not reasonable to have every node in the general p2p network handling this, why not just have special transaction queue nodes that will handle this?
< BlueMatt>
Provoostenator: well my concern is ux for average users...if I'm sending to someone I know understands bitcoin, fine, no issue, if its some guy who's receiving a withdraw from an atm/their exchange, they may be very confused
< adiabat>
gmaxwell: I agree; I'm mainly thinking about the logistics of different nodes / codebases
< gmaxwell>
there is no need for 100,000 nodes to queue up txn that will likely never confirm.... just having a couple handle it would be sufficient.
< adiabat>
easy enough to have a website which says "give your future-dated RBF txs" and has a captcha or something
< BlueMatt>
or add it to ln nodes? dont they have some ability to do similar things?
< BlueMatt>
might as well let them do it for any txn with payment of 5 satoshis over ln or so?
< adiabat>
right now LN nodes don't have actual tx storage for other nodes
< adiabat>
but it's something that could be added
< adiabat>
I have been looking at bumping fees for funding channels and it's a little tricky due to multisig / multiple parties
< Provoostenator>
BlueMatt: what's the implication of that for #11605? In particular, wouldn't that make the case for not making RBF a default in RPC, because we don't want every ATM out there to start using this just yet?
< Provoostenator>
(every ATM that uses the Core wallet)
< gmaxwell>
Provoostenator: hm? there is no problem signaling RBF if you don't make use of it.
< gmaxwell>
The problems arise when you make use of it.
< BlueMatt>
Provoostenator: I mean that would be my thought, which is what I put in that pr anyway, but worth asking morcos and jnewbery since they objected?
< BlueMatt>
yea, ok, that too, if you dont use it it doesnt matter
< gmaxwell>
The issue for the batching thing is that if it used RBF it would immeidately make use of it.
< Provoostenator>
Ok, that's a good point. Wallets indeed suck even more at that.
< Provoostenator>
They complain it's a double spend, might even mess up the balance.
< gmaxwell>
though on reflection even if your batching thing can RBF, it shouldn't do so eagerly, since it'll pay high fees since the bumps have to increase fees.
< BlueMatt>
yes, exactly, batching rbf isnt quite supported by the current restrictions on rbf...maybe be worth exploring reducing those restrictions if people have a desire for it
< gmaxwell>
but still, flagging rbf is pretty much harmless, I believe electrum does this by default already without incident...
< gmaxwell>
BlueMatt: I dunno, if anything current RBF restrictions are too lax because mempool minfee is unrealistically low.
< BlueMatt>
yea, well possibly minfee needs to be higher with the incremental/relay fee lower for rbf? dunno, worth exploring
< Provoostenator>
Do we have an estimate of how often fee increases are used in the wild currently? I find it useless in both GreenWallet and QT, because it doesn't let you pick your own amount, and the cheapest option is usually much too expensive.
< Provoostenator>
Like I make a tx with a €0.50 fee and it says the minimum for a fee bump is €25.
< BlueMatt>
that....doesnt sound right
< BlueMatt>
oh, yea, greenaddress' feebump is really annoying
< gmaxwell>
for greenaddress IIRC it only currently supports one bump, so it only offers it at whatever the shortest fee estimate is.
< Provoostenator>
I had to use some AngularJS javascript console voodoo to make GreenWallet behave. And with Core I already have a TODO to improve this.
< BlueMatt>
gmaxwell: no, it offers several, but they're all relatively short
< gmaxwell>
Provoostenator: the bumpfee in bitcoin core however lets you set whatever target you want AFAIR.
< Provoostenator>
gmaxwell: correct, so my TODO is about allow the UI to do the same. Probably by reusing the send screen, hiding all elements except the fee selection.
< Provoostenator>
(and enforcing the correct minimum, etc)
< gmaxwell>
you might want to also do something to handle the minim..right
< adiabat>
bitcoin-qt bump fee only gives you one option though; cli lets you set whatever you want
< gmaxwell>
I'd forgotten we had anything in the GUI yet.
< adiabat>
you can right click on txs and there's an "increase fee" option
< Provoostenator>
I'm trying to Make QT Great Again :-)
< gmaxwell>
it's still relatively useless due to not being able to change the input set.
< adiabat>
brings up a modal with OK / cancel
< Provoostenator>
Yes, that's the other contraint I suppose. I guess the max fee is constrained by the amount of change for the original tx?
< Provoostenator>
I'm not going to mess with coin selection, but for RBF, it might make sense to try and overshoot by the worst case fee, if there is an input available.
< gmaxwell>
uhg. no... the correct thing to do is to just drop the same-inputs restriction.
< gmaxwell>
it was just done that way to make it faster to implement, but it's a bad restriction.
< Provoostenator>
That does sound cleaner. Is that restriction part of the BIP?
< gmaxwell>
absolutely not
< Provoostenator>
Ok, so the first step there would be to change bumpfee RPC to let go of same-input?
< Provoostenator>
But somehow track what you've used, because I assuem there has to be overlap in inputs.
< Provoostenator>
(between all versions)
< gmaxwell>
Probably easiest to let it add additional inputs, this requires plumbing through mandatory inputs to the coin selection logic.
< gmaxwell>
technically they merely needs to be an overlap. But it's simpler to superset and I think hardly worse.
< gmaxwell>
Supersetting is better for privacy.
< Provoostenator>
And the wallet keeps all previous versions around and knows which ones they are? (doesn't matter in the superset case)
< gmaxwell>
Thats why the superset case is easier to implement.
< Provoostenator>
Supersetting in combination with my idea above of overshooting the initial selection?
< Provoostenator>
(though that can always be done later)
< gmaxwell>
there is no reason to overshoot the initial.
< gmaxwell>
we should be trying to avoid producing dusty change (e.g. change in value comparible to fees)
< Provoostenator>
My rational was to make bumping cheaper in the super set scenario, because you don't need to add an extra input. But I see your point about creating dust.
< gmaxwell>
well you'll pay the fees for that extra input eventually, so it's not that bad to add it.
< gmaxwell>
the cost of the extra input is just the difference in the feerate between now and when you might use it later.
< luke-jr>
gmaxwell: but you need to cover the cost of the data/weight for the first tx as well?
< luke-jr>
not sure it matters much in practice I guess
< Provoostenator>
Probably not when fees are at a level where you actually need RBF.
< Provoostenator>
At what point would you expect most node operators to increase the minimum relay fee?
< gmaxwell>
Provoostenator: we don't expect anyone to increase the minimum relay fee, we expect it to increase automatically.
< gmaxwell>
unfortunately it's not, seemingly because the mempool is too big.
< sipa>
Provoostenator: do you mean the minimum relay fee (the fee needed to get into the mempool at all) or the discard rate (the fee increment needed for replacing) ?
< sipa>
the first is controlled by the mempool limiting; the second is just a configurable constant
< sipa>
(luke-jr was talking about the second)
< morcos>
gmaxwell: it got quite high before the weekend, i think 40 sat/B
< morcos>
is there any reason that resendwallettransactions needs to be a hidden RPC only used for testing?
< morcos>
doesn't it seem kind of useful to be able to fully create and locally accept transactions, but not broadcast them until ready
< morcos>
is it just a privacy concern?
< morcos>
this is partly in response to the ongoing discussion in #10247 right now
< gmaxwell>
you mean turn off wallet broadcast and trigger broadcasting yourself?
< morcos>
yeah exactly
< gmaxwell>
we probably need to add a flag in the wallet to track if unconfirmed txn has been seen in the mempool, and show it in the GUI, to avoid users footgunning by never broadcasting.
< gmaxwell>
but I think it's fine, personally I always run with broadcasting off.
< instagibbs>
do you just sendraw when ready?
< morcos>
ah, i suppose sendraw accomplish what i wanted to suggest pretty well
< phantomcircuit>
personally i disable internet when i want to do that...
< * luke-jr>
wonders why the GUI is blocked until rescan finishes
< jb55>
morcos: I'm about to remove the InMempool() check from AbandonTransaction on my local node, is there any good reason why that's there?
< sipa>
jb55: if your own node has it in its mempool, it's very likely other nodes do too, in which case the effect won't accomplish much
< sipa>
you could try to double-spend the transaction, but it may not get relayed by other nodes, for example
< jb55>
I've just had a tx that's been around for a month and it looks like my node keeps rebroadcasting it?
< jb55>
would be nice if there was some way to tell my node to stop broadcasting it, I though that's what abandon would do but I can't abandon because it keeps getting rebroadcasted and stays in my local mempool! Unless I'm confused about something.
< sipa>
jb55: ah, yes agree wth that
< sipa>
not quite abandoning, but at least stoo broadcasting
< gmaxwell>
I agree that stop broadcasting would be reasonable, however I also don't think it'll be very useful: the recieving side will also rebroadcast, and so will random nodes on the network
< gmaxwell>
probably when we add a "I've seen this in a mempool before" flag on wtx we should add a "I should keep trying to rebroadcast" and have abort set that to false.
< jb55>
gmaxwell: well the case I was referring to was specifically ResendWalletTransactions, which only applys to transactions in your own node. It didn't stop rebroadcasting (for a month) until I passed in walletbroadcast=0 which seems a bit overkill
< gmaxwell>
jb55: I know, my point was that even if _you_ stop, the reciever will keep going, as will random people on the network who rebroadcast other people's transactions for unclear reasons.
< gmaxwell>
I think it's reasonable to have a way to stop, but at the same time don't expect it to be very useful.