< jonasschnelli>
If someone wants Bech32, why override to OUTPUT_TYPE_P2SH_SEGWIT?
< sipa>
meshcollider: can't do that right now (on phone)
< luke-jr>
jonasschnelli: that's if the checkbox is unchecked
< luke-jr>
if they have it set to Bech32, the checkbox is checked by default
< meshcollider>
sipa: all good, sorry I posted that before I read your message about packing :)
< meshcollider>
maybe jonasschnelli can then
< jonasschnelli>
meshcollider: done
< luke-jr>
should we bump libsecp256k1 for 0.16? not sure how big a deal the optimisations are
< sipa>
i don't think there is anything very important
< jonasschnelli>
luke-jr: I was just confuse that you called OUTPUT_TYPE_P2SH_SEGWIT legacy
< luke-jr>
jonasschnelli: I did?
< jonasschnelli>
<bitcoin-git>[bitcoin] luke-jr opened pull request #12208: GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default
< gribble>
https://github.com/bitcoin/bitcoin/issues/12208 | GUI: Rephrase Bech32 checkbox texts, and enable it with legacy address default by luke-jr · Pull Request #12208 · bitcoin/bitcoin · GitHub
< luke-jr>
jonasschnelli: that's referring to the ability to use Bech32, if your addresstype=legacy
< gmaxwell>
jonasschnelli: I was confused by the regtest prefix and thought the prefix was getting truncated.
< wumpus>
probably want only the URL encoding to capitalize it, and not in other places like below the image
< gmaxwell>
Personally I think allcaps monospace addresses usually look nicer, at least when presented in isolation. might want to look at it both ways before deciding.
< wumpus>
but I think caps are wider so it'd have to use an even smaller font
< gmaxwell>
they're the same size in monospace font.
< meshcollider>
do the current PRs resolve that or does it still need work
< gmaxwell>
I think thats a non-issue.
< gmaxwell>
non-change send to selfs are not hidden.
< gmaxwell>
otherwise a service with multiple users which sends funds on user commands would lose payments when one user sends to another user by address.
< luke-jr>
I agree that looks as expected in RPC
< gmaxwell>
(and 'custom change' to a non-change address is not treated as change)
< meshcollider>
ok, wumpus or someone can remove it from the milestone then :)
< luke-jr>
I really don't see the use case for 'custom change'.
< gmaxwell>
I whined a bit about it when implemented. I could contrive up some for you, e.g. you're slowly migrating from one old wallet to a new one, and want all your change to go to the new one.
< gmaxwell>
it's certantly an advanced feature.
< luke-jr>
hmm, that's an interesting idea
< gmaxwell>
I can't think of any other usecase.
< gmaxwell>
oh sorry, I know another one but its bad.
< gmaxwell>
E.g. user really insistant on keeping all their funds on a single address.
< gmaxwell>
Which there can be justifications for, but they're still bad. :)
< wumpus>
meshcollider: ok
< sipa>
i can't ooen an issue now, but we should mark addwitnessaddress as deprecated
< gmaxwell>
Does it do anything anymore?
< gmaxwell>
meshcollider: I went and added some explination to that issue with the sends to self.
< meshcollider>
gmaxwell: sounds good, thanks
< gmaxwell>
meshcollider: thanks for bringing attention to it.
< sipa>
gmaxwell: it probably at least resets the address label
< meshcollider>
wumpus: is that !IsDeprecatedRPCEnabled() stuff overkill for this case
< gmaxwell>
probably, but uniformity is cheap.
< meshcollider>
gmaxwell: I mean he hasn't currently used it, was wondering if that was a deliberate choice :)
< gmaxwell>
ah!
< wumpus>
meshcollider: how does that work?
< wumpus>
FWIW I've added it to the release notes as well now
< meshcollider>
wumpus: its the stuff which forces you to use -deprecatedrpc=addwitnessaddress argument to use it
< meshcollider>
like estimatefee uses
< wumpus>
oh I see, sure
< gmaxwell>
might be premature to do that?
< gmaxwell>
do we want it to immediately stop working without settings?
< gmaxwell>
(I'm asking, no strong opinions)
< meshcollider>
are we planning on removing it in 0.17?
< wumpus>
I was assuming it would be removed in next major release, if not, should update the release notes :)
< meshcollider>
It should be a trivial transition for most use cases I'd imagine, and it was always advertised as experimental so I'd say its fine how it is
< wumpus>
waiting another release and going for 0.18 is fine with me too
< gmaxwell>
yea, I suppose! if we're going to remove it in 0.17 then the disruptive choice is probably the right one.
< meshcollider>
nah it shouldn't have gained enough use in this short timeframe to be necessary waiting another whole release
< meshcollider>
i vote remove in 17
< gmaxwell>
strangly I don't feel any cosmic force hurrying the removal of no-op RPCs. Perhaps one GOOD argument for going faster is this: people are going to keep following old "how to segwit" guides.
< wumpus>
gmaxwell: which is another good reason to use the IsDeprecatedRPCEnabled() stuff, I guess, as otherwise it will seem to just keep working a s intended
< meshcollider>
yeah users tend to ignore help text even if it is in caps ;)
< gmaxwell>
banner blindness.
< wumpus>
well, more that they'll not look at the help if they 'help' is some online or wiki guide
< gmaxwell>
right, which is why its important to fail. I would sort of like if in general we start breaking interfaces a little faster, at least until we cause complaints. we've gone to far in the never breaking things direction for too long. :) and IsDeprecatedRPCEnabled is a pretty nice middle ground.
< UnderDog_>
good morning
< meshcollider>
UnderDog_: maybe for some ;)
< UnderDog_>
work got cancled today
< UnderDog_>
bad freeze
< UnderDog_>
i still woke up at 4am and so i decided to make a whiskey and do laundry
< UnderDog_>
i haven't used IRC in almost 20 years
< meshcollider>
UnderDog_: I think you might be in the wrong channel, maybe try #bitcoin for general discussion on it, this channel is just for bitcoin core development
< UnderDog_>
well i'm not part of the development team but I did not see another IRC available and thought I might be likely to find similar persons of interest here.
< sipa>
#bitcoin may be a better place
< UnderDog_>
ok
< UnderDog_>
only think I might be able to help with is thermodynamic's and heat extraction designs for your servers
< UnderDog_>
no need ofr 's
< UnderDog_>
for*
< waseem>
/UNIGNORE a5m0
< Pritty_Kitty>
Hello and thank you to all good Core developers for what you do.
< Pritty_Kitty>
I'm trying to learn the system and use it but hope to get answer for a question:
< Pritty_Kitty>
I have a 0.15.1 node with a "testnet=true" setting. getblocktemplate gives me a template where "txid" and "hash" field are identical for transaction.
< Pritty_Kitty>
Should they not be different for SegWit is running on testnet?
< Pritty_Kitty>
Will i use the "hash" field to create my witness hash tree and put a commit in my coinbase value? Do i put this commit value AFTER the BIP34 blockheight value?
< Pritty_Kitty>
I am trying to make blocks.
< Pritty_Kitty>
I want them SegWit compatible
< wxss>
t
< Randolf>
Pritty_Kitty: You seem to be asking a "how to use Bitcoin" type of question. You'll likely find that such questions are better suited for the #bitcoin channel as this one you're asking in now is specifically focused on Bitcoin core software development.
< Pritty_Kitty>
No no i am a developer asking technical questions about bitcoin. I have built php code to deserialize transactions and build a merkle tree. Now i am working on the witness tree.
< Pritty_Kitty>
But i could just mine regular blocks without SegWit. But I know you want SegWit so i hope for answers to my questions
< instagibbs>
Pritty_Kitty, this isn't a question for Bitcoin Core development though. maybe #bitcoin-dev
< Pritty_Kitty>
ok ty i will try there
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #12211: Avoid potential null dereference in ReceiveCoinsDialog constructor (master...pr/nullrecv) https://github.com/bitcoin/bitcoin/pull/12211
< jojeyh>
Can anyboyd give me a brief explanation for "struct zero_after_free_allocator" ?
< jojeyh>
What is the point of this object instead of a traditional std::allocator ?
< jojeyh>
in file "bitcoin/src/support/allocators/zeroafterfree.h"
< luke-jr>
jojeyh: std::allocator probably doesn't zero when freeing
< jojeyh>
can you explain what this means?
< luke-jr>
jojeyh: in other words, it leaves the data in memory
< luke-jr>
which means when something else is allocated (hypothetically even in another program), it might have the data in its new memory
< jojeyh>
luke-jr: ok, so basically if a std::allocator were used then even after the memory is freed the bits will still be nonzero ?
< luke-jr>
right
< jojeyh>
k thanks
< luke-jr>
this is particularly bad if the memory might contain private key or passphrase info