< jonasschnelli>
wumpus: do you think we should have an optional "keep-seed" argument when encrypting the wallet in 0.13?
< jonasschnelli>
I think it can be useful, but I think we can also add this in 0.14 (though the implementation is easy and relatively risk free)
< gmaxwell>
keeping around a key that has been stored unencrypted on many systems is no better than not using encryption at all.
< gmaxwell>
Probably a better thing to do is restructure things so the wallet doesn't even contain any keys until first use, so if the first thing you do is encrypt there is nothing to keep.
< jonasschnelli>
gmaxwell: Yes. I though of that. The problem is the current way how the wallet works and how it always generate a first address during initialization.
< jonasschnelli>
We could add wallet initialization/creating to a (new) bitcoin-txish tool. "./bitcoin-wallet"
< gmaxwell>
There is no particular need for it to work that way... (e.g. there doesn't need to be a wallet.dat until we attempt to use one)-- it just is that currently.
< gmaxwell>
yuck
< sipa>
jonasschnelli: i would be fine with just a function to import or export a seed from the wallet
< jonasschnelli>
People could do all sorts of things with it. Dump, enctypt, create, export/import seeds.
< jonasschnelli>
sipa: there is a PR to exporting the xpriv (over dumpwallet)
< jonasschnelli>
import is not possible now.
< sipa>
jonasschnelli: if you want to keep the seed when encrypting, export the seed before and import after
< gmaxwell>
jonasschnelli: thats going down a path of _more_ mucking inside the wallet and with keys directly, which has a remarkable track record for resulting in funds loss. :)
< jonasschnelli>
Importing should be done together with a flexible keypath option.
< sipa>
that makes sense
< jonasschnelli>
I guess users will would complain otherwise if you only can "import" seeds with m/0'/0'
< gmaxwell>
Importing should be a rarely used functionality-- manual mucking with things is dangerous. Sometimes it can make sense, sure, but the basic functionalitty needs to work.
< gmaxwell>
There is a lot of complexity required to property handle multiple derrivation schemes within a wallet.
< gmaxwell>
also unclear import with an explicit path would interact with implied chains (e.g. for chains)
< jonasschnelli>
Yes. The whole importing situation is not yet clear to me....
< gmaxwell>
I think at this level of development it's wrong to pretend that any compatiblity of keys across wallets can exist-- kind-of-sort-of compatibility will only result in funds loss.
< jonasschnelli>
People might expect a lookup of the 0-n after importing a seed, etc.
< sipa>
by import i guess i just meant "override deterministic keypath"
< jonasschnelli>
I just think people would like to stick to bip44 or something in order to use the seed in other wallets once they want to move away from Core
< jonasschnelli>
sipa: yes.
< gmaxwell>
jonasschnelli: except that won't actually work reliably, and it would hobble security and functionality.
< jonasschnelli>
gmaxwell: yes. I agree. Importing after bip44 is a nightmare if you don't have an tx-indexed blockchain
< wumpus>
jonasschnelli: I don't know, I think any solution to this is quite ugly. People expect a wallet to have only one seed, but on the other hand, keeping using the unencrypted seed when encrypting the wallet is risky
< wumpus>
that wallets are 'born' unencrypted and later encrypted keeps causing difficulties
< wumpus>
though I also don't like the idea of forcing people to set a passphrase on first use
< warren>
Don't force them upon starting Core, only if they want receive addresses?
< wumpus>
Probably a better thing to do is restructure things so the wallet doesn't even contain any keys until first use, so if the first thing you do is encrypt there is nothing to keep. <- the funny thing is that from a user viewpoint this is already the case. If you haven't used any keys, and encrypt the wallet, all pre-encryption keys were never used and will never be dealed out, just take a bit of space in the wallet
< wumpus>
warren: yes, that's an option
< gmaxwell>
setting the passphrase prematurely is a sure path to funds loss.
< wumpus>
right
< warren>
Make them type the passphrase if they want a receive address?
< sipa>
"It looks like you received yoir first bitcoins! Congratulations! Maybe now is a good time to encrypt yoir wallet so your funds are safe?"
< gmaxwell>
What electrum does is what I think is the best option, but it is very difficult to get observational data on the actual effects on users.
< sipa>
what does electrum do?
< wumpus>
sipa: but then the first bitcoins were sent to the address associated with an unencrypted key, so it's sort of too late already
< gmaxwell>
it forces you to write down an unencrypted recovery code... and by forces it disables printing and copy-paste, then when you say you've written it down it challenges you to reenter.
< gmaxwell>
so it does the encrypting at install, but it makes you make an encryption free backup at the same time.
< gmaxwell>
It also doesn't have hours/days lag between install and usability. :)
< wumpus>
sipa: it'd be succesful way of encouraging people to encrypt in the first place, but wouldn't make any of the implementation/working around it easier
< sipa>
gmaxwell: also... our wallet model is really that you should not lose your wallet.dat
< wumpus>
gmaxwell: there have been plenty of ideas of discouraging creating receive addresses at all before syncing up?
< gmaxwell>
wumpus: well it's perfectly fine to recieve before synced, if you know that you won't see the results right away!
< wumpus>
gmaxwell: but confusino about that almost no one knows that, and it results in 99% of support mails I get
< sipa>
sure, with deterministic seeds there is a way to recover your funds from catastrophic lost
< sipa>
but not the rest...
< wumpus>
gmaxwell: I'm not saying it should be impossible ofc
< gmaxwell>
I think the wallet encryption is mostly snake oil that causes a net loss of funds. Don't forget this... the failure modes it protects against aren't the most interesting, esp wrt user's ability to remember cryptographic keys. Personally, I use wallet encryption only as authorization; so that it's really clear when I'm about to spend funds in a production wallet.
< gmaxwell>
wumpus: we could very easily be scanning ahead of where we've synced ... probably with <50 lines of code changed to just catch advertised unconfirmed transactions.
< wumpus>
wallet.dat encryption helps against exploit that allow grabbing a named file from the file system, but not more
< gmaxwell>
wumpus: wallet.dat encryption also gives you an authorization hook. A user doesn't have to worry when screwing around with bitcoin-qt that they're acidentally going to send funds.
< wumpus>
it's not exactly a panacea, but encryption never is, it only helps if it's used in the right way
< gmaxwell>
but for that sort of thing a passphrase such as "goat" is perfectly fine. :P
< wumpus>
in any case I don't think arguing about this makes sense - we're not considering removing wallet encryption I hope?
< sipa>
i'm sure more funds have been lost from forgotten passphrases than from theft
< sipa>
wumpus: hell no
< gmaxwell>
wumpus: yea, not going to remove it. (I say with some regret.)
< gmaxwell>
(because as sipa says, I'm pretty confident that more funds have been lost to lost passphrases, than saved from theft by it)
< wumpus>
sipa: we have no statistics about that. Theft is also quite common, it can't be coincidence almost all malware has wallet.dat-stealing hooks these days.
< gmaxwell>
wumpus: same malware also has keylogging hooks.
< wumpus>
gmaxwell: that's not an argument against theft happening
< wumpus>
gmaxwell: just that the current security may not be good enough
< gmaxwell>
wumpus: no, it's an argument that the encryption doesn't protect much against theft. If you note, my repeat of sipa states it somewhat differently.
< gmaxwell>
forgotten vs protected from theft by encryption.
< wumpus>
hw wallets would be preferable, and I think we need to support those in the future
< gmaxwell>
I do know of cases protected from theft by encryption, but few.
< gmaxwell>
wumpus: yes.
< wumpus>
but repeating this discussion for/against wallet encrption every few months is not going to help :)
< gmaxwell>
I wasn't making an argument against wallet encryption, I was reminding that its value is limited and please don't "improve" it in ways that it more harmful.
< wumpus>
there's certainly a compromise between theft and loss due to forgetting, we've been aware of this since the beginning, and there's not really a solution that works for everyone
< gmaxwell>
There are knobs we can to make things better or worse. E.g. encoraging an unencrypted offline backup can mitigate risk, while prompting at install for a key would exacerbate.
< gmaxwell>
can't spell tonight.
< wumpus>
One thing I can think of where encryption helps, somewhat, is simple protection against local users. Stealthily copying someone's wallet.dat when you are on someone's computer for a few minutes is trivial. Installing a keylogger or trojan is more involved, and leaves much more evidence.
< wumpus>
gmaxwell: yes, we agree there, I started this off with stating that I don't like forcing the user to set a passphrase
< wumpus>
and I don't think a goal should be to encourage people to use the encryption
< wumpus>
but if they want to use it, they should be able to
< gmaxwell>
I think the way most people who would trojan your machine e.g. on windows/mac would be installing something innocent looking, which requires preparation.
< wumpus>
and then it should also be as secure *as possible given the constraints of local usage tc*
< gmaxwell>
I'm even fine with encouraging it, if it got them to make an unencrypted backup at the same time. I ~think~ that the combination is useful.
< wumpus>
indeed, an unencrypted backup makes sense combined with physical security
< sipa>
then again we don't even have a user-friendly way to recover from a backup...
< wumpus>
if only they don't put it in the cloud :(
< gmaxwell>
wumpus: electrum works hard to make you actually write it down... it does all it can to prevent your backup from being electronic.
< wumpus>
gmaxwell: yes that is good
< wumpus>
sipa: yes, which wouldnthere the ugly problem of lack of people actually interested in working on it rears its head again
< wumpus>
which wouldn't be rocket science*
< wumpus>
I mean there is a 'backup wallet' menu option, could add an 'import wallet' option too
< wumpus>
although it would work better with multi-wallet support I guess
< gmaxwell>
I'm looking at the PR list and seeing 4 unmerged wallet PRs from phantomcircuit; who has had roughly that number of open wallet PRs at any given time throught all of 0.13's development.
< gmaxwell>
Restore is mostly a disaster until something is done about rescan.
< btcdrak>
greenaddress has encrypted seeds so you put in a passohrase and it gives you an encrypted seed
< wumpus>
why? it doesn't matter if restore takes a while, it will be an infrequent operation
< btcdrak>
that is part of the initialisation process.
< wumpus>
gmaxwell: there's not really a lack of wallet PRs, but many of the ideas that have been proposed here over and over have never been implemented
< gmaxwell>
wumpus: there is "a while" and then there is ">8 hours" which is what a rescan takes on my laptop.
< wumpus>
gmaxwell: that long? oh last time I did it it was much faster
< wumpus>
yes, >8 hours is bad
< btcdrak>
rescan? ouch
< gmaxwell>
I think on a fast machine its about 5 hours now, down from about 12 prior to 0.12.0.
< wumpus>
that's longer than a reindex takes in good circumstances
< btcdrak>
good case for keeping an addrindex
< * btcdrak>
ducks
< wumpus>
why is a rescan so slow? it's a fairly simple scan over data right?
< gmaxwell>
deseralizes every block and every transaction.
< wumpus>
so deserialization-bound? ok
< gmaxwell>
and then is constantly opening and closing the wallet database.
< gmaxwell>
I believe that one of phantomcircuit's wallet fixes (maybe in the pipeline) fixed the latter part.
< wumpus>
I guess there's room for optimization there, it wouldn't need to deserialize everything
< wumpus>
many operations could be done in-place on the data
< gmaxwell>
or we could implement some version of the block bloom indexing that was posted about on bitcoin-dev.
< gmaxwell>
where for each block (or group of blocks) we would store a small lossy map for the block; and hits on the map would result in deciding which blocks to scan, or not.
< wumpus>
anyhow: why would importing a wallet.at require a rescan?
< wumpus>
it's no different from replacing your wallet.dat with a different one and restarting the client
< gmaxwell>
it always requires _some_ rescanning; assuming it was offline more than one blocktime :P
< gmaxwell>
but presumably a backup is old.
< wumpus>
the transaction should already be in there. Sure, it may need to catch up a bit, but no full rescan should be needed
< gmaxwell>
well the first 300k blocks rescan in pretty much no time. :P
< wumpus>
partial rescans are pretty fast at least in my experience
< wumpus>
I just don't think this is a blocker issue for implementing wallet import, if someone really wanted to implement it
< wumpus>
optimizing rescan would be awesome still
< gmaxwell>
I have data on the partial rescan.
< sipa>
the wallet should be able to tell the node code that some range of blocks is to be downloaded agaim
< wumpus>
but on the other hand, importing a wallet is already possible by the (circuitous, and possibly risky) work of replacing wallet.dat manually, which users already do. Would be nice if it was more userfirendly
< gmaxwell>
that was a backup restore I did a day ago.
< sipa>
gmaxwell: many matching transactiond in that range?
< wumpus>
a lot things never get done because too many other things are dragged into it, the old scope creep again
< gmaxwell>
sipa: none.
< sipa>
gmaxwell: ugh
< sipa>
well, 1 second per week
< wumpus>
oh so you want to implement wallet importing? we first need to improve rescan performance. Oh never mind then...
< gmaxwell>
pft. it's not gating, I'm suggeting why it's not as interesting to actually work on, even testing it (with mainnet) would be painful. Thats all.
< wumpus>
gmaxwell: yes, that's a very bad data point.
< gmaxwell>
I'm not complaining, but sharing info. Performance with the wallet is painful, people are working on it... and it has improved quite a bit. Though that also means that most of the really dumb things are already fixed.
< wumpus>
I'm sure it can be really slow if it's done multiple times :p
< gmaxwell>
freaky, I don't think I've seen it do that before.
< gmaxwell>
oh I see you imported while it was already rescanning, and so it started over?
< gmaxwell>
oh no your import is what triggered the rescan and the new block restarted it.
< wumpus>
no, that's not even possible
< wumpus>
if it's rescanning everything is blocked
< wumpus>
yes, that seems to be the case
< gmaxwell>
weird. pretty sure I've seen it connect blocks while rescannign and not start over.
< wumpus>
maybe it was just a fluke. But it could explain some very slow rescans
< gmaxwell>
not the ones I've been expirencing at least.
< wumpus>
the end result was correct so I didn't make a big issue out of it
< gmaxwell>
but some of the complaints for sure.
< da2ce7_mobile>
I would really like the option of importing extended private keys, ie. m/44'/0'/2' or m/44'/0'/3' etc. Where I can have my HD seed stored somewhere more secure.
< gmaxwell>
da2ce7_mobile: what you're asking there could describe several different actual usecases which have different supporting development requirements.
< gmaxwell>
For example, do you ask that in terms of just having a system that can securely getnewaddress for a remote wallet? That would best be accomplished by a standalone keygen tool.
< gmaxwell>
Or do you hope to form transactions on an online wallet and transfer them to an offline wallet for signing? That requires a large suite of tools for offline wallet support (and doesn't technically require public derrivation)
< da2ce7_mobile>
For example, One could generate a HD seed from a Trezor. Import that seed onto a offline computer and create a few extended private keys.
< da2ce7_mobile>
You could import these seeds into your Bitcoin Core to act as hot-wallets.
< gmaxwell>
you mean extended public keys there.
< gmaxwell>
IIRC trezor has absolutely no private key export.
< gmaxwell>
also it uses public derrivation exclusively, and leaking one public derrivation described key lets you unzip and go and recover all the other keys.
< da2ce7_mobile>
It has no private key export, but you can re-import your HD seed into a offline computer to generate the private keys.
< gmaxwell>
yes, but the public derrivation lets someone with the extended public key and any one private key derrive all other private keys. pretty fragile.
< da2ce7_mobile>
yeah. It would be great if BIP44 had a 'hardened only' option.
< gmaxwell>
I think what you're mostly saying though is that you'd like to have a single master secret and generate seperate wallets off it, with {details} in the generation.
< da2ce7_mobile>
Well, I already use this method for my hot-wallets. I import an extended private key (via a round-about-way) into copay on my iPhone.
< gmaxwell>
The other issue with the whole public derrivation split is that an attacker who can compromise the front end can make it start issuing bad keys (e.g. ones they have the private key) silently. :( still an improvement (and thats the use case I came up with public derrivation for) but not a panacea.
< da2ce7_mobile>
I really don't like public derivation. I don't see any point of it if you have a hardware wallet.
< da2ce7_mobile>
it is userfull for 'watch only'
< da2ce7_mobile>
but most people don't use watch only accounts.
< da2ce7_mobile>
also, why not just derive 10k public keys; and export those; it doesn't take up so much space; and the 'watch only' wallet can warn you when you are running out of keys.
< gmaxwell>
at one point I had a proposal for a new address type which would encode pubkey P plus scalar offset s, and then you pay to P+sG. And so an attacker that compromises the front end causes a publically visible change when all the addresses it gives out begin with a different prefix.
< jonasschnelli>
da2ce7_mobile: indeed
< gmaxwell>
da2ce7_mobile: indeed. Public derrivation causes a lot of trouble for a very narrow improvement.
< gmaxwell>
it's useful, but the utility is often overhyped.
< sipa>
... says the man who invented iy
< sipa>
:)
< sipa>
*iy
< sipa>
**it
< jonasschnelli>
hehe
< jonasschnelli>
I think there are serval usecases for pubkd... but not for the novice wallet user
< gmaxwell>
sipa: yup.
< jonasschnelli>
So... I'm kinda no longer sure if we even want to allow flexible keypath... with or without pubckd
< jonasschnelli>
We should probably work more towards supporting cold storages with something like "importmulti"
< gmaxwell>
Back in early 2011 the FSF complained that they wanted unique addresses for donations, but didn't want their wallet on their webserver (duh!), ... and with it being on a website if they had any fixed number of addresses, some user fetching the site might easily exhaust them... which was the original motivation. Though it doesn't really fully fix that case, since some user making to scan a milli
< gmaxwell>
on addresses is also undesirable. :P
< gmaxwell>
I think supporting offline wallets, HW wallets, and multisig with these things should be a higher priority than anything about derrivation paths.
< gmaxwell>
Some things like multisig might imply things about derrivation paths, and thats fine.
< jonasschnelli>
I think the address part in the offline wallet/HW wallet signing is the simplest part. More difficult is probably how you would design the API/interface between the twos.
< gmaxwell>
I do offline signing today, using raw transactions; but the usability is not good. :) (OTOH, it's also a workflow that allows me to have a second person review the transactions... which is quite handy)
< jonasschnelli>
rawtx is possible because fundrawtx has a custom change address in 0.13.
< jonasschnelli>
But somehow we first would need a feature that stops generating addresses inside the wallet. Something where you can fill your keypool from the "outside"
< gmaxwell>
well I suggested before a general design, where bitcoin-core wallet just has a simple interface to call another process to ask it to get signatures, providing it with the relevant data... and then that external process can implement the approrpiate call out to whatever is in use.
< jonasschnelli>
gmaxwell: I though it would be most simple if it would be TCP/HTTP
< jonasschnelli>
A json call goes out to a configurable URL, a response might come back.
< jonasschnelli>
Would also possible allow to sign on a cold storage attached to a different computer in your LAN
< gmaxwell>
Then you get CSRF from js running on the users machine...
< jonasschnelli>
You can avoid that...
< gmaxwell>
different computer; now the communication needs to be cryptographically protected.
< gmaxwell>
Sure you can but you just said, most simple.
< da2ce7_mobile>
I think that it is a good opportunity to make a standard 'Segwit Offline Signing Protocol and Format"; something that both copy-paste and a hardware wallet could use.
< gmaxwell>
Having to avoid CSRF and provide link layer encryption is not simple.
< jonasschnelli>
Launching a process... yes. Why not...
< jonasschnelli>
It would also eliminate the need for a background daemon
< jonasschnelli>
Can you check if a certain process (application at path) is already running?
< gmaxwell>
jonasschnelli: yea, and if you did want it to talk to some daemon-- it could do that... with the complexity to communicate with it encapsulated in the process that it launches.
< jonasschnelli>
Or how would you prevent from spinning off to many processes?
< gmaxwell>
well my suggestion would be that it would launch it on demand, communicate via stdio. If the operations are 'blocking', then you wouldn't have to worry about too many being launched.
< jonasschnelli>
gmaxwell: I think very likely there is a GUI attached to that launched process (signing verification or similar), the stdio com should be async/nonblocking...
< gmaxwell>
By blocking I just meant bitcoin core wouldn't open multiple processes.
< jonasschnelli>
But right, you could track on the bitcoincore side if there is already a signing in process and refuse anotherone.
< gmaxwell>
Not the actual mechenism for talking to the file descriptors.
< jonasschnelli>
You could also retrive pubkeys over that process by sending different commands over stdio
< gmaxwell>
And yes, for some kinds of usage, there would be a UI.. or things like hardware access. other kinds, ("connect to bob.com and get him to SMS you then sign the transaction") perhaps not or only in error cases.
< GitHub176>
bitcoin/master ab942c1 Pieter Wuille: Treat high-sigop transactions as larger rather than rejecting them
< GitHub176>
bitcoin/master 618c9dd Wladimir J. van der Laan: Merge #8365: Treat high-sigop transactions as larger rather than rejecting them...
< GitHub182>
[bitcoin] laanwj closed pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (master...unifysigopcost) https://github.com/bitcoin/bitcoin/pull/8365
< sipa>
anyone have any intuition about what hashrate you could get out of a raspberry pie?
< sipa>
i'm writing an answer on quora, and being able to claim it would take a trillion years to redo the chainwork on a pi would be a nice statement...
< sipa>
but that requires its hashrate to be at most 1.2 Mhash/s
< jonasschnelli>
install CGMiner...
< gmaxwell>
jonasschnelli: has no cpu mining.
< gmaxwell>
sipa: openssl has a nice benchmark.
< jonasschnelli>
Oh. I'm not familiar with mining, maybe install cpuminer..
< kinlo>
sipa: raspberry pi will not get 1.2 Mhash/s
< kinlo>
it's not that powerfull
< gmaxwell>
you can scale that for actual use, e.g. three compression function runs, early termination, and asicboost if you want (maybe a 10% speedup).
< * gmaxwell>
goes to find the old bitcoin wiki page.
< gmaxwell>
funny how much slower original rpi is compared to sensible arm computers.
< gmaxwell>
in any case those numbers are going to be too slow by about 10% or so because they don't implement asicboost.
< gmaxwell>
"more energy than a whole country" is ... laughable
< gmaxwell>
$35 million a month (a reasonable upper bound on mining's energy consumption)-- I wonder if any country uses that small an amount of electricity? Would the vatican count?
< GitHub192>
bitcoin/0.13 cfd1280 MarcoFalke: [doc] gbuild: Set memory explicitly (default is too low)...
< GitHub199>
[bitcoin] NicolasDorier closed pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (master...wallet-min-output) https://github.com/bitcoin/bitcoin/pull/8356
< sdaftuar>
sipa: BlueMatt: i'm not sure i followed your discussion of the sendcmpct semantics
< sdaftuar>
if a node supports version 1 and version 2, sure it can send 2 messages. but since we attempt to keep track of which peers are announcing to us, how is that supposed to be calculated?
< sdaftuar>
also, how do you know what version the compactblock announcements that you receive are generated with?
< sipa>
sdaftuar: for example: if a node sends a sendcmpct version 2 at any time, and received one, then getdata cmpctblocks must be version 2
< sdaftuar>
sipa: ah okay, so we are looking at responses then. that makes sense to me.
< sipa>
for unsollicited cmpctblocks, you can say that the last received sendcmpct takes effect (as that is the one with the announce bit set)
< sipa>
but it's probably easier to just say that the last understood sendcmpct is what countd?
< sdaftuar>
last one with an understood version number? yes, i think that.
< sdaftuar>
i guess changing version numbers should only really happen during initial handshake, otherwise we get race conditions
< sipa>
so that means you'd send v1 and then v2 initially, without announce bit
< sipa>
if the peer never sends you a v2, you never ask for announce and never ask for cmpctblock
< sipa>
i don't think there is any race
< sdaftuar>
i mean, you shoulnd'
< sdaftuar>
you shouldn't later try to negotiate up to v2
< sdaftuar>
if several hours into our connection, i try to send you an announce=true, version=2 sendcmpct message, and you do the same, right before you make a compactblock announcmeent
< sdaftuar>
then it would be unclear how the announcement is encoded
< sdaftuar>
as i wouldn't know whether my message to you was received before that point, or not.
< AaronvanW>
"the #bitcoin core developers deserve a lot of credit for sticking to their guns on the block size issue" <- Stephen Pair on Twitter
< jonasschnelli>
AaronvanW. :)
< jonasschnelli>
"[...] sticking to their guns [...]" I think this is the US version for "being loyal"?
< AaronvanW>
more like, not being intimidated or persuaded to do the wrong thing. doing what you believe is right.
< AaronvanW>
(though I'm also no US native)
< kanzure>
AaronvanW: wrong channel i think
< AaronvanW>
o
< AaronvanW>
k
< jtimon>
ping #8348 #8346 and #8391
< luke-jr>
I have a fresh Core master build, that I started on an old testnet dir. It rewound the blockchain, and has not made any attempt to sync onward since
< luke-jr>
for 22 minutes now
< luke-jr>
sorry, 1 hour 22 minutes..
< luke-jr>
getpeerinfo shows no blocks inflight from anyone
< luke-jr>
two peers are 0.12.1
< luke-jr>
sipa: ^ any ideas?
< sdaftuar>
you need node_witness peers to download blocks from. i wonder if the logic to query the dnsseeds needs to improved? i would imagine that would solve your problem
< luke-jr>
sdaftuar: are not 0.12.1 all NODE_WITNESS? O.o
< sdaftuar>
uh, no released code is NODE_WITNESS
< luke-jr>
got something I can addnode?
< luke-jr>
right, I'm confusing segwit with csv now. :|
< instagibbs>
there are reports that syncing on testnet is near impossible with master/0.13
< sdaftuar>
this might work: x9.testnet-seed.bitcoin.jonasschnelli.ch
< sdaftuar>
or you could restart with -forcednsseed maybe
< luke-jr>
-forcednsseed seems to have worked, although I restarted in the process :x
< sdaftuar>
my guess is we should more proactively use the dns seeds if the addrman is light on NODE_WITNESS nodes
< sdaftuar>
i imagine this could be an annoying problem for people on mainnet down the road, if someone is upgrading from older software that doens't have the recent addrman improvements
< sdaftuar>
which, i think, improved the bookkeeping on peer services
< luke-jr>
is testnet really at 3.125 BTC subsidy? O.o
< Lightsword>
yep
< luke-jr>
anyone who can easily send a bunch of segwit txs on testnet? :x
< GitHub66>
[bitcoin] sdaftuar opened pull request #8408: Prevent fingerprinting, disk-DoS with compact blocks (master...cb-misbehaving) https://github.com/bitcoin/bitcoin/pull/8408
< arubi>
luke-jr, I made a few, I don't have many funds
< luke-jr>
arubi: hm, seems to have not relayed to me; can you pastebin them raw?
< arubi>
hmm let's see. might have easier time if I set it to output raw hex this time
< arubi>
oh oops it was set to segnet :) moment
< luke-jr>
XD
< arubi>
making some more txes
< luke-jr>
arubi: if you have a limited #, hold off a bit, I have a crash to debug XD
< arubi>
no problem :). I'm off to bed now anyway, will be doing some more tomorrow. these are the ones I have from now, if you see them: http://paste.debian.net/hidden/b0b0c9ca/