< * luke-jr>
ponders if it would make sense to softfork in on-chain chain-split tokens..
< luke-jr>
hmm, or maybe when/if we finally do a hardfork, just declare that all UTXOs *without* the high tx.nVersion bit set are void.. anyone who consents to the HF must set the bit for their outputs, with the understanding that the original chain can/will softfork these to be invalid when/if the HF split
< * luke-jr>
wonders if -wizards is more appropriate for this topic
< meshcollider>
Heh the renaming of "Easy to implement" -> "Good first issue" means the 0.16 release schedule is now a "Good first issue"
< sipa>
it has some nontrivial dependencies, though :)
< luke-jr>
lol
< Varunram>
though if someone did contribute that, would be great ;)
< bitcoin-git>
[bitcoin] Sjors opened pull request #11557: WIP: Use Sat/WU instead of (μ/m)BTC/kB and show percentage fee (master...fee-sat-per-wu) https://github.com/bitcoin/bitcoin/pull/11557
< Grandpa_>
Hello, - an old lowtech grandpa on the line here - hoping you guys can help me figure out what to do. I have an old Bitcoin Core wallet with some old BTC coins in it. It haven't spent any or even touched the wallet (other than upgrading to Core 0.15.0.1 a few day ago) since May 2017 - prior to the Segwit implementation and the Bitoin Cash and Gold forks that I have been trying to follow through the media.
< Grandpa_>
Now I would like to transfer some to Bitstamp (the only place where I have an acct) in case I would like to sell a litle bit. But I would of course also like to NOT LOSE the Bitcoin Cash and Gold coins which now (as far as I am able to discern from media coverage) reside inside the belly of each of my old Bitcoins. I've tried to make sense of Bitstamp's official statements but there isn't really any usable information ther
< Grandpa_>
So: Could someone among you PLEASE share some insight as to what to actually do? Since Bitstamp has automatically credited costumer accts with pre-BTCash holdings with one BTCash for each old BTC, do they also automatically do this with BTC that are transferred now? If not, how to go about it from inside Bitcoin Core (with the least possible difficulty and complexity for an aging chap who struggles with the technicalities i
< gmaxwell>
Grandpa_: Bitcoin Cash will not 'replay' your bitcoin transactions. You can send bitcoin without worrying about that. Bitcoin gold doesn't really exist yet, but they claim that when it does it will also not be vulnerable to replay, so again, should be no reason to worry there.
< gmaxwell>
When you pay with your bitcoin core wallet, only the bitcoin will move... the Bcash (and presumably bgold) will just stay where they are.
< Grandpa_>
So you are saying that I can safely transfer som BTC to Bitstamp and they will take care of it_
< Grandpa_>
?
< Grandpa_>
How can they stay where they are if the BTC are sent away?
< gmaxwell>
No, I am saying you can send btc to bitstamp and other currencies will not be effected.
< gmaxwell>
Grandpa_: because they are entirely seperate systems that diverged from bitcoin in the past, they will not see your transactions.
< gmaxwell>
(and, in fact, your bitcoin transactions are not compatible with them).
< Grandpa_>
Should a make a copy of my wallet before sending then?
< Grandpa_>
With the old balance?
< gmaxwell>
That could make it a little easier to later send the bcash/bgold.
< gmaxwell>
Though it is not strictly needed, as you can rescan your wallet on those systems.
< Grandpa_>
How else could I preserve the gold/cash?
< gmaxwell>
it would be preserved even if you didn't back up the wallet because the keys are never removed from the wallet.
< Grandpa_>
I mean, if I now send away some coins reducing wallet balance to 0 / could I later extract cash and gold from it_
< Grandpa_>
?
< gmaxwell>
Yes, that is what I've been trying to tell you.
< Grandpa_>
Oh, my.
< Grandpa_>
Sound scary though.
< Grandpa_>
Sounds
< gmaxwell>
it isn't really-- these things are just totally seperate cryptocurrencies where they just happened to also pay everyone that owned bitcoin at a certian time on them.
< gmaxwell>
So its like importing the same private key into a litecoin and bitcoin wallet. They're still seperate.
< Grandpa_>
But the recommended path would, however, be to just make a copy of the wallet before sending? And then later on use it for the other two? How exactly would I go about it if I want to get rid of the bcash asap (which I dont like?)
< sipa>
can we move this to #bitcoin ?
< Grandpa_>
how do I do that?
< Grandpa_>
start there anew?
< sipa>
type exactly:
< sipa>
/join #bitcoin
< Grandpa_>
Thank you sincerely for your coaching guys! Might be checking in later.
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #11487: Check that new headers are not a descendant of an invalid block (master...2017-10-acceptblock-validity-check) https://github.com/bitcoin/bitcoin/pull/11487
< cfields>
ugh, the whitespace linter is annoying
< cfields>
</unhelpful grumble>
< sipa>
good, that means it's working
< gmaxwell>
Is anyone here permitted on the segwit2x list? it would be nice for someone to ask what the heck this refers to:
< gmaxwell>
7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing
< gmaxwell>
- ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x
< gmaxwell>
through the November fork. This is the most stable path for users, based
< gmaxwell>
on upstream Bitcoin Core instability.
< wxss>
gmaxwell: the segwit2x-dev branch (based on 0.15) crashes at least 5x during IBD
< gmaxwell>
?!
< gmaxwell>
wxss: are you sure your hardware isn't just fucked?
< gmaxwell>
gah. must resist urge to ask you about the crashes, I do not intent to help them fix their broken grap.
< gmaxwell>
er crap.
< wxss>
I haven't seen it with the Core client (0.15.x) so I'm pretty sure my hw is ok
< gmaxwell>
well it would be no shock to me if they broke it.
< wxss>
me neither, anyway it was just an observation.
< achow101>
I like how he doesn't report the bug upstream and just complains about it instead :/
< gmaxwell>
we claims that _we're_ seeing instability.
< gmaxwell>
AFAICT this is simply untrue.
< andytoshi>
fwiw adam is on the list and can maybe forward a message
< gmaxwell>
s/we/he/
< achow101>
are you not able to get on the list?
< gmaxwell>
I have no idea now, when they first opened it they were telling people that it was only for supporters and people who agreed they would deploy it, but if adam is on it then perhaps; I don't really have any interest in being on it, and I don't think jeff will reply to me.
< aj>
gmaxwell: i'd give 80% odds it's talking about the qt bugs fixed in 0.15.0.1... i doubt it's anything unknown or unfixed given the "Bitcoin Core project is seeing" them wording
< gmaxwell>
well the things fixed in 0.15.0.1 wouldn't really make a lot of sense in that context... because ... they're fixed.
< Chris_Stewart_5>
gmaxwell: Don't let your pesky facts get in the way of the narrative
< aj>
gmaxwell: the sensible reason for basing on 0.14 is that rebasing 0.14->0.15 on top of btc1 is too hard; but that's embarassing to admit, and rebasing btc1 on top of 0.15 would also be embarassing
< MarcoFalke>
0.15.0.1 only fixed the gui oob crash. The "peers.dat" crash will be fixed in 0.15.0.2.
< MarcoFalke>
I am not aware of any other bugs or instabilities.
< achow101>
peers.dat crash?
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11560: Connect to a new outbound peer if our tip is stale (master...2017-10-stale-tip-new-peer) https://github.com/bitcoin/bitcoin/pull/11560
< sdaftuar>
gmaxwell: cfields: i think i have a working implementation of what we talked about yesterday ^^^
< cfields>
sdaftuar: great, will take a look
< sdaftuar>
thanks!
< aj>
MarcoFalke: (hm, #11508 was the other one i was thinking of, but i don't think the bug was only introduced in master)
< gmaxwell>
sdaftuar: so remind me a bit about how the scheduler works... when the network hits 30 minutes with no blocks will all peers make their additional connection at exactly the same time?
< BlueMatt>
gmaxwell: wat
< BlueMatt>
no....
< BlueMatt>
checking
< sturles>
I am on a 3G network, downgraded to GPRS speeds after exceeding daily quota limit. Now my node has been stuck for hours on "Timeout downloading block [...] disconnecting". Is it possible to make it more patient, or will I have to wait until after midnight for more blocks? Does it keep the dowloaded part, or is it discarded before trying to download from the next node?
< gmaxwell>
discarded, unfortunately, though the timeout is 20 minutes, so if you can't transfer a block in that time you're going to fall behind regardless.
< sturles>
Would be nice if it could at least keep valid downloaded transactions in the mempool, to allow for a more compact block download next time.
< sturles>
It seems to download more than one block in parallel, which makes it more likely to time out.
< Chris_Stewart_5>
sturles: Perhaps you could use -blocksonly if you are on mobile?
< sturles>
I need the bandwidht for downloading two or more blocks in 20 minutes.
< sturles>
Chris_Stewart_5: That would not be helpful, I think. I would have to download every block in full, instead of just the unseen parts (ca compact block).
< Chris_Stewart_5>
sturles: I think it would eliminate your mempool problems, but it might not matter since you have to dl the entire block any way
< sturles>
I don't have a mempool problem that I am aware of.
< sturles>
How does sending transactions work with -blocksonly? I guess fee estimation will be off, and privacy will certainly be worse since all unconfirmed transactions I know about are my own.
< Chris_Stewart_5>
sturles: That would be a problem AFAIK
< gmaxwell>
sturles: the timeout is increased when there are more blocks in flight.
< gmaxwell>
sturles: it can't get anything from the partially sent block because its sent as a large single message. the bitcoin p2p layer deals with messages as big atomic units.
< gmaxwell>
It would technically be possible to do something like tear viable transactions out of a partially sent block when disconnecting a peer but it would be a big pile of tricky additional code.
< gmaxwell>
sturles: its interesting to me that you had block downloads fail on a running node with a mempool. they should have been fetched via compact blocks and been fast to transfer.
< gmaxwell>
I wonder why it didn't.
< sipa>
gmaxwell: he must have been behind already
< sturles>
My node had been offline for several hours, and had downloaded up to the tip about 25 minutes before the speed was downgraded. Perhaps the mempool was not up to date yet when the network speed was limited?
< sturles>
I assume progress=1.000000 means it doesn't know about any newer blocks.
< bitcoin-git>
[bitcoin] theuni opened pull request #11562: bench: use std::chrono rather than gettimeofday (master...bench-clock-chrono) https://github.com/bitcoin/bitcoin/pull/11562
< gmaxwell>
no progress is meaningless when its near 1, its just based on timestamps.
< gmaxwell>
sturles: right your mempool only learns about new txn coming in, and most txn getting confirmed now were broadcast quite a while ago (mempool is draining out)
< gmaxwell>
so probably a block came in after you were limited and had very few mempool hits, and you fetched it and couldn't manage it in 20 minutes.
< sturles>
height=491698 was downloaded at 17:48:40 UTC, seconds after my speed was downgraded.
< sturles>
I now have "blocks": 491699, which means one block has been successfully downloaded after that.
< gmaxwell>
you might end up back in sync if you -connect to a single peer. ... other peers sending you txn while you fetch that block might be making the difference.
< sturles>
I think I'll just wait 47 minutes for a new day. :-)
< gmaxwell>
thanks for reporting, I think I know what we need to do to better handle things like this... just so many things to do, and not enough time.