< murchandamus>
gmaxwell: Stupid question perhaps. If #frankensegwit activated by signaling on bit4, wouldn't that just get ignored by all current segwit-ready nodes? Except that those nodes wouldn't grok #frankensegwit, would there be more issues?
< murchandamus>
since #frankensegwit would be forking off at the same moment with their blocksize increase also, wouldn't it be a non-issue? :p
< gmaxwell>
murchandamus: they'd all end up banning each other.
< gmaxwell>
murchandamus: because frankensegwit nodes would hand witnesses to 0.14 nodes, and then get punted because things aren't supposted to have wittnesses yet.
< gmaxwell>
Segwit is more than the consensus rule, it's also a set of P2P changes.
< gmaxwell>
And the p2p parts are already in effect.
< gmaxwell>
Because we didn't want to have the p2p behavior suddenly change and light up a lot of new codepaths when segwit enforcement started.
< gmaxwell>
(as that sounded like a receipy for disaster! :) )
< gmaxwell>
Segwit has the bip9 activiation, and a network service type which is used to make sure the graph of segwit capable nodes is not partitioned, and new p2p messages for transfering messages (tx, blocks, compact blocks) with witnesses if they have them.
< murchandamus>
Ah right, I didn't realize that they'd actually hand over the full witness transactions
< gmaxwell>
Only the BIP9 part isn't triggered... so to redeploy segwit we have to also replace all those other parts, not just the bip9 bit.
< gmaxwell>
Which is a simple search and replace, but only if the BIP9 activation has reached its limit... otherwise we have the potential that it might activate under either.
< murchandamus>
gmaxwell: But since #frankensegwit would activate with the blocksize increase in unisono, the hardfork would be there anyway, right?
< gmaxwell>
Just thinking about making the tests for that makes my head hurt.
< gmaxwell>
murchandamus: maybe? people are saying directly contradictory things.
< gmaxwell>
if it's a hardfork why are they talking about percentages? e.g. The thing DCG linked to was sergios proposal that had the hardfork and segwit as seperate things.
< gmaxwell>
thats also what bitfury was saying (seperate), but not what jihan was saying.
< murchandamus>
garzik stated that on Twatter. But since they can't even properly phrase the agreement to make it in anyway specific, I sincerely doubt that they came to agreement on details in that regard yet.
< murchandamus>
Anyway, I guess it'll fall apart anyway when they try to specify what they're trying to achieve exactly with the proposal. :p
< murchandamus>
gmaxwell: Did Adam or Samson finally attend at the meeting?
< gmaxwell>
murchandamus: no, we were expicitly disinvited. (then reinvited, then disinvited-- samson ended up cancling a flight)
< gmaxwell>
Yea, details matter, and not just to engineers.
< murchandamus>
gmaxwell: Ah, I see. I was only up to date with "invited, disinvited, reinvited". Samson is in NYC though, right? Saw him in some pictures, I think.
< gmaxwell>
murchandamus: their meeting was on sunday, so I guess he went later.
< murchandamus>
gmaxwell: It just pisses me off that after two years of debate, somebody trying to forge an agreement doesn't even invest the time to run it by someone to make the text any sort of clear. E.g. "2MB hardfork", "immediately/within six months" gnarf
< murchandamus>
Ah, I C
< murchandamus>
I'm so done with the debate. I want all the shiny things that come with SegWit.— I'm sick of having 10 "unconfirmed transaction" questions on Bitcoin.SE every day.
< gmaxwell>
look on the bright side, -- someone tries to add some kind of crazy AML thing to Bitcoin, good luck to them! :P
< murchandamus>
gmaxwell: heh. Indeed. — Although I just realized. within six months would end just after the BIP9 timeout of segwit, perhaps they suggest to activate it right then?
< luke-jr>
on the bright side, BIP148 is up to 10% of listening nodes
< murchandamus>
I wouldn't be surprised if Frankensegwit becomes a large motivator for more people to adopt UASF. j)
< murchandamus>
;)
< paveljanik>
luke-jr, you mean that 10% of nodes match /UASF/?
< paveljanik>
or how do you know that run it?
< paveljanik>
...they...
< wumpus>
the bright side, for me, is that people are finally enthousastic about running their own node. So much activity! More (direct) users in the longer run run will likely result in more contributors to the project.
< wumpus>
Gavin's tweet (combined with BIP148) seems to have the complete opposite effect of what he probably imagined.
< gmaxwell>
jonasschnelli: because it tracks where it learns addresses from, so no single source can get excessive influence on the table.
< wumpus>
the origin of an address is kept around to make sure the connections are balanced, e.g. a not all to those from a single dns seed
< wumpus>
right
< jonasschnelli>
Okay. That makes sense. Thanks.
< jonasschnelli>
I somehow though addrman does relay the seeders IP which sets the assumption that a seeder should also run a node on the same IP (my seeder runs no node on the same IP).
< jonasschnelli>
*thought
< sipa>
nope
< wumpus>
I was confused about that too in the past, but no, that's never an assumption
< sipa>
addrman is also just a database
< sipa>
indeed, it just uses the source ip to balance in the buckets
< sipa>
this is to prevent that a single source could poison your entire cache
< wumpus>
gah it's painful to read how some people are juggling wallet.dat files, let's please get multiwallet in for 0.15
< gmaxwell>
oh it's finally been rebased.
< jonasschnelli>
Whats the etymological source of "bogo"(size)? My humble english understanding does only point me to buy-one-get-one-for-free?
< wumpus>
yes it's orignally a Linux thing, they needed an estimate to calibrate a delay loop. They called it 'bogo' to prevent people from using it as an actual measure of processor speed, though some people still were using it for that in the 90's.
< wumpus>
bogosize is bogus in that it doesn't measure the actual size, it can be used for relative comporisons, but keeping in mind that it's... bogus
< wumpus>
the definition is fixed and shouldn't change between client versions, unlike the leveldb size, which is entirely implementation dependent
< gmaxwell>
also history of reorgs dependant.
< wumpus>
yep, noisy and path-dependent, makes you wonder what is the bogus one :)
< jonasschnelli>
For luke-jr's multiwallet: is it problematic to keep multiple wallet.dat files in the same directory? BDB does open(datadir()), right?
< wumpus>
I think that's the only scenario supported?
< jonasschnelli>
Yes. But can BDB handle that?
< wumpus>
like with -wallet, all wallet files are relative to the data directory, there is no support for multiple BDB environments
< wumpus>
sure - a BDB environment can contain as many databases as you want
< wumpus>
there used to be a few when all the other files were BDB databases as well (that's the etymology of ".dat" for many of the files)
< jonasschnelli>
I wasn't sure if some of the salvage/recover functions where treating the whole bdb env. But right,... seems to always be per db
< wumpus>
(which is annoying for some things, e.g. you can't simply list/copy all the wallets with *.dat)
< wumpus>
jonasschnelli: but that's bitcoind.cpp, it's not part of bitcoin-qt
< jonasschnelli>
Right.. indeed... I guess no URI scheme calls bitcoind
< jonasschnelli>
I guess it can be removed then
< wumpus>
that's why I diligently copied the boost::starts_with into my new code... then later I realized, oh, this makes no sense
< wumpus>
what you want to happen if you accidentally call bitcoind with a bitcoin: URL is to give an error
< wumpus>
not for it to be silently ignored :)
< jonasschnelli>
Can we reject non GPG signed email to security@bitcoincore.org?
< wumpus>
jonasschnelli: we don't even have a GPG key for security@bitcoincore.org
< wumpus>
I'm all for a secure way to report security issues to us, but we'll first have to solve that
< wumpus>
could just list who to encrypt it to
< jonasschnelli>
wumpus: I just though require a signature (encryption can be dealt later), as form of a spam protection
< jonasschnelli>
Auto-answer back (your mail needs to be signed)...
< jonasschnelli>
reduced the "can you please confirm my tx" mails
< jonasschnelli>
*reduces
< wumpus>
I'm also not sure about the technical side, I don't think the current mail alias provider supports running a custom script to check incoming mails
< wumpus>
and - signing doesn't provide security - we'll need to decide either 1) list theGPG keys encrypts to (leaks the list of recipients) 2) generate a GPG key and share that between the recipients
< wumpus>
(one might want to be able to submit security reports deniably, so that's another reason to not require signing)
< timothy>
wumpus: you can use a pseudonimous GPG key
< gmaxwell>
luke-jr: why is the gentoo ebuild of bitcoin broken since 0.13.1 at least? it seems impossible to get it to build with wallet support if ljr is disabled.