< NotAnNSAgent>
I have to have two separate 75 GB blockchains and separate bitcoind daemons running just to have two accounts.
< NotAnNSAgent>
Yes, I know what you said about pruning, but remember the circumstances.
< NotAnNSAgent>
Out of curiosity, what was the thinking with the "accounts" that exist and are being killed off now?
< NotAnNSAgent>
To me, it just seems bizarre that if you have not enough money in an "account", it will take money from other "accounts".
< NotAnNSAgent>
Unless you assume that the wallet is literally a wallet and the "accounts" are like... separate credit cards inside the physical wallet.
< NotAnNSAgent>
So I would've liked it better if the initial metaphor wasn't "wallet" and "wallet.dat", but instead "virtual Bitcoin bank" and "bank.dat".
< NotAnNSAgent>
Then, "accounts" would make far more sense.
< NotAnNSAgent>
But the "wallet" idea is also an attractive thing to advertise. Though I think the "wallets" could rather be Bitcoin's own term for an "account", all inside a "Bitcoin bank" (bank.dat).
< NotAnNSAgent>
Do you understand what I mean?
< phantomcircuit>
NotAnNSAgent, what are you trying to accomplish? (the accounts stuff is almost certainly the wrong way to do it, no matter what it is)
< NotAnNSAgent>
phantomcircuit: I don't know if you have followed the conversation, but I know that the accounts are deprecated since a long time.
< NotAnNSAgent>
phantomcircuit: I'm trying to discuss the concept of "accounts" in Bitcoin and why they were made the way they were.
< NotAnNSAgent>
And why Bitcoin forces me to have separate instances and separate blockchains for each "account" I want to have (each "wallet" in your terms).
< phantomcircuit>
NotAnNSAgent, the "accounts" functionality is an attempt to bring standard accounting practices to the reference wallet
< phantomcircuit>
it falls well short of accomplishing this
< NotAnNSAgent>
phantomcircuit: It's standard accounting practice to take money from other accounts if the account that's transferring money doesn't have enough?
< phantomcircuit>
NotAnNSAgent, the "accounts" stuff is completely separate from handling of bitcoin transactions
< phantomcircuit>
except that when you receive a payment it will correctly generate the accounting entry for that
< NotAnNSAgent>
...
< phantomcircuit>
yes i agree it's not ideal and definitely confusing
< NotAnNSAgent>
Why didn't Bitcoin support multiple "wallets" right away? I have no idea what you mean that "accounts" are supposed to be, still.
< phantomcircuit>
it's much less confusing if you just ignore the accounts stuff
< NotAnNSAgent>
I have to ignore the accounts stuff, because I learned it's practically removed from the Bitcoin software.
< NotAnNSAgent>
(Without the manual being updated to reflect this)
< phantomcircuit>
NotAnNSAgent, in bitcoin terms a "wallet" is just a collection of private keys and the transactions related to those keys in the blockchain
< NotAnNSAgent>
Why is it so hard for Bitcoin to simply support multiple wallets? Why do I have to run entire separate blockchains and instances of the daemon for this?
< phantomcircuit>
NotAnNSAgent, it's in the documentation that the accounts are deprecated
< phantomcircuit>
NotAnNSAgent, why do you want multiple wallets?
< NotAnNSAgent>
phantomcircuit: To be able to support Bitcoin donations to one of my services, and to deal with another Bitcoin account for my commercial site.
< NotAnNSAgent>
If I don't have any ability to set the "account" for a given txid, I can't know which "account" it's supposed to be connected with.
< NotAnNSAgent>
Also, when I want to send out money back to my own desktop wallet, I can't select which "account" to send it from.
< phantomcircuit>
oh we're in the wrong channel for this conversation
< luke-jr>
[00:25:28] <NotAnNSAgent> To me, it just seems bizarre that if you have not enough money in an "account", it will take money from other "accounts". <-- it wouldn't.
< NotAnNSAgent>
I can't join that channel.
< NotAnNSAgent>
luke-jr: I thought that was the point of the example one of you showed me earlier.
< luke-jr>
phantomcircuit: the bitcoind concept of accounts is pretty ideal, even if poorly implemented
< phantomcircuit>
NotAnNSAgent, the correct way to do this is to map the receiving address to what it's paying for and then account for that separately
< luke-jr>
phantomcircuit: that's what accounts did :P
< phantomcircuit>
luke-jr, yeah... but poorly
< NotAnNSAgent>
phantomcircuit: My bitcoind is on a different server from my main server. Every hour, it generates 50 receive addresses with the account "X" and the same number for the account "Y". Then it sends those via HTTPS and JSON to my main server. The main server stores them in a database (separate DBs) and shows a unique one for each person who requests to pay.
< NotAnNSAgent>
Then, when a payment is made to one of those receive addresses, my script checks all the unchecked txids.
< NotAnNSAgent>
And then checks what their "account" is to decide what to do.
< luke-jr>
so you just need to skip the account stuff
< NotAnNSAgent>
?
< luke-jr>
keep track of that in your main server
< phantomcircuit>
NotAnNSAgent, in the database on your main server you're already associating an address with the invoice, correct?
< phantomcircuit>
then you already have all the information you need to do this without the accounts stuff
< NotAnNSAgent>
No... I just store them in a very simple table and pick one to show the user (and then deletes it).
< phantomcircuit>
oh
< phantomcircuit>
dont do that
< phantomcircuit>
associate the address with an invoice
< phantomcircuit>
then check for payments by calling "listtransactions" and looking at the address field
< NotAnNSAgent>
The bitcoind is on a separate server, as mentioned. It has no such database in it.
< luke-jr>
…
< luke-jr>
if you don't know which invoice is paid, what happens when someone doesn't pay?
< NotAnNSAgent>
It doesn't know what to do with the txid.
< NotAnNSAgent>
There are two machines: bitcoind and www. bitcoind is made hourly to generate 50 receive addresses for account X and 50 for account Y. When it's done, it sends those addresses to www which stores it in two databases. A user of one of the services requests to pay, and thus gets one of the prepared receive addresses. When they send money to them, bitcoind will soon react by running the walletnotify script (which I also run every hour as a
< NotAnNSAgent>
cronjob) which then lists all the recent transactions and checks if they have been processed (by comparing them to entries in a simple text file called processed_txids), and if they haven't, they get an action done to the right service by checking which "account" the txid has.
< NotAnNSAgent>
If I can't have accounts, there is no longer any "label".
< NotAnNSAgent>
So the walletnotify/hourly script has no way to know what to do with the txid.
< NotAnNSAgent>
Unless there is indeed a "label" I can use instead? Like the labels in the graphical client.
< NotAnNSAgent>
But in that case, why also have "accounts"?
< luke-jr>
accounts tracked a balance
< luke-jr>
labels *should* be usable in bitcoind, but not fully yet IIRC
< luke-jr>
but for receiving, it should work
< phantomcircuit>
luke-jr, i wouldn't use labels either just because it's essentially impossible to do backups in a sane way
< phantomcircuit>
NotAnNSAgent, do you already generate invoices on the www server?
< NotAnNSAgent>
phantomcircuit: I have no concept of invoices.
< NotAnNSAgent>
But that's a detail that can be fleshed out later.
< phantomcircuit>
NotAnNSAgent, then how do you expect to keep track of what a payment was for?
< NotAnNSAgent>
I can store user id, amount, txid.
< NotAnNSAgent>
It's simply not relevant to this problem.
< NotAnNSAgent>
Can I set an arbitrary property of my own?
< NotAnNSAgent>
Some sort of label/data?
< NotAnNSAgent>
This is insane. I can't believe I'm having to ask about this on IRC instead of it just being spelled out clearly on the site.
< NotAnNSAgent>
And I was looking at ancient documentation for the duration of my implementation up until today.
< luke-jr>
NotAnNSAgent: as I said, you can set labels for receiving. the backup issue will apply no matter what you do
< luke-jr>
NotAnNSAgent: and, invoices are relevant, since two orders may have the same amount
< luke-jr>
and Bitcoin has no concept of users
< NotAnNSAgent>
I still don't get what you are talking about in terms of backups.
< NotAnNSAgent>
luke-jr: You're all acting as if I had asked you to bake in a full-length movie into each block in the blockchain or something, but all I'm asking for is a way to label my receive addresses in the bitcoind so it stands any chance of knowing which "account" it belongs to.
< NotAnNSAgent>
Why isn't that in every example and the first thing you see?
< NotAnNSAgent>
And how do I actually set and get it?
< luke-jr>
NotAnNSAgent: we're saying you need to label each address individually to know what purchase it's used for
< NotAnNSAgent>
..............
< luke-jr>
that's how bitcoin works
< NotAnNSAgent>
This has NOTHING to do with the product bought.
< NotAnNSAgent>
I'm talking about the BITCOIND.
< NotAnNSAgent>
Not the WWW server.
< luke-jr>
you don't need it in more than one place
< NotAnNSAgent>
...
< NotAnNSAgent>
I give up. You won't read anything I type, so it's meaningless to attempt to ask this basic question.
< midnightmagic>
This isn't really the place to ask user questions about bitcoind dude.
< midnightmagic>
It would be like going into the engineering department of a commercial software house and asking support questions.
< gmaxwell>
NotAnNSAgent: I think you need an attutide adjustment. You came here seeking free tech support, and -- people are happy to provide it-- but at every turn you've treated the folks here with disrespect. This isn't acceptable. Please cut it out.
< midnightmagic>
.. by grabbing the ear of literally the first engineer who's sitting there staring at a wall of text, that you see.
< gmaxwell>
NotAnNSAgent: if all you want to do is attach labels to addresses, you can do that, via the accounts mechenism. As people mentioned the labeling isn't durable across backups; which might or might not be an issue for you. Earlier you weren't looking for labels, you were looking for seperate wallet functionality (which accounts do not provide). If you want to use accounts as labels, you may, but y
< gmaxwell>
ou'll have to take some time to understand the behavior lest you confuse yourself with get balance calls.
< gmaxwell>
NotAnNSAgent: if you're going to be generating hundreds of addresses per hour, you'll want to increase the keybpool size so that you're not invalidting your backups and risking key loss. The comments above were recommending that you record which user which address belongs to in your front end. This is important for data durability. If you're doing that, you probably do not also need to do the s
< gmaxwell>
ame in bitcoind, though you can if you want.
< midnightmagic>
+1 external address-to-user matching via listunspent queries or equivalent.
< NotAnNSAgent>
This just keeps on getting more and more complicated.
< NotAnNSAgent>
Also, Bitcoin Core is bitcoind, no?
< NotAnNSAgent>
(Except it also has a GUI client)
< belcher>
the gui client is generally called bitcoin-qt, bitcoin core is the project that includes both of those
< NotAnNSAgent>
I really don't know what to do.
< NotAnNSAgent>
It feels as if I'm desperately trying to help get some enthusiasm going for Bitcoin as a project, but everyone seems to have sort of given up mentally.
< luke-jr>
midnightmagic: listtransactions or listreceived :x
< luke-jr>
midnightmagic: listunspent is wallet internals; not something normal users should need ever
< luke-jr>
NotAnNSAgent: you can expect many people will "give up" helping when you ignore the advice you're given.
< NotAnNSAgent>
You are the one who ignored what I said, but sure.
< phantomcircuit>
NotAnNSAgent, i already told you
< NotAnNSAgent>
You make about as much sense as the Bitcoin API.
< phantomcircuit>
you want to assign an address to an invoice
< phantomcircuit>
that's it
< phantomcircuit>
horray
< midnightmagic>
you think so?
< phantomcircuit>
im thinking we shouldn't have "assert" in serialization code
< phantomcircuit>
only for maintaining invariants of things in memory
< cryptocoder>
luke-jr, phantomcircuit: saw your comments earlier about using “listtransactions” instead of “listunspent”. wouldn’t the latter make more sense?
< luke-jr>
cryptocoder: no, listunspent makes no sense in that context since it deals with UTXOs and not addresses
< cryptocoder>
I see. I just wasn’t sure if that’s was your view in general or simply in the context of notannsagent’s use case
< luke-jr>
ah
< luke-jr>
yeah, right tool for the right job kind of thing
< luke-jr>
listunspent makes some sense for some sending use cases; I can't think of any time it'd be useful for receiving
< cryptocoder>
wouldn’t they function similarly enough though? unless you’re saying that by taking adv of the from+count you get a simpler result set to check against?
< luke-jr>
cryptocoder: not really, no
< luke-jr>
listunspent lists UTXOs, which are unrelated to receiving
< cryptocoder>
oh, I see your point. I get what you mean
< phantomcircuit>
i was going to ask why CDataStream takes a signed integer and then asserts that it's >=0
< midnightmagic>
listunspent output requires the least amount of work on my part to build a tx programmatically.
< midnightmagic>
if someone wants to try to involve me in a multisig without my knowledge, they're gonna be waiting a long time for any participation from me.
< luke-jr>
midnightmagic: building a tx = sending :p
< luke-jr>
midnightmagic: also, have you seen fundrawtransaction?
< midnightmagic>
hrm
< midnightmagic>
I think someone pointed me at that before. manual selection of inputs is definitely annoying. :)
< midnightmagic>
ooo look at that it does the change output thing automatically
< luke-jr>
midnightmagic: the GUI for manual input selection is fairly nice too FWIW :P
< midnightmagic>
<3
< luke-jr>
but no way to do complex use cases (multisig, etc) with it
< luke-jr>
versionbits.cpp:11:9: error: expected primary-expression before ‘.’ token
< luke-jr>
why is Travis whining at that PR? :/
< * luke-jr>
wonders if he is accidentally C++11ing
< paveljanik>
looks so ;-)
< luke-jr>
annoying C++ :P
< midnightmagic>
:)
< GitHub136>
[bitcoin] pstratem opened pull request #7936: CDataStream::ignore Throw exception instead of assert on negative nSize. (master...2016-04-24-cdatastream-ignore) https://github.com/bitcoin/bitcoin/pull/7936
< phantomcircuit>
luke-jr, -Wall -pedantic will tell you if you're using c++11 isms
< phantomcircuit>
(sometimes)
< phantomcircuit>
it'll also complain about lots of random irrelevant stuff
< gmaxwell>
libsecp256k1 builds completely clean with -Wall -Wextra -std=c89 -pedantic (plus a few more warning flags that aren't turned on by extra). (well, excepting the -Wno-long-long is used so it doesn't whine about use of long long, -Wno-unused-function because pieter didn't like me peppering the code with ifdefs to kill the last unused functions in some builds, and -Wno-overlength-strings to work aro
< gmaxwell>
und a clang bug)
< wumpus>
speaking of c++11, it's Monday, any news from Travis cfields?
< wumpus>
sorry for the impatience <:
< phantomcircuit>
gmaxwell, afl-cmin -C isn't finding any crashes but afl-fuzz reports them in the curses ui
< phantomcircuit>
thoughts?
< sipa>
wumpus: at least wait until the business day is over :)
< sipa>
wumpus: seems travis is baser on germany, so we don't need to wait another 9 hours
< GitHub121>
bitcoin/master 74f7b12 Wladimir J. van der Laan: dbwrapper: Remove throw keywords in function signatures...
< GitHub121>
bitcoin/master 878bf48 Wladimir J. van der Laan: dbwrapper: Remove CDBWrapper::GetObfuscateKeyHex...
< GitHub121>
bitcoin/master b69836d Wladimir J. van der Laan: dbwrapper: Pass parent CDBWrapper into CDBBatch and CDBIterator...
< GitHub160>
[bitcoin] laanwj closed pull request #7927: Minor changes to dbwrapper to simplify support for other databases (master...2016_04_dbwrapper_modernization) https://github.com/bitcoin/bitcoin/pull/7927
< NotAnNSAgent>
This is obviously going to offend you, but I have to ask... Is the not only poor, but grossly *misleading* documentation deliberately so? I mean, maybe you don't want Bitcoin to be easy to implement to ensure job security or something? I've seriously begun asking myself if that could be the case. Again, though, I understand that this is both very difficult stuff, and you can't change things directly as individuals without first talking
< NotAnNSAgent>
to a bunch of people, but still. The documentation just seems... nonexistent in practice?
< NotAnNSAgent>
(It's worth adding that I feel the same thing about Let's Encrypt and many other projects.)
< NotAnNSAgent>
I eventually figured out how to use LE, though.
< wumpus>
note that no one is being paid to write documentation, so if you want to spend time contributing on improving the documenttion you're very welcome
< wumpus>
if not I suggest you leave, this is an open source project, there is no customer support and complaining won't get you anywhere
< assder>
wumpus: Is there a big difference in the architecture of Core between 0.11 and 0.12, such that one should wait until that gets updated to start studying it?
< wumpus>
assder: no, it's still the same on a high level
< wumpus>
the P2P code and initialization didn't change much since then
< wumpus>
the RPC server changed quite a lot from 0.11 to master (e.g. switching from boost::asio to libevent, amongst other things) but I see that page isn't even there
< NotAnNSAgent>
wumpus: I'm talking about the API to talk to bitcoind. Which seems to be explained (messily) at https://bitcoin.org/en/developer-reference#bitcoin-core-apis , but that documentation is full of dangerously outdated information.
< NotAnNSAgent>
And has "not been reviewed by Bitcoin developers", which makes no sense to me.
< instagibbs>
NotAnNSAgent, bitcoin-cli help ?
< wumpus>
NotAnNSAgent: the best documentation for the API is in bitcoind itself, using bitcoin-cli help
< wumpus>
right, as instagibbs says
< NotAnNSAgent>
That is the same as sending "help" as an RPC call, right?
< NotAnNSAgent>
(I don't have bitcoin-cli binary)
< wumpus>
yes, help with an optional method name
< * NotAnNSAgent>
fires up his shutdown server and tries that
< wumpus>
how do you manage to not get the bitcoin-cli binary?
< da2ce7_mobile>
hello, I wish to copy the blocks from one PC to another, what is the minimum I need to copy? It If I just copy the blk0xxx files it overwrites the files. If I include the rev00xxx files bitcoin throws an assertion. I suppose it has something to do with the chainstate obfuscation.
< da2ce7_mobile>
I'm using Bitcoin 0.12.1
< wumpus>
you want to copy just the block data or also the databases?
< wumpus>
the minimum is copying just blk*.dat then running -reindex
< wumpus>
the other option is to copy blocks/ and chainstate/ entirely
< sipa>
or either of them separately, as long as the result is a chainstate/ that is not ahead of blocks/
< wumpus>
which will be faster as you don't need a reindex. Be sure to do that while bitcoind is not running.
< da2ce7_mobile>
ahh. so it won't automatically detect without -reindex.
< da2ce7_mobile>
ok.
< sipa>
it will
< sipa>
you can copy the blocks, and delete the chainstate
< sipa>
in which case it will rebuild it
< sipa>
(though due to a bug, that's currently much slower than just reindexing)
< da2ce7_mobile>
I will try again, I was seeing a different result.
< wumpus>
don't include the revXXXX files if you don't copy the chainstate though, they're undo files for the chainstate and have no use without it
< da2ce7_mobile>
Ok, I have just the blkXXX files, and a wallet.dat file. Will load bitcoin.
< wumpus>
(although I don't understand why you'd get an assertion error, they should just be ignored on reindex)
< sipa>
best is to start with -reindex in that case
< sipa>
it will only work without -reindex if you also have blocks/index/ already
< da2ce7_mobile>
ahh ok.
< da2ce7_mobile>
that explains the result.
< sipa>
blocks/ > blocks/index/ > chainstate/
< sipa>
(> meaning 'must be ahead of')
< sipa>
i guess >= is a better symbol
< wumpus>
right
< da2ce7_mobile>
ok. I get the expected result now "reindexing blocks on disk"; thank! :)
< NotAnNSAgent>
Okay, so at least the "help blabla" stuff mentions "DEPRECATED" in the output, but it still lists <account> and all that.
< NotAnNSAgent>
wumpus: I manage to not get the bitcoin-cli binary because I only installed bitcoin-daemon because why would I want the -cli thing?
< NotAnNSAgent>
I searched the online manual for "label", but found no way to set/get this. How is it set/get?
< wumpus>
you still have to use the account API for that right now
< NotAnNSAgent>
That is, any label I need for my own reference to know which "account" (not the deprecated Bitcoin concept of "accounts") it belongs to.
< wumpus>
this is the label API that will replace it: https://github.com/bitcoin/bitcoin/pull/7729 ... note that this is mostly just a subset of the account functionality, the only thing that will disappear is the account balance
< NotAnNSAgent>
wumpus: Are you saying that the "account" concept is deprecated and about to be removed, and the "label" concept is so new it's not implemented properly?
< wumpus>
that's why it's deprecated, not removed
< NotAnNSAgent>
So I have to use "account" for now, then closely follow the project and change my code when the service is actually in production to reflect the "label" concept?
< wumpus>
feel free to help testing the label API pull request
< wumpus>
in general there is very little interest in that part of the code, so any help is welcome
< NotAnNSAgent>
Why not just keep the account concept, then?
< wumpus>
because it is broken in multiple ways
< NotAnNSAgent>
There is very little interest in making it possible to have any idea who owns a given address in a "Bitcoin bank" (wallet)?
< wumpus>
no, using accounts to group addresses is fine, but the account balance functionality (as well as the 'move' call) will be removed
< NotAnNSAgent>
Confusing part: "Users are used to seemingly-odd practices of transferring imaginary money from a dummy account, to eliminate a negative number in some cases."
< NotAnNSAgent>
Hmm.
< NotAnNSAgent>
wumpus: Where were you yesterday? :O)
< wumpus>
I expect the account calls, even after adding the label API and remvoing account balances, will be kept as aliases for the *label* RPCs for backwards compatiblity for some time
< wumpus>
on sunday?
< NotAnNSAgent>
wumpus: When you say it's "fine" to use accounts to "group" addresses, are you saying that it will be easy for me to just change some string later when the accounts are removed, or that the syntax will be kept (but not documented/encouraged) in the future, allowing me to keep running it like that?
< wumpus>
well, doing other stuff at least :p
< wumpus>
NotAnNSAgent: probably.
< * NotAnNSAgent>
is slightly less pissed off now.
< NotAnNSAgent>
Quite a bit, actually.
< wumpus>
NotAnNSAgent: there are no guarantees for anything in the future, especially not regarding thewallet, and for every *major* release you should read the release notes carefully
< NotAnNSAgent>
Yes, but how many people actually do that? It's like reading EULAs.
< wumpus>
bitcoin core is not something you should upgrade without paying attention, especially if you use it in production and there's actual money involved
< sipa>
NotAnNSAgent: if you're running your bank using, i think it may make sense to actually do it
< NotAnNSAgent>
I didn't even read the entire PHP 7 announcement, even though I'm heavily invested in PHP and the change from 5.6 to 7 felt like a major surgery.
< NotAnNSAgent>
Hmm. I guess.
< sipa>
NotAnNSAgent: we also maintain bugfixes for the previous major release, and critical bugfixes for the one before
< sipa>
so it's not like an API change will hit you without resort
< wumpus>
you're taking a risk by not doing so, you can decide for yourself whether it's acceptable, but most serious companies have careful upgrade practices (like running parallel servers with a new version for a while) for anything that directly affects their bottom line
< NotAnNSAgent>
Backwards compatibility should be of utmost importance in this context, though.
< wumpus>
backwards priority is a concern, but you don't decide our priorities, sorry
< wumpus>
compatibility*
< sipa>
NotAnNSAgent: that's why accounts haven't been removed outright, and there is a long discussion going on about it
< wumpus>
right, they've been deprecated for ages, it's not as if it was removed from one version to the other
< wumpus>
but the RPC API can change in non-backwards compatible ways between *major* releases
< sipa>
also, i thought you had realized that accounts were not what you needed?
< GitHub91>
bitcoin/master c3932b3 Pieter Wuille: List solvability in listunspent output and improve help
< GitHub91>
bitcoin/master 46880ed Wladimir J. van der Laan: Merge #7688: List solvability in listunspent output and improve help...
< GitHub66>
[bitcoin] laanwj closed pull request #7688: List solvability in listunspent output and improve help (master...helpspendsolv) https://github.com/bitcoin/bitcoin/pull/7688
< Chris_Stewart_5>
is the 'first public key is invalid' i'm guesing that refers to them being consumed off of the top of the stack?
< sipa>
0 is a correctly-encoded but invalid public key
< NotAnNSAgent>
Just one more note, since sipa isn't in ##bitcoin: yes, I learned what "accounts" actually are in Bitcoin, but I also learned that the labels stuff is not stable/finished either, and that I can use "accounts" as a form of label until things stabilize, but I cannot use them to segregate money in the way I first thought was possible.
< sipa>
NotAnNSAgent: aye, indeed, thanks for clearing that up
< sipa>
Chris_Stewart_5: as the checkmultisig requires 2 valid signatures, but it only gets one, the checkmultisig fails, the NOT after is inverts that result
< Chris_Stewart_5>
sipa: That seems to directly contradict the comments "2-of-2 CHECKMULTISIG NOT with the first pubkey invalid, and both signatures validly encoded."
< Chris_Stewart_5>
sipa: You said "requires 2 valid signatures, but only gets one" - the comment says "both signatures validly encoded". Are you talking about being the correct key?
< sipa>
right... so there are 2 correctly-encoded signatures there, and a valid and an invalid pubkey
< sipa>
pubkeys are not subject to any encoding rules
< sipa>
(except when STRICTENC is on, but that's only for mempool validation, not in blocks)
< Chris_Stewart_5>
So "CheckPubKeyEncoding" is a misnomer? :-)
< sipa>
no
< sipa>
it just only has an effect when STRICTENC is on
< Chris_Stewart_5>
sipa: So is strictenc in a certain way part of relay policy? and just to be crystal clear, DERSIG is absolutely consensus critical correct?
< sipa>
yes
< Chris_Stewart_5>
Thanks :-)
< phantomcircuit>
NotAnNSAgent, you've been unbanned from #bitcoin please move your discussion there
< GitHub25>
[bitcoin] laanwj opened pull request #7939: qt: Make it possible to show details for multiple transactions (master...2016_04_qt_multiple_transaction_details) https://github.com/bitcoin/bitcoin/pull/7939
< NotAnNSAgent>
phantomcircuit: Thanks. As mentioned, I only said that to sipa because he asked a question to me in here and he isn't in there.
< NotAnNSAgent>
(Or wasn't when I sent the message.)
< Chris_Stewart_5>
arubi: Guessing it was just happen stance, I don't think there is any functional difference
< sipa>
agree
< arubi>
doesn't seem like there is, just wanted to make sure. thanks.
< GitHub173>
[bitcoin] Christewart opened pull request #7941: Fixing comment in script_test.json test case (master...fix_script_test_comment) https://github.com/bitcoin/bitcoin/pull/7941
< kanzure>
how often should testnet nodes be receiving pings?
< kanzure>
er, from a well-behaving peer node
< Guest32930>
kanzure: bitcoin core at most pings once per minute, i think
< kanzure>
have a strange peer doing it once a second.. they seem really eager to know if this node vanishes.
< sipa_>
kanzure: what is the user agent?
< kanzure>
/bitcoinj:0.15-SNAPSHOT/
< sipa_>
kanzure: i think bitcoinj has always had insane ping frequency
< kanzure>
weird.
< kanzure>
thanks.
< achow101>
what does the hex of the version for the upcoming soft fork look like?