< wasi>
great job on v0.13.1 guys. thanks to all the contributors for making this version a reality. looking forward to see the segwit sf happening.
< btcdrak>
sipa: luke-jr: jonasschnelli: each of you dns seeds appear to be down.
< goatpig>
Are there specific rules to create SW outputs from legacy outputs? Can I just create a SW tx with empty witness programs, redeeming only legacy outputs? Do I have to use nested outputs in a legacy tx?
< goatpig>
phantomcircuit: current P2PKH and P2SH outputs
< jl2012>
goatpig, current P2PKH and P2SH outputs will be spent in the old way
< jl2012>
you may send to your own segwit-compliant address, of course
< goatpig>
my concern is what is the preferred/legal path to convert a legacy output to a sw one
< Victorsueca>
goatpig: I'd just make a standard transaction to send them to the segwit address
< aj>
goatpig: same way you would upgrade from a legacy single-pubkey address to a 2-of-3 multisig address, you just spend the coin to your new address
< goatpig>
ok so i dont have to force my users to spend to a nested sw first?
< aj>
goatpig: no, you don't have to. you'd save a step if you did though (which would be more efficient usage of the blockchain, and help free up tx space for other people to use)
< goatpig>
aj: you mean in their ability to provide non SW wallets with a way to pay into a SW output?
< goatpig>
my plan was to ease my users into SW by defaulting change to SW outputs in the long run
< goatpig>
im more concerned about migrating my users funds to SW than interfacing with non upgraded services
< jl2012>
goatpig, maybe using segwit output as change, but that hurts privacy
< goatpig>
jl2012: how?
< goatpig>
by revealing the change output?
< jl2012>
it indicates which output is the change
< jl2012>
but that's a chicken and egg problem
< goatpig>
but that's basically the case as long as you have a mixed set of outputs
< goatpig>
if you have only SW outputs and you are paying to a legacy output, the same privacy leak takes place
< aj>
goatpig: you can give out an address for people to send money to you that looks like (is) a legacy P2SH address, but that you spend via segwit (ie saving tx fees when you spend it)
< aj>
goatpig: if you have only SW outputs, you're not paying to a legacy output by definition?
< goatpig>
aj: sure but it is less efficient that SW in that you still have to fulfill the p2sh script in the input before interpreting it as SW
< jl2012>
goatpig: you could use native SW as change
< goatpig>
aj: if someone requests a payment to a plain P2PKJ
< goatpig>
P2PKH*
< goatpig>
and i only have SW outputs
< goatpig>
jl2012: that's what i want to run with so far
< goatpig>
if the user wants "soft" SW conversion, send change to native P2WPKH
< aj>
goatpig: then you're *inputs* (or prevouts) are SW, and one of your outputs is the P2PKH
< jl2012>
SW outputs could be sent to anything, P2PKH or segwit
< goatpig>
aj: yes, which is a privacy leak, in the light of jl2012 remarks
< aj>
oops, "your"
< goatpig>
jl2012: sure you can, but if your payee requests a legacy P2PKH payment, chances are his wallet isn't SW compliant
< jl2012>
native SW is a even bigger privacy leak, because there is no address for that
< goatpig>
and he won't see that payment if you force it to SW on your own
< aj>
goatpig: there was a suggestion to have your change address be in the same form as one of the real outputs, so if you're spending to P2PKH, make your change address P2PKH...
< goatpig>
jl2012: no but you are at best stuck with an output you can't spent, at worst you have a weird miscommunication where one end paid and the other lacks the software to aknowledge the payment
< jl2012>
of course they will see it. That's the point of a softfork
< jl2012>
the wallet should not care what the input is
< jl2012>
they just care what the output is
< jl2012>
the input, for an unupgraded wallet, is anyone-can-spend
< goatpig>
there's an argument to be made for non upgrade wallets, that they simply won't consider the output as theirs
< goatpig>
even P2WPKH
< goatpig>
as for native SW, i thought there was a spec for creating addresses out of those?
< jl2012>
if the payee gives you a P2PKH address, you must send to P2PKH, not P2WPKH
< goatpig>
of course
< goatpig>
if all my outputs however are P2WPKH
< jl2012>
so what's the problem?
< goatpig>
that's a privacy leak anyways
< jl2012>
P2WPKH could pay to P2PKH
< goatpig>
so taht goes back to using P2WPKH output change as default and the privacy leak
< goatpig>
wait
< goatpig>
im confusing a couple things here
< goatpig>
nvm
< goatpig>
although that's a bit annoying
< goatpig>
you'd be downgrading a SW output to a P2PKH change in that scenario
< jl2012>
that's by design
< goatpig>
ok
< goatpig>
what's the status on BIP142?
< jl2012>
i mean, it's up to your design. Or just let the user chooses
< goatpig>
more GUI complexity, sweet!
< jl2012>
expert mode
< goatpig>
i just hate working pyqt4
< goatpig>
anyways
< jl2012>
we have some discussion about the address design, like using BASE32
< goatpig>
wait so BIP142 isn't approved?
< goatpig>
and why the sudden change?
< jl2012>
many people hate BASE58
< Victorsueca>
is base32 like base58 but without caps?
< jl2012>
case-insensitive
< Victorsueca>
but addresses would be longer with base32 rigth?
< Victorsueca>
rigth*
< jl2012>
sure
< jl2012>
should be 17% longer with same amount of data
< goatpig>
is it gonna be a little flavored to avoid 0 and o? or i guess the case agnostic aspect covers that?
< Victorsueca>
goatpig: I think base 58 already avoids 0 and O
< jl2012>
there is some discussion to avoid bad word
< goatpig>
Victorsueca: it does, im wondering if the base 32 proposal is gonna
< jl2012>
but anyway, we could only take 4 characters away
< Victorsueca>
it would be base28 then
< jl2012>
no, 26 + 10 - 4 = 32
< luke-jr>
btcdrak: nothing wrong with my DNS seed, so must be on your end?
< Victorsueca>
ahh it's already counted
< jl2012>
so the question is which 4
< Victorsueca>
I would remove 0, O, I and i
< jl2012>
1-L-I ; 0-O
< jl2012>
if you remove O, you may keep 0
< goatpig>
quick question about SW, can i create a SW tx but have all emtpy witness programs?
< Victorsueca>
goatpig: wouldn't e a segwit transaction at all
< Victorsueca>
be*
< jl2012>
you mean something like all inputs are P2PKH?
< btcdrak>
luke-jr: is is not accessible from 3 geolocations I tried.
< goatpig>
jl2012: ive seen that but didnt go over it. thanks
< jl2012>
feel free to ask for clarification
< goatpig>
once i get the signer out of the way ill be back with more i expect
< goatpig>
thanks for the help =)
< Victorsueca>
does bitcoin core support 64-bit POSIX time?
< tonikt>
Hi. Is there a way to find out whether "cmpctblock" message is version 1 or 2, just by looking into the content of the message?
< GitHub141>
[bitcoin] MarcoFalke opened pull request #9042: [rpc] ParseHash: Fail when length is not 64 (master...Mf1611-rpcParseHash64) https://github.com/bitcoin/bitcoin/pull/9042
< GitHub107>
[bitcoin] MarcoFalke opened pull request #9043: [qt] Return useful error message on ATMP failure (master...Mf1611-qtATMPerror) https://github.com/bitcoin/bitcoin/pull/9043
< luke-jr>
btcdrak: well, others seem to hit it fine
< sipa>
tonikt: no
< luke-jr>
Victorsueca: kinda has to, to work on x86_64 Linux
< luke-jr>
sipa: hmm, I understand why that is, but maybe it's going to make life hard for Wireshark >_<
< sipa>
luke-jr: well thankfully the data inside is very similar
< sipa>
2 uses wtxid and can contains witnesses in transactions
< sipa>
1 uses txid and can't
< luke-jr>
yes, but maybe something to keep in mind for future versions
< sipa>
agree
< GitHub139>
[bitcoin] paveljanik closed pull request #8468: Do not shadow member variables in serialization (master...20160805_Wshadow_serialization) https://github.com/bitcoin/bitcoin/pull/8468
< petertodd>
sipa: ah cool, I was having problems with 100% cpu usage; my vps provider kept turning the seed node off
< midnightmagic>
hah, hilarious: <sipa> wow, mtgox almost reached $0.5
< midnightmagic>
oldschool
< sipa>
date?
< Lightsword>
hmm, anyone seeing a bunch of spy nodes from AWS? I’m seeing a pattern of 3 connections per IP to my node
< BlueMatt>
lightningbot: 3 connections seems low...theres been a bunch of deanonymisation services doing like 10/30 per IP from aws
< lightningbot>
BlueMatt: Error: "3" is not a valid command.
< BlueMatt>
ehh, Lightsword
< Lightsword>
BlueMatt, 3 connections per IP, but many sets of 3
< BlueMatt>
yea, thats some deanonmization attack services
< Lightsword>
BlueMatt, yeah and it’s bitcoinj which normally gets kicked since I block bloom filters
< BlueMatt>
its obviously bullshit bitcoinj, because they claim to be actual wallets (multibit, etc) but dont send bloom filters :p
< BlueMatt>
i mean, yes, probably based on bitcoinj, but obviously not real wallets
< sipa>
BlueMatt: looks good. no need to do hashing in the message processing thread
< Lightsword>
BlueMatt, yep, there a good way to filter those out?
< BlueMatt>
Lightsword: ban them? run a script to ban anything that looks like /bitcoinj :p
< BlueMatt>
sipa: ok, pr'd
< GitHub178>
[bitcoin] TheBlueMatt opened pull request #9045: Hash P2P messages as they are received instead of at process-time (master...2016-10-p2p-hash) https://github.com/bitcoin/bitcoin/pull/9045
< Lightsword>
BlueMatt, won’t they just fake useragent if I do that? is there an easy way to ban all clients that aren’t full nodes or is that hard to determine?
< sipa>
BlueMatt: i'm a bit surprised we weren't doing that already, actually :)
< BlueMatt>
sipa: i was as well
< BlueMatt>
Lightsword: well at least it'll fix it temporarily :p
< BlueMatt>
Lightsword: you could hack your shit up to request a recent block on connection and ban if they dont respond?
< gmaxwell>
Lightsword: I put up a ban list previously.
< Lightsword>
gmaxwell, thanks, think that got most of them
< gmaxwell>
128.101.34.77 is another I've seen more recently.
< sipa>
gmaxwell: university of minnesota?
< Lightsword>
any idea why they open 3 connections per IP?
< gmaxwell>
they're trying to bypass the relay privacy protections.
< gmaxwell>
right now we leak somewhat more information if you make more connections.
< gmaxwell>
We should fix that. (I knew that when I put in the currency scheme, but it was better than what we had)
< CubicEarth>
Good day! Does anyone know of a protocol / standard so that wallets from different developers can work together in the creation of a multi-sig address?
< Victorsueca>
Lightsword: I just banned the whole 52.0.0.0/8 space
< Victorsueca>
that will get you rid of most of them
< TD-Linux>
that's effectively all of aws, clearly not a very sustainable solution
< sipa>
only 45% of AWE
< tulip>
none of this is sustainable really. rightward suggested an aliveness test by asking for a block from them, but there's already software which transparently proxies these requests to other peers on the network. it's not feasible to IP ban (because they will evade it with more distributed IPs), if we ban on services on subversions they will just change them.
< sipa>
only 45% of AWS's IPv4 space is under 54/*
< tulip>
s/rightward/lightsword
< sipa>
oh, 52
< sipa>
36% is under 52/*
< BlueMatt>
argh, whens the next block :(
< tulip>
BlueMatt: 10 minutes time.
< tulip>
there's no clear solution to these sybil nodes, regardless. the core problem is they obviously have a huge amount of money to spend attacking the network, and consequently you could assume they're getting results if they're continuing to spend money on this regardless.
< BlueMatt>
well the obvious solution is to fix the bug they're exploiting
< BlueMatt>
if there is no gain from them connecting 10x to each node then hopefully they will go away
< sipa>
is there a reason to assume that hosts in multiple netgroups are harder to obtain than individual ips?
< BlueMatt>
not harder, just more effort and maybe 1.5x cost
< BlueMatt>
well, not hard
< BlueMatt>
tiny bit more effort, not a ton, though
< sipa>
s/harder/costlier/
< BlueMatt>
usually a host will sell you extra ips for reasonably cheap compared to another host somewhere else
< BlueMatt>
but a host that is just proxying traffic is also dirt cheap
< sipa>
otherwise an easy solution would be to use deterministic randomness for the inv push events based on netgroup
< sipa>
so nodes within the same netgroup will see correlated sends
< BlueMatt>
bucketed-announces to most peers is probably the way to go?
< BlueMatt>
it has plenty of issues itself, but at least it solves this specific problem
< sipa>
what do you mean?
< BlueMatt>
gmaxwell's original suggestion of announce live only to eg two statically-selected peers and to the rest, batch inv announcements eg announce every 30 seconds the previous 30 seconds worth of txn you saw
< BlueMatt>
still has correlation issues since prop. is relatively deterministic, but it solves the issue we have now, and you could randomly delay the ~3 peers to which you announce live, as we do now
< gmaxwell>
there are providers that will give you IPs in diverse /8s (even better than /16s) basically for the purpose of tracing users in varrious DHT schemes.
< BlueMatt>
heh, cool
< gmaxwell>
I've never priced it out but I assume it's not horiffically expensive compared to what that one attacker is spending on ec2 costs already.
< BlueMatt>
I'm sure it cant be too much more expensive