luke-jr: also thx, appreciate the feedbacks :)
Hi, just a question: What about bit rot on the blockchain? This might not yet be an issue, but there might be a good idea to implement some sort of error checking algorithm which consolidates historical blocks by p2p?
okay, thinking further I guess this already happens by downloading a fresh copy of the blockchain. And there are checksums, too.
MarcoFalke: If you've got a moment, please also see PR #12501 -- after last week's meeting it seems that this should be okay to go, but if you think it needs more peer-review that's fine too.
[bitcoin] laanwj closed pull request #10922: New file-partition.md doc describing how to partition files to ensure fast initial blockchain synchronization.. (master...master) https://github.com/bitcoin/bitcoin/pull/10922
gmaxwell: quick question: do you remember around what time the (txt) document on confidential transaction was published? (the confidential_values.txt)
stevenroose: may 2015 iirc
Phew, that's been some time
It seems like we're getting closer though :)
There's some sort of bug related to accounts (which I know you intend to deprecate at some point, but still exist). Bitcointalk.org uses the used-to-be-standard accounts pattern of 'getaccountaddress <account>' & 'getbalance <account>'. Upon upgrading from 0.14.2 to 0.16.0, addresses are being given out by getaccountaddress, but at some point they no longer become associated with the account.
I haven't tracked down exactly where the account designation gets lost. I'm just going to take this opportunity to get rid of accounts usage. Though I suppose that other people will run into this problem, since it was the standard pattern some years ago.
theymos: can you open an issue on github about that?
Hmm. I kind of liked accounts. Where is the archive discussion about this?
ProfMac, look in the logs of this channel
theymos: getaccountaddress wasn't the standard pattern ever AFAIK; that's going to result in address reuse..
should be getnewaddress <account>
getaccountaddress generates a new address for the account when the old one receives a payment
yes, which it might not have yet
liable to give the same address to two people using the website at the same time, and then get paid by both to the same
accounts have always been broken, in some way or other. :(
luke-jr: that wouldn't happen if each person is a different account.
giving one person the same address multiple times until you've seen a payment on the old one isn't _that_ bad.
The ideal is probably invoice-based accounting, but that's a huge change from balances-based accounting. So currently bitcointalk.org is just reusing addresses 100%, since getaccountaddress is broken and I don't have time to implement the address-changing thing right now...
By happenstance, I have 0.8.1 -qt open. When I go to "receive coins" --> "new address" and drop in an existing label, it returns a new address. This occured when only 1 address existed and had received funds, and also when there were multiple addresses, several of which had never received funds.