< bitcoin-git>
[bitcoin] sidhujag opened pull request #22185: fix -Wdocumentation -Werror=documentation logic in configure.ac (master...master) https://github.com/bitcoin/bitcoin/pull/22185
< achow101>
ryanofsky: using #22155, I was able to write a test case where the dust change was more than the fees, so the recipients received more than specified by their CRecipients. So this case is not as contrived as we thought it was.
< yanmaani>
the coin selector thus double-spends the input
< yanmaani>
Is there an easy way to call CreateTransaction, look at the tx, find the change output, and then force that as input to the other transaction?
< yanmaani>
Or alternatively, find the consumed input, and then blacklist that in the subsequent call?
< yanmaani>
I think I could pass a coin control to CreateTx?
< gwillen>
the coincontrol object sounds like the right way to do this, yeah, I don't remember the mechanics of it
< gwillen>
you can use the Select method of CCoinControl to force a specific input to be used; I can't tell if you can force specific inputs NOT to be used without manually selecting all inputs
< gwillen>
(m_add_inputs = false, if you want to only use selected inputs)
< gwillen>
do you need to make both transactions without broadcasting the first one, or otherwise telling the wallet about it? I'm fuzzy on the exact details here, but I'm pretty sure if the wallet knows about the first transaction when you construct the second, it will do what you want (it will not re-select an already-used coin, even though the transaction was just created and obviously isn't confirmed yet, or maybe even broadcast)
< yanmaani>
gwillen: oh, right. I have to add the first transaction somewhere in the wallet, and that'll fix it
< yanmaani>
Is it possible to do this without broadcast?
< yanmaani>
I could copy CommitTransaction but cut everything below if (!fBroadcastTransactions) {
< gwillen>
if this is for Core, probably refactoring is better than copy-pasting, but it would help to know more about what you're doing. (If it's not for Core then probably I should direct you elsewhere ;-) )
< yanmaani>
Oh yeah, I found CWallet::MarkInputsDirty, that's what I want
< gwillen>
I don't have the code open in front of me, but the existence of fBroadcastTranactions suggests maybe you can get it to add to the wallet without broadcasting, but if that's a global flag it's probably not ideal for this
< gwillen>
ah, nice
< sipa>
yanmaani: i don't think it is
< yanmaani>
sipa: will that do something I don't want it to?
< sipa>
that's just for marking cached balanced as outdated
< bitcoin-git>
[bitcoin] hebasto opened pull request #22186: build, qt: Fix compiling qt package in depends with GCC 11 (master...210608-limits) https://github.com/bitcoin/bitcoin/pull/22186
< sipa>
if you don't want the wallet to use coins you've spent, you should just add the spending tx to the wallet
< achow101>
yanmaani: use the lockunspents rpc
< sipa>
or that!
< achow101>
*lockunspent
< yanmaani>
sipa: can I do that if the tx isn't ready for broadcast?
< sipa>
define "not ready" ?
< yanmaani>
sipa: not final
< yanmaani>
valid but not accepted to mempool
< sipa>
i'm pretty sure the answer is yes
< sipa>
that would also happen if you load an old wallet into a fresh datadir
< achow101>
if you do sendrawtransaction, it will be added to the wallet, just not broadcast
< achow101>
if it isn't final
< yanmaani>
achow101: that'll cause an ugly log message, but yeah I could do that
< yanmaani>
sipa: will I also have to mark cached balance as outdated?
< gwillen>
achow101: but don't call an RPC directly
< achow101>
yanmaani: you shouldn't mess with the cached balances
< gwillen>
refactor whatever you need from the RPC into an appropriate place and call it there
< yanmaani>
or will adding it to wallet take care of it
< gwillen>
when you call an RPC directly from another RPC it has annoying consequences
< yanmaani>
achow101: I'm looking at CWallet::CommitTransaction - it (1) adds to wallet and then (2) "Notify that old coins are spent"
< achow101>
gwillen: I don't think he's proposing a code change, but rather trying to hack bitcoind to do a particular thing
< yanmaani>
achow101: yeah, this isn't for mainline bitcoin core
< gwillen>
*nods*
< yanmaani>
(is it off-topic? It's still related to the bitcoin core codebase, right? :P)
< achow101>
yanmaani: I don't think you need to modify core to do what you want
< yanmaani>
achow101: this is for a fork, not a one-off hack
< sipa>
that'd make it off topic :)
< fanquake>
Sounds off topic to me
< yanmaani>
sipa: oh sorry
< yanmaani>
is there a separate place for the bitcoin core codebase per se?
< sipa>
freenode had an ##altcoin-dev channel, dunno
< yanmaani>
thanks
< redstar>
I don't want to be rude but https://github.com/bitcoin/bitcoin/tree/master/doc mentions BitcoinTalk, and I think it should be removed because on BitcoinTalk users encouraged to sell weapons and run scams.
< redstar>
there are many topics on BitcoinTalk in which they selling fully automatic assault riffles
< redstar>
how that related to Bitcoin?
< redstar>
I remember Cobra-Bitcoin kicked out theymos from the management of bitcoin.org for similar reasons
< redstar>
theymos in fact is a criminal stolen 11,000 Bitcoin from the community while BitcoinTalk looks like something from the Iron-Age, not to mention the weapons, scams etc.
< redstar>
would be way better to keep a distance from BitcoinTalk and not promote it in the Bitcoin source code because that maybe downloaded by kids as well
< redstar>
BitcoinTalk not only engaged in weapon sales and scams but without any doubt is the most toxic environment even existed, personal attacks, doxing, defamation, libel, slander, and constant swearing
< redstar>
excuse me for the typos
< redstar>
ANYONE UNDERSTAND THAT ON BITCOINTALK USERS SELLING WEAPONS?
< redstar>
I going to slam the Bitcoin Core developers from promoting BitcoinTalk where weapon sales, personal attacks, doxing, defamation, libel, slander, and constant swearing is a standard. No worry I will not let slide under the hood belcher either who get paid by literal terrorists to vandalize and delete close to hundreds charity from the "Bitcoin Wiki" which again, owned by theymos. https://en.bitcoin.it/wiki/Talk:Donation-accepting_organ
< redstar>
izations_and_projects#Page_is_filled_with_scam belcher got paid by hrf.org which literally MASSACRED 36 people in Bolivia (and that is not the only country) in Venezuela hrf.org organized BURNING PEOPLE alive! hrf.org also running since a year a so called "Bitcoin Development Fund" which is a pure scam playing the INTERMEDIARY role for marketing purposes, in fact many core developers got thousands of dollars from this right-wing
< redstar>
terrorist organization. So in short you all should be ashamed for promoting WEAPON SALES, SCAMS and LITERAL TERRORIST! Soon we open the Bitcoin Forum at https://bitcoin.forum and this will be published there! Be prepared whats coming to your way! I will kick the hornet's nest just wait!
< luke-jr>
redstar: none of this has anything to do with development; please take it to #bitcoin if you must rant
< redstar>
This stuff not even scraching the surface of the stuff I have on them, including confidential message I received from Washington D.C. to give them my passwords etc.
< redstar>
Thw whole Bitcoin 2021 was organized by Peter McCormack and Alex Gladstein the "staregy officer" of hrf.org
< redstar>
Don't tell me that without hrf.org's scam "bitcoin development fund" Bitcoin Core developers can't receive funds, are terrorist right-wing INTERMEDIARIES really needed? Isn't Bitcoin supposed to be peer-to-peer? Just remember when you deal with these people that they BURNING PEOPLE ALIVE and MASSACRING PEOPLE!
< redstar>
yes it has luke-jr because Bitcoin Core developers happily accepting funds from this terrorist organization and even thanking them, if you use google for 5 minutes you can see hrf.org NEVER promoted Bitcoin prior to Juan Guaido decelred himself president of Venezuela and made HRF.org CEOs cousin a minister. You know transfering money from the USA to Venezuela is NOT POSSIBLE so they neede to find something to send money to nazis and
< redstar>
found Bitcoin because of me and my websites!
< redstar>
I warning Bitcoin Core developers to keep a distance from hrf.org and Alex Gladstein in particular
< luke-jr>
I'd ask what developers they fund (none afaik, though I could be wrong), but it's off-topic here. Please take it somewhere else.
< luke-jr>
this channel is just for development; not funding, forums, or anything else
< bitcoin-git>
bitcoin/master 906b6d9 Antoine Riard: test: Extend feature_rbf.py with no inherited signaling
< bitcoin-git>
bitcoin/master 2eb0eed Antoine Riard: validation: document lack of inherited signaling in RBF policy
< bitcoin-git>
bitcoin/master 82bc7fa MarcoFalke: Merge bitcoin/bitcoin#21946: Document and test lack of inherited signaling...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #21946: Document and test lack of inherited signaling in RBF policy (master...2021-05-rbf-noinheritance) https://github.com/bitcoin/bitcoin/pull/21946
< redstar>
yanmaani I got a copy of the logs and I agree with that you got banned in #namecoin you have nothing to do there, stay here with #bitcoin-core-devs and work on get some help from the hrf.org maybe you and belcher able to promote better those who massacre people, well known terrorists, right-wingers, anti-feminist, anti-immigration, sinophobic, russophobic, islamophobic nazis. Go ahead yanmaani work with belcher in scamming more BTC.
< redstar>
You can go and rant on Matrix, OFTC, Hackint of freenode. I did give you voice in #namecoin but this is the third time you needed to be banned, you will be not allowed back.
< michaelfolkson>
redstar: You've already been asked not to post on this channel, this channel is for Core development discussion. Please go to another channel (e.g. #bitcoin) for discussion on organizations
< * redstar>
silent
< jonasschnelli_>
gitian 0.20.2rc2 signatures are pushed (sorry for the delay). Happy building...
< * hebasto>
starting signing...
< jonasschnelli>
the signature failes to apply (used wrong version of apple sign). Builders please wait.
< jonasschnelli>
signature is fixed (new signature is pushed). Now you can build/run the 0.20.2rc2 macOS/win signers.