< phantomcircuit>
gmaxwell, when fuzzing deserialization, should i treat throwing exceptions as a crash or as an expected result
< gmaxwell>
phantomcircuit: depends on the exception.
< gmaxwell>
The deceralization uses exceptions (spit) to do error reporting. So you shouldn't treat as crash ordinary errors during deseralization.
< phantomcircuit>
gmaxwell, the serialization stuff will throw std::ios_base::failure when there's a short read
< gmaxwell>
Not a crash.
< phantomcircuit>
ok that's what i thought
< gmaxwell>
basically, you only want to treat as crashes things that you might possibly want to go fix.
< gmaxwell>
:)
< phantomcircuit>
gmaxwell, that reminds me (although i dont know why) that i wanted to do a vm with the glibcxx_debug flag
< gmaxwell>
phantomcircuit: that would be very handy to have.
< phantomcircuit>
also fun fact
< phantomcircuit>
the sort command is threaded
< gmaxwell>
I know. it uses a merge sort with storage in /tmp.
< gmaxwell>
it's actually quite good.
< midnightmagic>
Un-fun fact. Sort uses the locale for sorting order, which if it's not 'c' and is e.g. en_CA.UTF-8, puts capital 'H' *after* lowercase 'i'.
< gmaxwell>
yea, the standard posix string functions all became localized in the 90s. And this means that e.g. number parsing functions change behavior (comma vs dot handling) ... resuting in lots of broken software that was using them for handling file formats and network protocols.
< gmaxwell>
Which goes back to my standard advice of not using strings anywhere normative. :)
< luke-jr>
anyone know what testnet blocks made csv change states?
< phantomcircuit>
luke-jr, something with timestamp around 1456790400,
< luke-jr>
gmaxwell: don't you need to explicitly enable locales for POSIX?
< phantomcircuit>
maybe?
< phantomcircuit>
gmaxwell, oops deleted my afl-cmin results
< gmaxwell>
phantomcircuit: some of these are used internally in others, so I'm not sure if they should be added at the top level or not.
< phantomcircuit>
gmaxwell, CBlockHeader is kind of covered by CBlock, but yeah
< gmaxwell>
yea, well the rule should be if a hash or something is going to prevent AFL from finding an input that lets it reach thoe whole thing, you should go directly.
< gmaxwell>
phantomcircuit: the next improvement you could do is, assuming the deseralization was successful you could try calling some methods on the object. (e.g. whatever we'd normally do after deseralizing it).
< phantomcircuit>
gmaxwell, heh one of these is crazy slow
< GitHub117>
[bitcoin] pstratem opened pull request #7930: CAddrMan::Deserialize Initialize to NULL on insane input. (master...2014-04-23-addrman-deserialize-limits) https://github.com/bitcoin/bitcoin/pull/7930
< sipa>
wumpus, jonasschnelli: i'm trying to call uiInterface.ShowProgress from the import thread (to show -reindex progress), but it results in a deadlocked UI
< GitHub10>
[bitcoin] sipa opened pull request #7933: Fix OOM when deserializing UTXO entries with invalid length (master...fixcompressoroom) https://github.com/bitcoin/bitcoin/pull/7933
< NotAnNSAgent>
.
< NotAnNSAgent>
Why is there no boolean flag for each transaction called something like "has_been_dealt_with"?
< NotAnNSAgent>
I must have my own, separate DB table just to store which txids have been dealt with? Or maybe there is? I can't see one.
< sipa>
define "dealt with"
< sipa>
seen? included in the mempool? rejected? relayed? in the utxo set? in the blockchain?
< NotAnNSAgent>
sipa: In my case, "recorded by application logic".
< NotAnNSAgent>
sipa: In the case of a GUI user, such as myself on this desktop computer, it would refer to "having seen it".
< NotAnNSAgent>
sipa: Transactions just come in and I have no idea which ones I've "seen" and "dealt with".
< NotAnNSAgent>
Since Windows 10, the Bitcoin Core client for Windows uses the awful Windows 10 notifications, which I've been forced to turn off globally.
< NotAnNSAgent>
As soon as I enable them, I'm constantly pestered by idiotic notifications.
< NotAnNSAgent>
And it appears to be impossible to enable them only for Bitcoin Core.
< sipa>
file an issue, please
< NotAnNSAgent>
I thought that was what I'm doing right now...
< NotAnNSAgent>
But my main issue is when using the bitcoind through the RCP API.
< NotAnNSAgent>
Does the bitcoind/wallet.dat really store nothing of this sort?
< sipa>
the wallet remembers all wallet transactions
< NotAnNSAgent>
?
< sipa>
i'm not sure what kind of notifications you're talking about, as i haven't used windows or the bitcoin core GUI in a long time
< sipa>
but if they're annoying, there should be a way to turn them off
< NotAnNSAgent>
How does my program display only new transactions?
< NotAnNSAgent>
It would have to manually remember which ones have been seen/dealt with.
< sipa>
what is 'your program' ?
< NotAnNSAgent>
Why doesn't the wallet.dat/bitcoind remember which transactions have been "processed" and which ones are new?
< sipa>
if you're talking about the wallet, it does
< NotAnNSAgent>
Is this really the case?
< NotAnNSAgent>
It does?
< sipa>
if you're talking about the verification logic, it does not and this should not matter
< NotAnNSAgent>
What's the API call called for figuring the status out?
< sipa>
can you please tell me what kind of notification you're talking about?
< NotAnNSAgent>
I'm not talking about any notifications...
< NotAnNSAgent>
I'm talking about a FLAG in the API for transactions that can be true or false.
< NotAnNSAgent>
Is there such a thing?
< NotAnNSAgent>
"has_been_processed" or something?
< NotAnNSAgent>
Something I can use to not have to store a separate database just to remember which txids I've processed?
< sipa>
if you're not talking about notification, then what does "has_been_processed" mean?
< sipa>
you're presumably using a polling mechanism to update the state
< sipa>
so the relevant question is whether you have already seen a transaction, not whether bitcoind had
< sipa>
*has
< NotAnNSAgent>
...
< NotAnNSAgent>
So does this mean no?
< sipa>
i'm afraid i don't understand your question
< sipa>
you're trying to create an application that does something once for every transaction (every wallet transaction, i assume)?
< sipa>
if so, there are 2 possible mechanisms
< sipa>
either a polling-based approach (for example, listtransactions or getreceivedbyaddress RPC)
< sipa>
or a push-based approach (for example, -walletnotify or ZMQ)
< sipa>
in case of a polling approach, you'll only be notified once for each transaction
< sipa>
eh, in case of a push-based approach
< sipa>
in the case of a polling based approach, bitcoind cannot know what you have already seen or not, so there is no way to do what you're asking
< sipa>
but even if you're using ZMQ or -walletnotify, you'll still need to use RPC to sync up in case your application restarted for example
< NotAnNSAgent>
sipa: That's why I don't use "walletnotify" directly.
< NotAnNSAgent>
sipa: I have "handle_new_bitcoin_donations.php" which I execute upon walletnotify (not caring about the %s you can send with it) as well as every hour as a cronjob.
< NotAnNSAgent>
sipa: That script simply grabs the latest 100 transactions and is supposed to "process" (do some application logic) for each new one.
< NotAnNSAgent>
sipa: In the situation I'm in, this is a dedicated server at home which has no SQL database installed/setup.
< NotAnNSAgent>
sipa: I was trying to get around having to set that up just to keep a list of all txids that my script has "processed"/"seen".
< sipa>
there is no solution for that, as bitcoind knows what it has seen, but it can't possibly know what you have seen
< NotAnNSAgent>
sipa: That's why it would be a boolean flag, as I've been trying to say a number of times now.
< sipa>
a boolean flag inside your application, yes
< NotAnNSAgent>
Meaning I would do something like "updateseenflag <txid> true".
< sipa>
bitcoind is not a database
< NotAnNSAgent>
(If it had supported that)
< sipa>
sorry, feature creep :)
< NotAnNSAgent>
sipa: How can you possibly call that feature creep?
< NotAnNSAgent>
It's the very basic associated flag IMO.
< NotAnNSAgent>
I mean, you can't rely on "walletnotify" to send once the txid and expect that the receiving script/server is up and running at that specific time, as you said.
< NotAnNSAgent>
So you have to do the "poll" method.
< sipa>
or use ZMQ, but still poll once at startup or whenever the connection is reset
< NotAnNSAgent>
I mean, as I said, I do use walletnotify, but only to "run the usual script" and not specifically for that txid (which I don't even capture).
< NotAnNSAgent>
What is ZMQ?
< sipa>
google is your friend
< NotAnNSAgent>
No, it's not.
< sipa>
sorry, i'm not your personal assistant
< sipa>
look into ZMQ, it may do what you want
< sipa>
otherwise, you'll need a database (or even just a text file!) in which you record what you've seen already and what you've done with it
< luke-jr>
NotAnNSAgent: your idea breaks down when you have more than 1 program "processing" transactions
< sipa>
despite that, it's open source, so you don't need anyone's permission to add such functionality to the code (for yourself, or present it as patch for including upstream)
< GitHub188>
[bitcoin] sipa opened pull request #7934: Improve rolling bloom filter performance and benchmark (master...benchrollingbloom) https://github.com/bitcoin/bitcoin/pull/7934
< luke-jr>
indeed, the wallet actually has extensibility that you could probably add it in a way that's backward compatible
< luke-jr>
and won't get removed if you accidentally run a non-compatible version
< NotAnNSAgent>
Hmm @ multiple programs.
< NotAnNSAgent>
How often would you have that? Seems like an odd thing to do.
< NotAnNSAgent>
As for being open source... that's an fallacy. I'm not an expert coder and don't have the ability to sit down and figure out how everything works, much less release my own branch of that software from that point on.
< sipa>
NotAnNSAgent: you can pay someone :)
< sipa>
but it's also a fallacy to think that everyone has the same priorities for the code as you do
< NotAnNSAgent>
No, I can't pay someone.
< NotAnNSAgent>
You'd think this feature would've been thought of for 0.1.0.
< NotAnNSAgent>
Different Core question, about the GUI application. How do you edit labels?
< luke-jr>
0.1.0 is not 1.0.0
< luke-jr>
and yes, you can pay someone; that's how code gets written typically
< sipa>
NotAnNSAgent: sorry, we're all volunteers here; code gets written that someone spends their time on
< NotAnNSAgent>
If they accept invisible money that I don't have, maybe.
< NotAnNSAgent>
Sure. Just trying to understand the reasoning.
< NotAnNSAgent>
I'll likely go for the text file.
< NotAnNSAgent>
But who knows what happens if it gets corrupted?
< NotAnNSAgent>
Or how slow it becomes after X transactions?
< luke-jr>
NotAnNSAgent: wallets can get corrupted just as easily
< NotAnNSAgent>
:/
< luke-jr>
and bitcoind's wallet is not optimised at all
< NotAnNSAgent>
Optimized?
< sipa>
if you need reliability, you need a backup mechanism
< sipa>
bitcoin core's wallet is design so it only needs a backup every 100 (or whatever you set the keypool size too) transactions
< sipa>
if you're going to put application data inside the wallet, that requirement becomes: for every transaction
< luke-jr>
sipa: well, you need a backup immediately for any metadata changes of course
< sipa>
luke-jr: indeed
< luke-jr>
hm, deadlock in almost-master
< luke-jr>
or not, maybe it's just busy :P
< luke-jr>
invalidateblock far back is slow <.<
< sipa>
luke-jr: haha, yes
< sipa>
it needs to rewind the entire UTXO set
< sipa>
though a lot is due to it trying to keep the mempool in sync
< sipa>
in segwit i have a patch that makes it bypass that
< NotAnNSAgent>
Makes sort of sense.
< NotAnNSAgent>
How do you edit labels in Core GUI?
< NotAnNSAgent>
Maybe it's not possible?
< sipa>
i have no idea, sorry
< luke-jr>
NotAnNSAgent: right click
< luke-jr>
(answering that was what I was trying to do when I realised it was blocked :P)
< luke-jr>
it's common sense though, in most cases
< luke-jr>
the one case that *doesn't* work sanely, is when you're sending via payment protocol
< luke-jr>
in that case, you have to go to the transaction list after you send, and edit it in
< luke-jr>
note that GUI labels aren't really well-supported in the RPC yet
< sipa>
there is a half-and-half overlap between RPC accounts and GUI labels
< NotAnNSAgent>
luke-jr: Right-click only has "Copy label".
< NotAnNSAgent>
(This is not a practical problem anymore because I deleted it and created new ones)
< NotAnNSAgent>
But I still wonder what you meant.
< NotAnNSAgent>
luke-jr, sipa, etc.: What is the "id" that I can send used for?
< NotAnNSAgent>
That is: 'jsonrpc' => '1.0', 'id' => 'curltest', 'method' => 'getbalance'
< sipa>
NotAnNSAgent: it's part of the JSON-RPC specification
< sipa>
i think it's just echoed back in the response
< NotAnNSAgent>
sipa: It is, but why?
< NotAnNSAgent>
Also, another question: sendfrom <-- What if I don't know which account (or no account) holds the money I want to send?
< NotAnNSAgent>
Or rather, I didn't assign it to any particular account.
< sipa>
NotAnNSAgent: then you're using the "" account
< sipa>
NotAnNSAgent: for why, i din't know... ask the people who wrote the JSOn-RPC spec :)
< NotAnNSAgent>
Hmm.
< NotAnNSAgent>
sipa: "<amount> is a real and is rounded to 8 decimal places." <-- 0.1 seems to not mean "one tenth of a Bitcoin".
< NotAnNSAgent>
(Thanks for the "" account tip)
< sipa>
yes it does mean that
< NotAnNSAgent>
sipa: Hmm. It doesn't seem to take 0.1 away from the balance.
< NotAnNSAgent>
Maybe something weird is happening because I'm not quoting it, and PHP is mangling it or something.
< NotAnNSAgent>
Oh. No. I just interpreted the data wrong. Sorry.
< NotAnNSAgent>
Hmm. I'm somewhat confident that my tests are now ready to be turned live. But that's scary.
< NotAnNSAgent>
I've essentially coded a little "bank" this last week.
< NotAnNSAgent>
Based around a bitcoind-
< NotAnNSAgent>
Have "accounts" existed since the very beginning?
< NotAnNSAgent>
Very useful they are.
< NotAnNSAgent>
Though I wonder how that works out with pre-generated safety addresses which aren't assigned to any account.
< sipa>
NotAnNSAgent: those are not assigned an address until you call getnewaddress
< sipa>
eh, a label
< sipa>
also, accounts are very likely not doing what you think they are
< NotAnNSAgent>
A label?
< NotAnNSAgent>
A label is something different from an account... no? Why did you call accounts labels right now?
< sipa>
and are deprecated and planned to be removed (and just be replaced by address labels)
< sipa>
labels and accounts are effectively the same thing
< NotAnNSAgent>
Are you saying that I've just implemented a deprecated concept?
< NotAnNSAgent>
And says it has not been reviewed.
< sipa>
pro life tip: thongs that indicate they have shortcomings are often much better than random claims :)
< sipa>
the information on the wiki is so wrong in many places that people stopped bothering to correct it
< NotAnNSAgent>
sipa: That's just swell.
< NotAnNSAgent>
I've been using it as a reference.
< NotAnNSAgent>
And no warnings anywhere.
< btcdrak>
sipa: thongs? o.0
< NotAnNSAgent>
Except a link to that weird documentation.
< NotAnNSAgent>
I find that link very messy.
< NotAnNSAgent>
And I'm not just saying that because I've been using the old one.
< sipa>
help improve it then :)
< NotAnNSAgent>
From what I can tell, the stuff I have works. But what you say about accounts being deprecated sounds insane to me.
< NotAnNSAgent>
It seems to be a core concept.
< NotAnNSAgent>
Having no "accounts" within a wallet would make it useless.
< NotAnNSAgent>
For anything but academic usage.
< NotAnNSAgent>
I really hope no syntax changes will be necessary.
< NotAnNSAgent>
Preserving backwards compatibility should be of utmost importance.
< sipa>
accounts are pretty much incompatible with backups, for example
< NotAnNSAgent>
?
< sipa>
as you can't reconstruct account information from the blockchain
< sipa>
if your wallet gets corrupted, you lose your accounting information, which for some businesses may be worse than losing money
< NotAnNSAgent>
Okay. Please listen: we, the users, do not like it when you, the developers, change stuff around. Even if it's stupid, we want a reliable API to use and not have to constantly change our code. We want solid, robust stuff that can be relied upon.
< sipa>
it's been deprecated for years
< NotAnNSAgent>
The wallet.dat still contains it, no?!
< NotAnNSAgent>
I really hope you're just joking or something.
< sipa>
not if your wallet.dat gets corrupted
< NotAnNSAgent>
That's why you have backups of wallet.dat?
< sipa>
are you making a backup after every transaction?
< NotAnNSAgent>
No, but often.
< sipa>
not enough, if you use accounts
< NotAnNSAgent>
"sendfrom <fromaccount> <tobitcoinaddress> <amount>" <-- Are you saying that at some point in the near future, I'll upgrade my bitcoind and this will cease to work?
< sipa>
yes
< NotAnNSAgent>
.........
< NotAnNSAgent>
And it's replaced by what exactly?
< sipa>
let me first ask you this
< sipa>
what do you think that RPC does?
< NotAnNSAgent>
Lets me talk to bitcoind.
< sipa>
so far so good
< belcher>
NotAnNSAgent do you have anything online that uses accounts?
< NotAnNSAgent>
belcher: No, but I thought I was ready literally minutes ago.
< NotAnNSAgent>
My test finished successfully, etc.
< NotAnNSAgent>
I just casually mentioned how much I liked accounts, and then I learn that it's deprecated!
< sipa>
NotAnNSAgent: say you have address A1 and address A2, A1 received a transaction paying it 1 BTC, A2 received a transaction paying it 2 BTC
< belcher>
well they are, since before i got interested in bitcoin
< sipa>
NotAnNSAgent: address A1 is associated with account L1, address A2 js associated with account L2
< sipa>
NotAnNSAgent: you do sendfrom L1 someaddress 1.5
< sipa>
what happens?
< NotAnNSAgent>
It fails because it doesn't have enough money? (Assuming they both had 0 initially)
< sipa>
wrong, it succeeds, and L1 goes to -0.5
< NotAnNSAgent>
o_O
< NotAnNSAgent>
Minus?
< NotAnNSAgent>
How is that possible?
< sipa>
because accounts do not do anything near what you think they do
< sipa>
you've read the documentation for a few minutes, and thought they were cool, made assumptions about what they do, and started using them with a few tests
< sipa>
and they are useful, for a few very narrow cases
< sipa>
but almost everybody misunderstands them
< NotAnNSAgent>
Seems like accounts were improperly designed to me. :/
< NotAnNSAgent>
If you can get negative amounts.
< sipa>
and recently we had a problem among developers where we were not even sure what a particular getbalance call was supposed to do wrt accounts
< NotAnNSAgent>
So L1 steals 0.5 BTC from the other accounts in the wallet?
< sturles>
Negative amounts is a feature, if you ask me.
< gmaxwell>
NotAnNSAgent: No, accounts are not wallets. They're accounting records.
< sipa>
NotAnNSAgent: you're making assumptions
< sipa>
NotAnNSAgent: an account just keeps track of how much (in BTC) in a wallet belongs to a particular user
< gmaxwell>
user/use
< sipa>
it does not have anything to do with which transactions or coins
< NotAnNSAgent>
If, in the example, you send more BTC than what exists in the "account" inside the wallet.dat (which contains the two accounts L1 and L2), I certainly hope that that money is taken from some place, or else anyone could generate free Bitcoins.
< sipa>
the coins in your wallet are shared across all accounts
< NotAnNSAgent>
Alright, so I have to redo everything. And I don't even know how.
< NotAnNSAgent>
No accounts...
< sipa>
at least i hope you now understand why they are deprecated: evrryone misunderstands them
< Arnavion>
You'd think the nomenclature of having multiple accounts within the same wallet would give a hint that they don't mean what you'd expect
< NotAnNSAgent>
Apparently. I sure did.
< sipa>
in fact, we recently came across some weird behaviour in tje getbalance call, and nobody including developers were even sure what the correct behaviour would be
< sipa>
yes, there is talk about having just multiple wallet simultaneously
< gmaxwell>
I think you're conflating multiple things; regardless of it being consider depricated; it's still there right now and still works as it always has.
< sipa>
NotAnNSAgent: i can tell you that the transition to no accounts anymore will not hapoen instantly, as there are indeed people who rely on them, and use them the way they were intended to be used
< gmaxwell>
It still continues to do what it's described to do; which is not what a lot of people initially think it does. (and often what they think it does isn't actually possible; or is equivilent to multiple wallets, with the overheads that involves)
< sipa>
but it's good to know that we should probably ask the bitcoin.org people to mark those RPCs as deprecated on the site
< gmaxwell>
Just axing out accounts would really screw up my tax reporting; unless they were at least replaced with labels.
< sipa>
only account balances will go away, you'll still be able to list transactions by label
< sturles>
I use accounts to kepp track of incoming BTC from users. BTC sold to me via my autobuy service. When the money has been transfered, I move the BTC to a different account. This is an extra safety for me, to make sure I have paid for every BTC I use or sell to other people, and in case I lose other records. I started to use accounts when I missed one payout due to a glitch in my walletnotify
< sturles>
script, and never missed a payout since. If account balances are lost, this failsafe would be gone. :-(
< gmaxwell>
sturles: the lack of good durability options for bitcoin wallets probably makes that workflow suboptimal. You probably want to have something that lets you send a transaction atomically with making a backup.
< gmaxwell>
I guess we kind of have that possiblity now with walletbroadcast off... e.g. you'd make all your transactions but don't broadcast yet, backup with wallet. Then broadcast.
< sturles>
Would be perfect, but my transaction volume is low enough that I can live with somewhat suboptimal.
< sturles>
I could transfer funds to a different address when paid for, but that would cost transaction fees and block space.
< NotAnNSAgent>
Why was the decision made to make "accounts" behave in this odd, unintuitive manner?
< * sturles>
doesn't think it is unintuitive..
< gmaxwell>
NotAnNSAgent: it's very sensible for the purpose they were created for. They're an overlay accounting system.
< NotAnNSAgent>
But the syntax is literally: "sendfrom <fromaccount> <tobitcoinaddress> <amount>", even in the current documentation.
< gmaxwell>
They let you tag incoming payments as payments to accounts, outgoing payments as payments from accounts, and let you enter correcting ledger entries.
< gmaxwell>
There isn't really any "from" in the design of the bitcoin protocol in any case-- that people often think there is an artifact of the forensic analysis done by block explorers and the presentation of that analysis as 'transactions' in a way that doesn't actually reflect the operation of the bitcoin system.
< gmaxwell>
I think this is why the rate of misunderstanding accounts increased over time, people were expecting there to be "from" in transactions.
< gmaxwell>
and then it looks like the API is setting it.
< NotAnNSAgent>
Somebody said it's been in "deprecated" state for years already.
< NotAnNSAgent>
And soon will be removed.
< NotAnNSAgent>
But the up-to-date manual doesn't even mention this fact.
< sipa>
Please stop saying official. There is no such thing.
< sipa>
Nobody said they will be removed soo
< sipa>
They have indeed been deprecated for a long time.
< NotAnNSAgent>
Alright, so if they are, then what do I do in place of "accounts"? And is this outlined nowhere?
< NotAnNSAgent>
Somebody mentioned "labels", but they already exist as "labels" for transactions.
< NotAnNSAgent>
And seem to be local only.
< gmaxwell>
everything is local only.
< sipa>
accounts are also local only
< NotAnNSAgent>
Good point.
< gmaxwell>
At no point have you mentioned what you're trying to accomplish, so no one can answer "what do I do in place".
< NotAnNSAgent>
But labels aren't exactly... um... the labels I'm thinking of are like "Payment for the bicycle from Joe". Not "someservice".
< NotAnNSAgent>
gmaxwell: I'm trying to have one wallet.dat/bitcoind, but deal with multiple "accounts" of money.
< NotAnNSAgent>
Namely for two separate services I run.
< sipa>
so you want multiple wallets, really
< NotAnNSAgent>
They must never share money.
< sipa>
i mean: you want something to behave as if they acted as two separate wallets
< NotAnNSAgent>
That's why I thought "accounts" existed.
< sipa>
bitcoind does not support this; there are other wallets out there that do
< NotAnNSAgent>
Now you're just being ridiculous. Are you saying that every Bitcoin business in the world uses third-party clients because the official one only allows one single wallet?
< sipa>
bitcoind does many things, and a wallet is only one of them
< gmaxwell>
"they must never share money." < Thats multiple wallets that you want. You can run multiple bitcoinds, with pruning each will use a couple gigs of disk space.
< sipa>
its wallet implementation is a reference one, certainly not the most advanced nor the one most development work goes towards
< NotAnNSAgent>
You know, I was really proud an hour ago or so when I had finally finished (I thought) this complex system...
< gmaxwell>
NotAnNSAgent: multiple wallets is very simple... run multiple wallets, connect to the correct one. Done. :)
< NotAnNSAgent>
Why would it require multiple blockchains?
< gmaxwell>
It doesn't, not with pruning.
< NotAnNSAgent>
Pruning is a whole problem in itself.
< gmaxwell>
uh. What?
< NotAnNSAgent>
I'm stuck with 0.11.x and only 0.12.x does it. This is why I went out of my way to make a separate computer to just run Bitcoind.
< gmaxwell>
How are you 'stuck with 0.11.x'?
< NotAnNSAgent>
Because 0.12.x doesn't exist on FreeBSD.
< sipa>
i'm sure you can run a compiler if you use FreeBSD
< gmaxwell>
Sure it does. Do you mean ports hasn't updated to it?
< NotAnNSAgent>
But even if it did, I wouldn't wanna run multiple different instances of bitcoind. That simply cannot be necessary. I refuse to believe that.
< sipa>
it is not necessary
< NotAnNSAgent>
There is no pkg except for 0.11.x, yes.
< sipa>
and it's silly that you can't have two wallets in one bitcoind, i fully agree
< sipa>
bit someone has to do the work to make that happen, someone has to test it, has to review it, has to maintain it
< sipa>
few people have showed up before to do that when there was talk of having multiple wallets
< gmaxwell>
I agree that it's a silly limitation, otoh, it's trivial to work around-- in a very safe and reliable way--, which is part of why no one has stepped up to fix that.
< gmaxwell>
(as running multiple bitcoinds, especially with pruning, is a trival cost-- much cheaper than opening multiple bank accounts. :) )
< NotAnNSAgent>
Trivial to work around? I'd have to run separate blockchains (ridiculous), not to mention it's a nightmare already to attempt to "restart" (kill and relaunch command) my one bitcoind...
< gmaxwell>
And having multiple wallets in one bitcoind is more complex than you might guess at a glance; for example, you don't want to allow any privacy cross linking of them.
< NotAnNSAgent>
And there is no pruning for me as mentioned.
< gmaxwell>
NotAnNSAgent: you're running outdated software which is several releases behind, lacking the latest security and performance fixes...
< NotAnNSAgent>
Tell that to the maintainer who doesn't respond to e-mails and doesn't take his job seriously.
< sipa>
are you paying him.
< sipa>
?
< sipa>
no? then don't complain about the work of volunteers
< NotAnNSAgent>
Crazy concept: doing something for other reasons than getting paid.
< gmaxwell>
I can try pinging too. But this might be an argument against using freebsd if you're going to depend on packages that don't get updated.
< gmaxwell>
NotAnNSAgent: sure, it would be nice but you can only ask for so much.
< NotAnNSAgent>
I'm told to not use FreeBSD every time I mention a problem I'm having. If it were easy, I would switch.
< sipa>
NotAnNSAgent: for the longest time i was not paid to work on bitcoin, and i still spent weekends and evenings on it. please don't say that money is the only reason to do things
< NotAnNSAgent>
You used it as an argument, though.
< sipa>
NotAnNSAgent: but you don't complain about the work of volunteers
< gmaxwell>
NotAnNSAgent: well I'm not telling you to switch, just pointing out that its a consideration that has to be taken in totality.
< NotAnNSAgent>
And of course nobody is saying that this is easy. I'd never say that.
< NotAnNSAgent>
My experiences especially these last few weeks have really convinced me that Bitcoin has a looooong way to go before it can be implemented by anyone other than hardcore experts.
< NotAnNSAgent>
I shouldn't say "implemented".
< NotAnNSAgent>
More like "deployed".
< gmaxwell>
In any case, 0.12.1 should build cleanly on freebsd without any modifications. If it doesn't we'd love to know about it and fix them for the next release.
< NotAnNSAgent>
gmaxwell: I actually tried to build it on my FreeBSD box. It failed with some requirement of a db4.h or something along those lines.
< sipa>
NotAnNSAgent: use --with-incompatible-bdb
< NotAnNSAgent>
I already had db4-something as an installed package, but that wasn't good enough because it doesn't contain the source code.
< sipa>
ah, yes, you'll need development headers
< NotAnNSAgent>
Incompatible BDB :S
< gmaxwell>
NotAnNSAgent: not that I'd disagree, but you've given yourself some disadavantages: you're using a less common and less well maintained platform, and you're trying to put two totally seperate uses on a single system, for example. These are things that _should_ still work well, I agree. But your expirence may not be typical. :)
< NotAnNSAgent>
Even if I wanted to switch right now, I couldn't pick one of the numerous Linux distros. That would simply be impossible for me. And of course I'd have to recode every single script and learn how everything is done in that OS... to me, that is like going through a heart transplant.
< sipa>
NotAnNSAgent: i must say that i'm somewhat surprised to see someone comment about using bitcoin on both Win10 and FreeBSD :)
< NotAnNSAgent>
At some point, I tried to "give up and just use Bitpay or Coinbase", but both of those require you to send them "proof of business" and a bunch of nonsense like that (which they reveal only after registering, of course).
< sipa>
NotAnNSAgent: not meant in a bad way, just curious
< NotAnNSAgent>
What's so surprising? I don't know if I've mentioned Windows 10, but yes, I run that on the desktop.
< sipa>
18:12:28 < NotAnNSAgent> Since Windows 10, the Bitcoin Core client for Windows uses the awful Windows 10 notifications, which I've been forced to turn off globally.
< NotAnNSAgent>
Ah. Yes.
< NotAnNSAgent>
When I picked FreeBSD, the year was 2000 or something.
< sipa>
Ha, that's when I last used Windows (ME!), and switched to Debian :)
< sipa>
NotAnNSAgent: btw, can you file an issue for those notifications?
< NotAnNSAgent>
I'm often told to "file a bug" or "file a PR" etc. for various open source projects. When I try, I never receive a verification e-mail and then I forget about it. I've come to consider such tasks to be real chores that are far worse than carrying heavy objects around in real life.
< sipa>
I can do it for you, but I don't even have any idea what notifications you're talking about
< sipa>
I do understand the burden of registering on github, but the best thing you can do right now to get the problem fixed eventually, is to provide as much information about it on a report.
< NotAnNSAgent>
The notifications thing really is a non-issue in comparison to this.
< sipa>
Doesn't mean it can't get attention, probably by very different people.
< NotAnNSAgent>
Essentially, I hate the Windows 10 notifications but loved the old, pre-Windows 10 balloon tips.
< NotAnNSAgent>
The Win10 ones are flooding me with useless notifications such as "all transfers finished" in FileZilla, making them useless.
< NotAnNSAgent>
Or "Get Office 360 for cheap!"
< NotAnNSAgent>
But the old balloon tips nicely stayed there until I saw them.
< NotAnNSAgent>
And no junk ones.
< NotAnNSAgent>
There is supposedly a way to turn off notifications for all but your chosen "apps", but it doesn't actually seem to work.
< NotAnNSAgent>
What disturbs me the most about all of this is probably that even the current documentation doesn't reflect this MAJOR (IMO) change.
< NotAnNSAgent>
Do you developers have some internal documentation that you use?
< belcher>
i think i found out accounts were deprecated from the bitcoin wiki or something
< NotAnNSAgent>
It's acting as if accounts are alive and well.
< belcher>
whoops wrong channel
< belcher>
if you run 'help getaccount' on json-rpc (or anything accounts related i guess) it tells you they're deprecated
< molz>
belcher, on the wallet qt, if you type in the console "help getaccount", it tells you "DEPRECATED. Returns the account associated with the given address." so i don't think anyone can miss it