< bitfriend>
hi if i want to buy ethereum do i need to buy bitcoin first
< bitfriend>
oh is this the wrong channel
< sipa>
try #bitcoin
< bitfriend>
thank you friend i went to #ethereum and they helped me
< kb4yer__>
Be a part of the NEW V-Tec-Telegram Lognterm Trading BOT Start here: https://goo.gl/yYT5qJ
< luke-jr>
correct me if I'm wrong, but it seems compact blocks breaks the "DoS banning for invalid blocks" stuff..
< luke-jr>
the assumption of it, relied on to ensure peers are on the same chain
< gmaxwell>
luke-jr: it didn't break it, it intentionally changed the behavior in order to facilitate relay before validation.
< luke-jr>
gmaxwell: then there's no problem with removing DoS banning from non-compactblock cases? O.o
< gmaxwell>
they'll still get disconnected if diverged (e.g. once the parent of their tip is not your tip)
< luke-jr>
oh, because that scenario falls back to non-cb?
< gmaxwell>
yes.
< luke-jr>
gmaxwell: lacking a clean way to ensure the tips match, can you think of any problem with simply turning all existing DoS banning for invalid blocks into a disconnect-only-if-a-primary-peer?
< rupy>
hi, so I know accounts are deprecated but I have no choice but to use them anyways. My concern is that come segwit accounts won't be able to make the new transactions, any1 have any clue about that?
< bitcoin-git>
[bitcoin] sipa opened pull request #10581: Simplify return values of GetCoin/HaveCoin(InCache) (master...simplehavecoin) https://github.com/bitcoin/bitcoin/pull/10581
< morcos>
wumpus: where are we with 0.14.2? i'm still tracking down where this bug appeared, and not sure it's urgent to fix, but the coin control approxmiate fee is no longer updated by the smart fee slider. it looks like the bug exists in 0.14.1 but not in 0.13.2
< gmaxwell>
unrelated to anything, should we be considering changing the fallback fee?
< gmaxwell>
I believe it's at a level which will never get confirmed.
< morcos>
gmaxwell: i'd be in favor of increasing it, but its unclear to what
< morcos>
i don't know about anyone else, but it seems to me this is fairly important to fix
< morcos>
if people are trying to manually select coins and there is a wide range of fee rates, it'll be super annoying if its not actually telling them how much its going to pay
< morcos>
the final dialog box at the end after you click send has the correct fee of course
< gmaxwell>
that PR is confusing.
< bitcoin-git>
[bitcoin] morcos opened pull request #10582: Pass in smart fee slider value to coin control dialog (master...fixcoincontrolfee) https://github.com/bitcoin/bitcoin/pull/10582
< phantomcircuit>
gmaxwell, possibly there shouldn't be a fallback fee at all
< phantomcircuit>
if we fail to estimate the fee
< phantomcircuit>
we should probably just do an rbf transaction with no fee
< phantomcircuit>
and correct later
< phantomcircuit>
(but work)
< gmaxwell>
kvnn: yes.
< bitcoin-git>
[bitcoin] achow101 opened pull request #10583: [RPC] Split part of validateaddress into getaddressinfo (master...getaddressinfo) https://github.com/bitcoin/bitcoin/pull/10583
< TD-Linux>
phantomcircuit, is there fee bumping support in bitcoin core now?
< sipa>
there is a bumpfee RPC
< sipa>
only works for bip125 transactions
< TD-Linux>
seems like exposing that in the GUI would be required before relying on it
< gmaxwell>
ACK
< * sipa>
volunteers TD-Linux to implement that
< TD-Linux>
:)
< TD-Linux>
though immediately, I'm mostly suggesting that you just crank the fallback fee to 70 sat/b for now
< TD-Linux>
by the way, the top Google results for "bitcoin transaction stuck" involve multi-step processes using web wallets that are much worse than overpaying
< TD-Linux>
oh, bumpfee is already in the gui. right click transaction -> increase transaction fee
< sipa>
orly?
< TD-Linux>
seems to work. automatically picks fee bump
< TD-Linux>
I do think if there's still opposition to enabling replaceability by default, enabling it when smartfee isn't available is reasonable
< gmaxwell>
TD-Linux: the GUI support isn't in a release yet.