< Jmabsd>
"Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis."
< sipa>
that's correct
< Jmabsd>
luke-jr: see there, this doc says a NULL data output (scriptpubkey = "OP_RETURN and a constant") must have amount == 0
< Jmabsd>
where did the amount == 0 requirement come from, what if I like to *BURN*?
< Jmabsd>
where in the core code is this?
< sipa>
there are plenty of other ways to burn
< Jmabsd>
i don't want to TXFEE it
< Jmabsd>
so i have a transaction with one null output. what's the easiest way to add a solid burn logic here?
< sipa>
this has nothing to do with fees
< sipa>
you still pay fees for null data outputs
< Jmabsd>
sipa: an alternative way to burn would be to just mismatch the input txo's amount and the sum of the null data output and the change output:s amounts right
< Jmabsd>
right i know
< sipa>
Jmabsd: that would be creating fee
< Jmabsd>
however this burn scheme is not a miner funding scheme.
< sipa>
you can burn in other ways
< sipa>
just send to an invalid pubkey
< Jmabsd>
would you make a P2SH output that either can't be redeemed, or that contained OP_RETURN?
< Jmabsd>
what's a mathemathically proven ever-invalid pubkey :)
< luke-jr>
sipa: that spams up the UTXO set forever though :<
< Jmabsd>
arr, i'll sign up later.
< Jmabsd>
what has the rationale been for enforcing amount == 0 on null data outputs?
< Jmabsd>
may it be lifted in the future?
< luke-jr>
Jmabsd: make a PR and see if it gets merged?
< sipa>
you can change the code and run it yourself
< sipa>
and convince others to run it
< sipa>
or that
< Jmabsd>
luke-jr: yes good point.
< Jmabsd>
where is the amount == 0 check in the code?
< Jmabsd>
sipa: thank you for emphasising that i should post this kind of Q online, that indeed is way better for knowledge conservation, i'll intend to do it in a while.
< Jmabsd>
do you have an example of a provably-unspendable pubkey? :-}
< sipa>
Jmabsd: if you ask on stackexchange, i promise i'll personally answer it
< sipa>
i can't actually find the 0-value requirement in the code
< Jmabsd>
sipa: exactly, i'm rading the relay code and can't find it too. so i was thinking maybe that bitcoin.org article is bss*ahem*incorrect*ahem*obsolete.
< sipa>
the amount of a CTxOut object is called nValue, so you'd at least need to look for that
< Jmabsd>
nothing.
< Jmabsd>
i would think that Bitcoin accomodated burn already, that's why i was so surprised to see that comment in that bitcoin.org article.
< Jmabsd>
very well. thanks for confirming. i'll presume the article was all incorrect.
< Jmabsd>
in this particular question.
< sipa>
i believe that's the case
< fanquake>
wumpus How'd you go with lxc 3 and getting your new gitian build setup sorted? I've been meaning to switch for the 0.17 builds.
< jonasschnelli>
fanquake: I compiled LXC 2.1 (or similar) on debian stretch and it worked flawless
< jonasschnelli>
haven't tried 3 (since the 2.something version should also work)
< fanquake>
jonasschnelli thanks, I'll play around with it later tonight.
< jonasschnelli>
Is GetTime() to expansive to call on every message decryption?
< wumpus>
fanquake: it worked great, I have succesfully built for linux, mac and windows, and tested the linux build on ARM32
< wumpus>
jonasschnelli: on linux time-related functions are fast because they bypass syscalls (using a DSO), on some other operating systems that will be hellishly slow though; so you'd probably want to avoid caling time functions too often
< wumpus>
jonasschnelli: I remember we had one of the tests that called a time function in an inner loop, no problem on linux, on wine though this was terrible
< fanquake>
wumpus any particular reason for debootstrap 1.0.95 vs 1.0.106 ?
< fanquake>
sorry disregard that, I think I see why.
< wumpus>
it's the ubuntu version, likely the newer one will work too if it includes bionic
< wumpus>
if you get it to work with a newer version I'll update the gist
< wumpus>
huh my freebsd build on master broke
< wumpus>
not sure this is a local issue (it appears that autoconf/automake was updated) or something with the tree
< wumpus>
I'll try building the revision that worked before
< wumpus>
--fails too, so no need to be concerned with this for rc1
< wumpus>
for some reason, --disable-dependency-tracking works around the issue
< wumpus>
I guess we're close to being able to tag rc1?
< jamesob>
pretty big spike in memory usage since Jul 31 https://bitcoinperf.com/timeline/#/?exe=3,4,2,1&base=1+23&ben=ibd.local.522000.dbcache=2048.mem-usage&env=1&revs=50&equid=off&quarts=on&extr=on
< jamesob>
if anyone has any inklings as to why, I'm investigating
< wumpus>
interesting -- is that correlated to a certain commit?
< jamesob>
wumpus: trying to bisect atm
< jamesob>
(the benchmarks were down for most of aug)
< gmaxwell>
jamesob: awesome.
< wumpus>
jamesob: thanks! I guess logs / reflog might be able to give that information as well
< gmaxwell>
https://github.com/bitcoin/bitcoin/pull/13657 I don't understand this change. Coinbase transactions can be conflicted, by being orphaned block. I guess GetDepthInMainChain doesn't return negative in the case, but I think it probably should.
< gmaxwell>
Am I missing something?
< gmaxwell>
I don't see any PR merged in that time span whos description makes me go "duh, obviously that would increase memory usage"