< luke-jr>
feels like a waste of time to debate bit 5/7 disconnection. we all know ~nobody supports it and it's never going to happen anyway..
< gmaxwell>
luke-jr: your message is unclear.
< luke-jr>
?
< gmaxwell>
17:44:30 < luke-jr> feels like a waste of time to debate bit 5/7 disconnection. we all know ~nobody supports it and it's never going to happen anyway..
< gmaxwell>
what is it?
< luke-jr>
Sw2x
< gmaxwell>
ah ha!
< gmaxwell>
sipa: I win the bet.
< luke-jr>
O.o
< gmaxwell>
luke-jr: perahps but there is still ABC and an ounce of prevention is worth a pound of cure.
< sipa>
luke-jr: my guess was that you were talking about the disconnection
< gmaxwell>
which made no sense.
< gmaxwell>
the discussion is also an oppturnity to make it clear that Bitcoin developers don't support s2x... there are still some people going along spreading the idea that we'll somehow be going along with it.
< bryyan>
is this just for bitcoind stuff, or would questions involving new implementations of bitcoind be valid
< bryyan>
like for example a C version that uses less processor intensive means then json for communication
< wumpus>
bryyan: this channel is specifically for "bitcoin core", the c++ implementation, it has a very narrow scope on purpose to make sure the scrollback is relevant to the devs here
< wumpus>
there is #bitcoin-dev that is more general
< aj>
BlueMatt: fyi, the code comment in PR#10982 refers to bits "5 or 8" rather than "6 or 8" (or "5 or 7")
< aj>
BlueMatt: yeah, but you're switching between them in the same sentence :)
< BlueMatt>
oh did I
< BlueMatt>
ugh
< BlueMatt>
kept confusing myself, i thought i fixed it
< BlueMatt>
aj: fixed
< aj>
BlueMatt: \o/
< bitcoin-git>
[bitcoin] jharvell opened pull request #10997: Add option -stdinrpcpass to allow RPC password to be read from stdin (master...stdinrpcpass) https://github.com/bitcoin/bitcoin/pull/10997
< MarcoFalke>
jnewbery: Hit me a pm when you happen to be around.
< r251d>
(Please let me know if another channel would be better for this.) Would anyone here have guidance on whether hard forks should use a different address version for standard transactions? Seems like users would benefit from being able to recognize an NYA2X P2PKH address from a standard chain P2PKH address (1...) or a NYA2X P2SH address from a standard chain P2SH address (3...).
< r251d>
Maybe the recommendation for users to ensure they're transacting with the intended chain would be to use bech32 addresses, "bc1..." for main chain vs something else for forked chains? If so, is Bech32 anticipated to be released before the NYA2X fork (late Nov)?
< gmaxwell>
r251d: the problem is that the S2X people are very agressive about creating these sorts of problems, they refuse to take any of the prudent measures, so if we introduce anything, they're likely to copy it in an incompatible way. :(
< gmaxwell>
(and by incompatible I mean "All too compatible")
< r251d>
gmaxwell: thanks for the feedback. I want to submit an issue on S2X Github to recommend to change address format to minimize user confusion, but I wasn't sure whether to recommend a different prefix for their P2PKH and P2SH standard addresses, or to recommend a different Bech32 prefix, or both.
< r251d>
(Afk in a minute, but I'll read any responses in the Slack transcript for this channel)
< gmaxwell>
They'd have to do new p2sh/p2pk outputs, bech32 is sw only. Also I doubt they have the expertise to implement it.
< gmaxwell>
But people have already asked. (I suppose more doing it won't hurt, but you might want to read some of the other discussions on their github first)
< r251d>
Does anyone recall where the previous discussions about it happened? I don't see any open or closed issue or PR about P2PK or P2SH version changes.