< jeremyrubin>
sipa: the biggest things in c++14 is ergonomic I think -- things like make_unique
< jeremyrubin>
also being able to move a var into a lambda is a good feature
< phantomcircuit>
is there an rpc call that will decode a raw transaction, lookup the inputs in the utxo and tell you how much it's paying in fees?
< GitHub176>
[bitcoin] NicolasDorier opened pull request #8665: Trivial: ContextualCheckBlockHeader should never have pindexPrev equals to NULL (master...fixup) https://github.com/bitcoin/bitcoin/pull/8665
< dcousens>
phantomcircuit: you could just iterate over the inputs and grab them yourself? Or is the point to be 'all in one'?
< phantomcircuit>
dcousens, the point is to be lazy :P
< phantomcircuit>
er uh
< phantomcircuit>
yes all in one!
< phantomcircuit>
this seems like something decoderawtransaction should attempt to do
< dcousens>
phantomcircuit: understandably, but, you could do that for so many RPC calls :S
< dcousens>
you could probably use wumpus's RPC extension idea to do this
< phantomcircuit>
dcousens, indeed i can do this with the gettxout rpc call
< phantomcircuit>
but well
< phantomcircuit>
so much work
< dcousens>
dcousens: really? its like 5 lines of JS, if you're using JS
< dcousens>
depending on whether you're doing batched results or not, I suppose
< dcousens>
rpc('decoderawtransaction', [txHex]... async.map(result.ins, (input, callback) => { rpc('getrawtransaction', [input.txid, true], (err, tx) => { callback(null, tx.outs[input.vout].value) }) ... or some such
< dcousens>
or even the gettxout rpc haha
< dcousens>
but that might depend on your needs, IIRC gettxout is for UTXOs only
< sipa>
phantomcircuit: it can't generally work, unless all inputs are still unspent
< sipa>
we could add it as output to sendrawtransaction perhaps, which always knows the fee
< BlueMatt>
ok, so ubuntu 12.04lts is still supported with gcc 4.6.3...bitcoind will refuse to ./configure on that because it doesnt support -std=c++11.....
< BlueMatt>
so options are: hack things to compile with -std=c++0x (terrible idea, lets not do this), leave it on 0.12.1, or "upgrade" it to a dummy package that removes bitcoind and just gives a popup that tells people to upgrade
< Lightsword>
BlueMatt, can’t you just update gcc?
< Lightsword>
is this for ppa?
< BlueMatt>
for ppa, yea
< BlueMatt>
i mean I could probably convince launchpad to install a backported gcc for the building of that package
< BlueMatt>
but....eww
< Lightsword>
BlueMatt, does launchpad compile it themselves or do you compile it locally then upload it to them?
< BlueMatt>
they do the compilation
< BlueMatt>
if not I'd just be uploading the statically-compiled packages
< BlueMatt>
gitian ones, that is
< sipa>
i wonder how much of c++11 we use in 0.13.0
< BlueMatt>
I mean I'd bet it would compile and probably work, but I'm not really sure I'd want to ship something that probably works and might have compiler bugs in it
< sipa>
maybe std::atomic is the only thing
< sipa>
yes, agree
< BlueMatt>
whats min gcc we support?
< sipa>
4.7
< Lightsword>
BlueMatt, is clang on 12.04 a high enough version?
< sipa>
4.7 may just work
< sipa>
eh, 4.6 may just work
< sipa>
with -std=c++0x
< BlueMatt>
sipa: it does not recognize -std=c++11, only -std=c++0x
< BlueMatt>
yes, I'd kinda prefer to not do that?
< sipa>
does 4.6 have any known bugs?
< BlueMatt>
this is my question, I suppose
< BlueMatt>
Lightsword: good point, looks like that could be an option
< Lightsword>
BlueMatt, does launchpad not let you use a custom gcc version?
< BlueMatt>
Lightsword: yea, I've generally wanted to move to a model where the packages are install-once and just contain the gitian verifier
< BlueMatt>
lightningbot: and then they decide to update when they see new gitian-signed updates
< lightningbot>
BlueMatt: Error: "and" is not a valid command.
< BlueMatt>
arg
< BlueMatt>
Lightsword: but I've never gotten around to doing it....would love for someone to do so
< Lightsword>
BlueMatt, well with a custom repo I think it would just use the same signature scheme as normal packages
< BlueMatt>
yes, that would also probably be a step up from the launchpad-controlled keys that are used now
< Lightsword>
yeah, and should be fairly simple
< BlueMatt>
ehh, I mean then we have to secure a hosted server
< BlueMatt>
or.../I/ have to
< Lightsword>
bitcoincore.org or bitcoin.org?
< BlueMatt>
much eaiser to have an install-once gitian verifier
< BlueMatt>
bitcoin.org maybe, but I'd prefer to not put it there
< BlueMatt>
bitcoincore.org has deliberately never hosted bins
< BlueMatt>
(for this reason)
< gmaxwell>
it is _not_ acceptable to have autoupdates. Install once should be fine, but the users should trigger the update. (It could notify and such too)
< kanzure>
are the launchpad builds signed by anything other than launchpad?
< Lightsword>
they would still be signed…just like normal ubuntu packages
< Lightsword>
gmaxwell, it wouldn’t be any different from ppa
< BlueMatt>
gmaxwell: yesyes, by gitian-verifier I mean a notification of update and install through gitian verification
< BlueMatt>
kanzure: no
< gmaxwell>
BlueMatt: great.
< BlueMatt>
kanzure: the upload from me to launchpad is pgp-signed (ie the source files are), but launchpad just takes those and builds the bins and signs with keys it controls
< BlueMatt>
kanzure: its really quite a shitty model
< BlueMatt>
but, afaiu, they are built on a similar set of boxes as the actual ubuntu builds, so....
< gmaxwell>
Lightsword: the difference is that if bluematt wants to be kidnapped by having the ability to trigger automatic updates or court ordered, thats his own problem. it's not one that should be extended to other contributors to the system.
< Lightsword>
is it possible to have multiple signers for normal package managers?
< BlueMatt>
Lightsword: only via the multisig rsa stuff, I'd presume
< Lightsword>
gmaxwell, do you consider apt-get update && apt-get upgrade to be an automatic update?
< Lightsword>
ie using signed apt repository system
< gmaxwell>
I consider that not my problem.
< BlueMatt>
luckily right now its probably 10x easier to make launchpad push a new build than convince me to :p
< Lightsword>
wonder how easy it would be to do an apt repository using the gitan sigs as multisig
< BlueMatt>
afaiu the multisig-rsa stuff requires collaborative setup
< BlueMatt>
but I havent heard anything about it in like 5/10 years, maybe it didnt even work
< gmaxwell>
it works fine.
< BlueMatt>
seems like something gmaxwell would remember
< BlueMatt>
heh, there we go :p
< gmaxwell>
worse than collaborative setup, the straight forward construction requires a trusted dealer.
< gmaxwell>
but it's one time trust at least, assuming the dealer doesn't retain the key.
< BlueMatt>
iirc someone had a multiuser setup for it?
< kanzure>
this would be to avoid distributing a program to verify individual separate gitian signatures?
< gmaxwell>
there is some MPC approach to it, but it's seriously more complex.
< BlueMatt>
gmaxwell: sure, ofc....
< gmaxwell>
kanzure: it's whats required to make the apple and msft signing threshold secure.
< BlueMatt>
kanzure: yes, the idea is that you would do multisig-rsa where the verifier is simple rsa
< BlueMatt>
kanzure: that way you can make android/apt/yum/apple/etc/etc validate your multisig in their normal package validation routines
< kanzure>
yes well it would be nice to use the default package validation infrastructure i guess, although i don't know how to balance that with discouraging people to use PPAs in the first place.
< Lightsword>
kanzure, well custom authenticated repo is better than ppa at least
< kanzure>
er, this seems sort of backwards; the reason why the ppa is being used at all with launchpad builds is because -- well nevermind i shouldn't point this out i guess.
< BlueMatt>
Lightsword: it does require I maintain (a) a secure build server, (b) a secure server to serve off of (kinda, I guess really just a secure way to serve the pgp key which signs the packages), and (c) get kidnapped :p
< kanzure>
if you are going to be doing a secure build server then you might as well use the gitian builds in the first place
< BlueMatt>
yup
< Lightsword>
BlueMatt, well if you can do it with multisig-rsa with gitian main thing is just serving the initial pgp key securely
< kanzure>
but the reason why this is not done is not because of the difficulty of doing gitian things, Lightsword
< Lightsword>
yeah, I know autoupdates are to be avoided…but this isn’t any worse than the ppa is IMO
< kanzure>
no i mean, the ppa is pretty awful, i think people with their heads on straight are correctly avoiding it
< BlueMatt>
kanzure: people with their heads on straight are correctly avoiding ubuntu for their bitcoin node hosting, I'd think
< BlueMatt>
kanzure: but the number of people who even validate gitian sigs is probably +/- 0
< kanzure>
let's not get too optimistic
< * sipa>
hides in a corner
< kanzure>
:)
< Lightsword>
uh, a lot of pool servers use ubuntu
< BlueMatt>
the number of people building themselves is like....non-0
< BlueMatt>
but the folks who might otherwise validate gitian sigs probably build themselves
< BlueMatt>
Lightsword: I'd assume they dont use the ppa, though?
< kanzure>
do not ask questions you don't want the answer to
< BlueMatt>
Lightsword: if the answer is that they do, please dont respond
< Lightsword>
BlueMatt, I did early on but haven’t for a while
< BlueMatt>
kanzure: yea, fair point
< Lightsword>
a lot of people do seem to be using the ppa though
< Lightsword>
since it’s in a lot of guides
< BlueMatt>
yes, this is true
< BlueMatt>
well yea, lots of folks use it since its easy to install, reasonable to keep up-to-date, etc
< CocoBTC>
I don't think many people understands the risk
< CocoBTC>
s
< BlueMatt>
anyway, I'll get a secure build server and switch it to not-launchpad-hosted when someone gets a reasonable server which we all feel comfortable hosting binaries on :p
< Lightsword>
BlueMatt, I can host one if you want for the signed binaries, would probably not want to be hosting the pgp key though myself :P
< BlueMatt>
yea, thought so :p
< Lightsword>
not sure how best to distribute that though
< BlueMatt>
one of these days I'll fly somewhere decent and buy a rack with some crazy tempest protection and explosives inside and host shit there
< BlueMatt>
one of these days........
< Lightsword>
I mean, I’m pretty sure I can run a secure server…just by limiting attack surface by only running nginx and ssh key based auth and nothing else
< BlueMatt>
Lightsword: right up until someone figures out where its hosted :P
< Lightsword>
well…I usually put my stuff behind cloudflare to prevent that…
< BlueMatt>
remember: the value of compromising this would be more than what the fbi paid cmu to compromise tor to locate dark net market sites
< BlueMatt>
also, FUCK CMU
< sipa>
there's a swiss company that houses server inside a bunker inside a mountain
< Lightsword>
yeah, this is really just an initial key distribution problem though
< Lightsword>
could just stick it on bitcoin.org
< BlueMatt>
sipa: there are many of those....thats fine right up until you dont want the owner of the mountain to have access
< sipa>
BlueMatt: details
< BlueMatt>
heh
< sipa>
:p
< Lightsword>
could maybe just put the key on github…
< BlueMatt>
*stab*
< Lightsword>
and a few other places
< BlueMatt>
but, yea, the key distribution is more of a problem, I suppose
< kanzure>
i thought "open access policies" were good?
< kanzure>
maybe that's something else.
< jeremyrubin>
buys old mine shaft, quick-crete, and 100 m ethernet cable
< BlueMatt>
but I dont particularly want to have /the/ key that can sign for lots of updated bitcoin-qt clients
< Lightsword>
yeah..multisig-rsa would be nice...
< BlueMatt>
jeremyrubin: I prefer old oil shafts....1 mile down? no problem!
< Lightsword>
for signing the builds….wonder if a m of n scheme is possible
< Lightsword>
with authenticated repository infrastructure
< BlueMatt>
Info: there will be a little „hackathlon“ event after the #scalingbitcoin conference in Milan. Mo/Tue, 10th-11th October. More infos to come
< BlueMatt>
ie another core hackathon after scaling bitcoin: milan, monday and tuesday
< BlueMatt>
general fyi: book your accomodation to wed, if you feel like sticking around to do in-person Bitcoin Core code review/hacking just like the last few times
< Lightsword>
is there any actual usable code for multisig rsa?
< phantomcircuit>
BlueMatt, just replace the ppa thing with something that downloads that static binaries to $HOME
< phantomcircuit>
(yes yes stabs face)
< BlueMatt>
phantomcircuit: yes, with gitian verification
< BlueMatt>
phantomcircuit: you jest, but I'd actually like to do something like that
< BlueMatt>
though probably not $HOME
< BlueMatt>
Lightsword: some folks said they had code for it
< BlueMatt>
maybe gmaxwell
< Lightsword>
could always just download to /usr/bin :P
< BlueMatt>
people might hate you more for that
< BlueMatt>
lol, in writing the compact block version negotiation spec:
< BlueMatt>
"As a node must send all sendcmpct messages which contain a novel version announcement before any other compact block-related messages, it is possible to determine which version of compact blocks will be used for each object received. It is, however, not possible to know which version will be used to encode the response to a request for a compact block object before any MSG_CMPCT_BLOCK-containing inv, cmpctblock, getblocktxn, or
< BlueMatt>
blocktxn messages have been exchanged."
< BlueMatt>
that seems...irritating
< BlueMatt>
actually, add ping to that list :)
< * BlueMatt>
prepares for someone to get very upset now
< BlueMatt>
sipa: nvm, I just posted text for compact block version negotiation ont he pr...I think its not crazy, but it is awkward (eg the above text)
< BlueMatt>
it might require slight implementation tweaks, though nothing major, I think
< BlueMatt>
copied from -wizards:
< BlueMatt>
<BlueMatt> is there any interest in a fibre/propagation talk by me in milan?
< BlueMatt>
<BlueMatt> frankly I find fibre to be somewhat self-explanitory and could likely only talk for about 3 minutes at a really technical level about it
< BlueMatt>
<BlueMatt> but this may be some form of the the-thing-i-work-on-of-course-seems-self-explanitory-because-i-work-on-it effect