< kallewoof>
So, the make depends part of the macos travis job is taking 35 minutes. leaving ~5-10 minutes for the rest of the build process before travis bops it over the head.
< kallewoof>
Do we really need to ... make everything from scratch every time? It feels quite overkill.
< aj>
downloads might be cached, but the rebuilds sure don't seem to be?
< aj>
(assuming you mean via ccache)
< ken2812221_>
I hava a PR #13515 to fail the travis job if depends build take more than 20 mins, so it can store cache safely.
< gribble>
https://github.com/bitcoin/bitcoin/issues/13515 | travis: Enable Qt build for Windows and 32-bit Linux by ken2812221 · Pull Request #13515 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< kallewoof>
I was wading through logs because make depends made so much output that travis truncated the log. Hence #13654
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13645: [tests] skip rpc_zmq functional test as necessary (master...2018-07-skip-zmq-tests) https://github.com/bitcoin/bitcoin/pull/13645
< pavan>
JOIN
< bitcoin-git>
[bitcoin] afk11 opened pull request #13655: bitcoinconsensus: invalid flags should be set to bitcoinconsensus_err (master...bitcoinconsensus-invalid-flags-squashed) https://github.com/bitcoin/bitcoin/pull/13655
< StayCool>
I just read through some of satoshi's old posts on bitcointalk, and some of the latest ones mention the accounting feature of the JSON-RPC. I find it interesting that Satoshi wanted an implementation of accounts to be available, to easily enable developers to handle customer balances. However currently, it seems like there is consensus from the current developers for completely removing accounts. https://bitcointalk.org/i
< StayCool>
from what i can read, it seems that the primary reason behind removing the accounts feature is that it has had some issues with balances below 0 while not scaling to millions of accounts? I wonder how Satoshi would look at the account feature today.
< luke-jr>
jonasschnelli: why do you insist on keeping a broken mis-feature in scantxoutset? ("address" support confuses users by mixing up addresses and keys, and on top of that, it doesn't even work since p2pk won't get picked up)
< provoostenator>
StayCool: it's mostly just renamed to labels. Keeping funds properly seperate is better achieved by using multiple wallets, a feature that was recently added.
< StayCool>
provoostenator: but this "multiple" wallet feature only scales to about 100-200 wallets, and that is with a rather big amount of RAM. Hopefully the scalability can be increased.
< StayCool>
Also it's not simply a renaming to labels. Some RPC commands will be removed regarding account, for example the move command.
< jnewbery>
StayCool: `move` is utterly broken
< luke-jr>
provoostenator: accounts are in many ways better than multiwallet
< luke-jr>
jnewbery: broken how?
< luke-jr>
it did/does what it is intended to do AFAIK
< provoostenator>
Labels no longer keep funds seperated when they're spent, right?
< luke-jr>
provoostenator: they never did, and never were intended to
< provoostenator>
Right, so that gives a false sense of privacy.
< luke-jr>
only if people don't RTFM
< luke-jr>
(and in some ways, accounts actually improved privacy because of this)
< provoostenator>
If funds aren't seperated in any way, how did "move" make any sense?
< luke-jr>
provoostenator: each account had a balance. move increased the balance of one, and decreased the balance of another.
< luke-jr>
it basically worked fine AFAIK, except 1) didn't scale and 2) didn't backup very well
< provoostenator>
And because of the funds mixing, you could end up with negative balances (though the sum would be 0)?
< luke-jr>
provoostenator: you get negative balances by move-ing more funds than your source account had
< luke-jr>
and possibly with fees; I forget how those worked
< luke-jr>
eg, if accountA has 1 BTC, move 2 BTC and now it has -1 BTC
< provoostenator>
Proof that Satoshi wanted fractional reserves ultimately :-P
< StayCool>
i think the issue with fees was fixed when sendtoaddress included a subtractfee parameter, before that sendfrom was used which could result in a negative fee if the fee was higher than the amount
< StayCool>
how come the accounts feature doesn't scale very well?
< StayCool>
negative amount not fee*
< luke-jr>
StayCool: all move-s were basically kept in RAM
< StayCool>
you mean move-s using the "move" command, or all transactions?
< bitcoin-git>
[bitcoin] 251Labs opened pull request #13656: Remove the boost/algorithm/string/predicate.hpp dependency from netbase.cpp (master...patch/remove_boost_predicate_from_netbase) https://github.com/bitcoin/bitcoin/pull/13656
< bitcoin-git>
[bitcoin] Empact opened pull request #13657: wallet: assert to ensure accuracy of CMerkleTx::GetBlocksToMaturity (master...accurate-get-blocks-to-maturity) https://github.com/bitcoin/bitcoin/pull/13657
< bitcoin-git>
[bitcoin] Empact opened pull request #13658: [wallet] [moveonly] Move rescanning from time logic into wallet/rpcdump.cpp (master...rescan-from-time) https://github.com/bitcoin/bitcoin/pull/13658
< gmaxwell>
StayCool: beyond being somewhat flaky, the accounts feature is just inherently unsafe to use because there is no way to make it durable. Say you withdraw under a seperate account, but then crash right at the same time. Its possible for the transfer to have gone through but the account binding information to be lost.
< gmaxwell>
provoostenator: like luke said, multiwallet is in absoltely no way a replacement for accounts, and for the application of accounts multiwallet is tremendously worse.
< gmaxwell>
Nor is multiwallet intended to be a replacement for accounts.
< gmaxwell>
The replacement for accounts is managing them in your own front end accounting database... which can be made durable and scalable.
< gmaxwell>
StayCool: as far as what satoshi thinks, I think it's quite likely that he'd agree now that we can't manage the complexity of the software by craming in every additional piece of functionality that could be done just as well (or better) outside of the software. But if he didn't? Who cares? Lots of people disagree about this or that here and there.
< gmaxwell>
luke-jr: I don't agree with your addresses comment above. Addresses are highly useful ways to identify txouts. It doesn't 'mix up addresses and keys' -- it lets you query by "give me the txouts that were sent to this particular address" which is highly useful, since the address is likely the only identifying mark that the user has previously seen for whatever set of txouts they're aware of.
< gmaxwell>
provoostenator: to be clear, accounts never kept funds seperate, nor were they intended to. They accounted for different attribution for funds while not keeping them seperate.
< luke-jr>
gmaxwell: txouts aren't sent to addresses; bitcoins are. the txouts created don't get associated with the address
< luke-jr>
it's an important distinction, because otherwise you get people thinking the validity of a UTXO means the person who received at that address owns those funds
< gmaxwell>
touts are spendable by a specific scriptpubkey, which an address encodes. It's written write into them.
< luke-jr>
an address is an opaque abstraction; that it is implemented by encoding a scriptpubkey is a technical detail unrelated to the address itself
< gmaxwell>
You're just wasting people's time arguing that scanning shouldn't match by address. Thats 99.9% of the utility of it for me and many others. People are not going to go "gee luke, you're right. I guess we'll handicap this feature to make it useless to us even personally then merge it anyways"
< gmaxwell>
Moreover, consistency with listunspent demands it.
< luke-jr>
if listunspent has such a bug, that should get fixed. UTXOs and addresses do not mix, or you end up with "send from", "address balance" and similar nonsense
< gmaxwell>
"send from" is a bit of confusion about the properties of the spending transaction, not properties of the txouts.
< luke-jr>
the spending transaction is spending txouts
< gmaxwell>
touts identified by txid:vout, not by address.
< luke-jr>
UTXOs are identified by txid:vout, not by address.
< gmaxwell>
I'm all for avoiding confusing functionality that isn't important. But without the ability to match by address this scanning stuff (as well as listunspent) would be almost useless.
< gmaxwell>
luke-jr: indeed, they are not, if they were identified by address you wouldn't need a scan function to go from address to identifier!
< gmaxwell>
The purpose of a scan function is to go from a non-identifying property about something to the identifier(s).
< instagibbs>
Empact_, I'm seeing a number of "move only" PRs, now I'm unsure of the definition of move only.
< luke-jr>
if address was a property of UTXOs, then addresses would have balances, and addresses would send coins
< instagibbs>
Your PRs are encapsulating and de-duplicating behavior, to me that's not move only, but maybe I have my personal biases on the meaning
< Lauda>
Is it possible that txindex building is doing too many operations? According to linux mint system monitor it did: read total 3.0 TiB, write total 276.6 GiB
< Lauda>
Seems excessive, and I compared to the network traffic (insignificant in comparison) so it isnt block serving
< sipa>
Lauda: no, validation is very heavy in i/o; it should go down with large dbcache
< Lauda>
this was with ~5-6GB being used by qt
< Lauda>
did anyone ever benchmark something like this? If so, I'd like to take a look :)
< sipa>
StayCool: the biggest issue with accounts is that it effectively requires you to make a backup after every address you generate
< sipa>
StayCool: plus 99% of people assume they work like multiple wallets, and that acxounts represent sets of UTXO (instead of being bean counters internal to a wallet)
< gmaxwell>
Not just after every address you generate, but also backup concurrently with sending funds-- e.g. any time you spend in an account you'd need to backup before broadcasting the transaction.
< sipa>
luke-jr: of course "balance of an address" is a technically meaningful and consistent thing to define
< sipa>
luke-jr: every output has an associated locking script
< sipa>
an address is a shorthand way to write some (most) locking scripts
< sipa>
that doesn't mean balance of an address is a useful abstraction to show users; you're very correct that it is confusing to people
< sipa>
however, scantxoutset is an RPC that inherently breaks that abstraction - it exposes the user to a lower level view than a wallet
< sipa>
just like listunspent, createrawtransacrion, gettxoutsetinfo, ...
< sipa>
i don't think there is a risk for confusion there; you can't use the RPC unless you already understand that internally wallets are backed by sets of unspent outputs
< sipa>
i would be opposed to a getaddressbalance RPC that reported the sum of the values in all unspent utxos with a locking script that corresponds to a given UTXO
< sipa>
but scantxoutset doesn't do that; it gives the actual UTXOs
< sipa>
luke-jr: another principle perhaps is that you shouldn't try to guess what address a txout was sent to by looking at its script; but given address you can always convert it to a script and see what matches
< sipa>
(the "stealth address test")
< gmaxwell>
reminder #13298 needs acks
< gribble>
https://github.com/bitcoin/bitcoin/issues/13298 | Net: Random delays *per network group* to obfuscate transaction time by naumenkogs · Pull Request #13298 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] Empact closed pull request #13619: Include cstring alongside select in compat/glib_sanity.cpp (master...glib-sanity) https://github.com/bitcoin/bitcoin/pull/13619