As you note, these are indirectly accomplished via listtransactions already. It's not going to be faster to generate them directly as it will take the same process as a listtransaction to handle them internally.

Since you need help to do so, perhaps adding RPCs aren't the best way to handle your needs.

Keep in mind that errors made while programming here may cause funds loss. The threshold for where you need to add something new should be accordingly somewhat high.

Bitcoin transactions do not have from addresses. https://iwilcox.me.uk/2014/no-from-address

This data is in chainActive.Tip()->nChainTx

IRC is a pretty crappy way to have a centralized server handle things... it's crappy because the server has few tools for DOS mitigation, because messages are very limited in size, and because it's frequently blocked.

If you're willing to trust a server to mediate communications, there are better options. Though, I won't if you really are willing... what happens when that IRC server replaces addresses in payment URIs?

You haven't actually asked a question. By assistance do you mean "I'd like someone to do the work for me, for free, and I'm not even going to tell you why"?  Thats what it sounds like, absent an actual specific question. If that isn't the impression you want to give you should try making it clear that you've attempted this stuff yourself already and ask specific questions.

I did, but it doesn't follow. One does not need to use a constant address to have transparency. (As an aside, your goal has extreme scaling problems if implemented directly; part of the reason to have exchanges in the first place is to support high volume instantaneous transactions.)

This is not good for security and it's also bad for not just your privacy but the privacy of everyone you transact with (and, ultimately) for all of Bitcoin. It also creates increased systemic risk for the system as parties that reuse addresses are trivially blockable and if many users are behaving in ways that can be blocked miners may be pressured to utilize their position in ordering transaction to block particular participants in the system, the same also applies to other services such as exchanges: if you behave in a identifiable way otherwise honest participants may be forced to block or seize your funds when they can.

Forcing a single address also generally incompatible with normal business practises. A Bitcoin address is emphatically not an "account"-- it's more like a serial number of a bill, alternatively it would be more accurate to think of it as an invoice number. Normal bitcoin usage requires you to use addresses to distinguish which of multiple payers has paid you.

For these reasons this behaviour is not generally supported by Bitcoin core and I question the level of understanding of the system of anyone who produces software which works in this manner.

Thats the point Adam is making. "Anyway I claim the hard part about bitcoin is the decentralised secure inflation control (and sybil resistant byzantine generals solution.) "

Sure. Any scriptPubKey works... in that respect its no different from any other transaction.

"Counterparty" cannot actually implement a smart contract system for Bitcoin. It can only do so for its own altcoins, and only at the expense of being incompatible with SPV and being subject to blocking by miners (who might suffer loss of value of their bitcoin income should the counterparty altcoin manage to displace bitcoin to any great extent).

Well I'm not sure what you're expecting: releases are planned; and proceeding more or less on schedule: http://sourceforge.net/p/bitcoin/mailman/message/32971508/

Some features have had to slip here and there, mostly due to a lack of testing interest from the community; e.g. http://www.reddit.com/r/Bitcoin/comments/2krlob/wladimir_tweets_call_for_testing_and_review_help/

Please don't confuse Bitcoin with a product that is owned by someone who can just set out and tell you how you're going to be able to use Bitcoin in the future. Bitcoin's future is defined by what people make of it; not some schedule anyone imposes on it top down.

No they haven't.

Mike Hearn has made some comments like that, but he's not a member of the development team of Bitcoin core, and I believe everyone who is actually involved in the development was more or less mystified by his comments. I certainly was. They certainly don't reflect the actual enormous amount of ongoing activity.

Thanks for making the agenda in your post clear, I guess  But it's not so, things are actively being developed, but the design we came up with was one where much of the development could happen without any additions to Bitcoin at all (via the federated peg, described in the appendix of the sidechains whitepaper). It would be improper to take things out of order and suggest softforking additions to Bitcoin without making the use-case for it.

No fork is currently proposed.

Plenty of people are. but you choose to ignore and insult the people working on the project, for which you don't pay... don't expect them to go out of their way to draw your attention to it.

Seems to have worked out great for all those buying into MTGOX's view of the world.

Making it potentially infeasible or much more costly to introduce new nodes to the network would undermine security enormously, it's critical that this not be undermined. In any case, we've been working on this for _years_ uninformed navel gazing on bct isn't going to move it along.

None of you showed up to test the patch when we made a public call in the hopes of having an initial version in 0.10. Perhaps in the next version.

That isn't the case. Yes, reference counting is one tool, in that box but it has considerable costs. Most things are handled by RAII. And then there is unique_ptr... "By hand" is also perhaps misleading... in that, for better or worse, the developer themselves doesn't see the machinery under the hood any more than they see boundary checking in Java.

There are hundreds of contributors who have been auditing it for years as part of their use (and, in some cases, efforts to enhance it)-- the difference is that they went in and did it, they didn't step up here and ask for money before even showing that they had the skills to contribute useful review.

We mostly do not use manual memory management in Bitcoin core. Virtually all use of delete is in explicit destructors, most things are just RAII. I looked a while back and think found only something like three or four instances of use delete outside of destructors, and I assume those cases will all be changed the next time they're touched (e.g. examples include the wallet encryption, which hasn't been touched in years).

(I thought it was really weird of Mike brought up manual memory management, I see I made an error in not correcting him.

It is not quite so simple. You'll abuse your peers if you make them think you can serve them blocks but fail. If you erase too much you'll be unable to reorganize.   We plan on actually supporting this, in a sane organized manner probably in the next major version. (The fact that you were able to try that at all is a result of our work to facilitate that feature, prior to 0.8 there was no data you could just delete without making yourself unable to verify new blocks.)

You wrote, "Most exploits arise from programming errors in low level weakly typed languages". I pointed out that in our space we've observed the opposite: There have been more serious cryptographic weaknesses in software written in very high level languages like python, javascript, php, Java. etc. Thats all.  Please tone down the personal insults. You're very close to earning an ignore button press from me. I have scrupulously avoided besmirching your skills-- or even saying that I think your preferred tools are not _good_, only that that people using them suffer errors too-- but in every response you make you attack my competence.

Yes, years ago. https://bitcointalk.org/index.php?topic=21995.0

Our process is not "don't make mistakes", Bitcoin Core largely uses a safer subset of C++ that structurally prevents certain kinds of errors (assuming the subset is followed, we don't have any mechanical enforcement).  I don't believe anyone writing or reviewing code for the project would describe things primary safety strategy as coming from "don't make mistakes", not with the level of review and the general avoidance of riskier techniques.

Though even equip with automatic theorem provers that could reason about cryptographic constructs no language or language facility can free you from having to avoid errors (though avoiding errors is much more than "just don't make them").

Things like "restart on crash" can be quite dangerous, because they let an attacker try their attack over and over, or keep the software running (and mining / authoring irreversible transactions) on a failing system. In most cases if we know that something that the software hasn't accounted for has happened just being shut down is better. If doing this results in a DOS attack, ... DOS attacks against the network are bad, but they're preferable to less recoverable outcomes. I think if anything we'd be likely to go the other way: On a "can never happen" indication of  corruption, write out a "your_system_appears_busted_and_bitcoin_wont_run_until_you_test_it_and_remove_th is_file.txt" that gets checked for at startup.

There have been Java bitcoin software, e.g. a vanity-generator that generated predictable keys, altcoin software that failed in various ways, bouncycastle causing inconsistency in node software from throwing surprise null pointer exceptions on weird inputs. I wasn't saying that there was any language issue there, but pointing out that even using the most confined language you can find will not prevent people from writing unsound cryptographic software. (And perhaps even making things worse, if the protection against idiotic mistakes makes people forget that they're playing with fire.)

Actually no, you're catching the point I'm making but missing it.  Cryptographic systems in general have the property that you live or die based on implicit details. Cryptographic consensus makes the matter worse only in that a larger class of surprises which turn out to be fatal security vulnerabilities. It's quite possible, and has been observed in practise, to go end up with exploitable systems because some burred/abstracted behaviour is different than you expected. A common example is propagating errors up to to the far side when authentication fails and leaking data about the failure allowing incrementally recovering secret data.  Other examples are that implicit padding behaviour leaking information about keys (there is an example of this in Bitcoin core: OpenSSL's symmetric crypto routines had implicit padding behaviour that make the wallet encryption faster to crack than had been intended.)

I'm certainly a fan of smarter tools that make software safer (I'm conceptually a big fan of Rust, for example). But what I'm seeing deployed out in the wider world is that more actual deployed weak cryptography software is resulting from reasons unrelated to language.  This doesn't necessarily mean anything about non-cryptographic software. And some of it is probably just an attitude correlation; you don't get far in C if you're not willing to pay attention to details. So we might expect other languages to be denser in sloppy approaches. But that doesn't suggest that someone equally attentive might not do better, generally, in something with better properties. (I guess this is basically your demographic correlation).  So I'm certainly not disagreeing with these points; but I am disagreeing with the magic bullet thinking which is provably untrue: Writing in FooLang will absolutely not make your programs safe for people to use. It _may_ be helpful, indeed, but it is neither necessary nor sufficient, as demonstrated by the software deployed in the field.

Tampered firmware can just feed you a copy of the correct firmware.  (snake oil certification even gets the clueful folks, I guess).

The btcchip stuff apparently works with multisig... though it's a little odd to use because it doesn't have a display (it does a very clever thing where it acts as a USB HID device and you plug into another device to act as the screen.)

It was an issue in OpenSSL (bitcoind doesn't expose SSL to the public in a default, or even sane, configuration at least).  Every other language also depends on system libraries too. So the language Bitcoin core was written in was irrelevant in this example.

I'm sorry you feel that I'm nitpicking, but I'm not trying to.

So far our experience in this space is that there is more irresponsible and broken software written in higher level languages, there has been virtually no issues in this space from cryptographic weaknesses (or even conventional software security) in Bitcoin applications written in C / C++. I agree that sounds somewhat paradoxical... but it's not that shocking: The security of these systems depends on the finest details of the behaviour of each part of the software and the interactions, when your system obscures the details some extra work is required to review though the indirection. This somewhat offsets the gains. In cryptographic (and especially consensus) systems it's much harder to "fail safe" and a much wider spectrum of unexpected behaviour is actually bad and exploitable. Languages like Java make some kinds of errored software "more safe" when the software is incorret, but making software more correct is still something that is largely not reaching production industrial software development yet (languages with dependant types and facilities for formal analysis seem like they _may_ result in more correct software).  

There is no replacement for hard work and many view higher level languages as an escape from drudgery, so there may be some language selection bias from the attitude of the authors that has nothing to do with the language itself.  In any case, I think your barb was misplaced, at least in this thread: We've seen bad RNG behaviour from Java software several times, and not just in system libraries. (And not just RNG safety, also things like attempts at full node code being shattered by underlying crypto libraries bubbling up null pointer exceptions that cause false block rejections which would have created forks if it were widely used).

(I do agree though that using untyped languages is basically suicide for any, even moderately large, system where correctness matters.)