It's fine, yes. I mean a relay without a blockchain at all.  I think I misread your post as saying you had 1GB storage, but I'm guessing now that you have 1GB ram.

Soon-ish (probably in 0.11) we'll support running pruned nodes which could fully verify things but won't need the whole blockchain. They'll still require a couple gigs of storage and that amount will grow (but much slower, unless things that spam the utxo set become popular)... which might fit better on a small device like that, though it would be useful it wouldn't be as useful as something with the whole history.

That you could do. Though right now you'll need, say, 60 gigs of storage though better if you have more since you'd be able to keep serving old blocks long into the future.  (Actual usage is more like 32GB at the moment, but since it can grow at a rate of about 25-50GB/yr, it's best to have plenty of headroom if you're going to store a full chain.

USB flash sticks often wear out quickly when there are many writes, so you'd want an actual SSD or spinning hard drive. On newegg it looks like one can get a 500GB usb external drive for under $50.

Absolutely. One thing that would be pretty useful is to run a hidden service bitcoin node,  we're rather short on HS nodes and you can use tor to limit the bandwidth. ("BandwidthRate" in torrc).

The maximum long term average data rate for the blockchain is about 14kbit/sec. So even just a few megabits can do a lot to help keep more peers connected.

A relay node that doesn't filter for validity is not very useful for Bitcoin (and can easily be caused to get banned by all its other peers) and at worst is an attack amplifier.

It's great that you want to support the network, but running another node on that host is probably not the best way that you can do so right now.

Ah, it's the standard game of trying to con the Bitcoin technical community into doing the engineering work for some competing altcoin which doesn't actually have any technical backing.

Thanks Shorena.

Of course, otherwise it would risk triggerable (or even spontaneous) convergence failures which could be exploited to cause loss of funds.

This does fit within the model of "address as an invoice number", and it's strictly less harmful than other kinds of reuse. Though it would certainly be possible to provide multiple addresses for this purpose (the payment protocol accommodates this, IIRC). There may be reasons why the receiver cannot handle funds split up, and so the willingness to accept multiple payments really should be established up front or no payment should be made.

This application was my primary inspiration for the type-2 deterministic wallet proposal, which became BIP32: The FSF started accepting Bitcoin donations and they asked about being able to issue receipts for donation in order to comply with IRS requirements for 501(c)(3) chartable contributions over $250 in value. Doing so required they use one address per contribution but they did not want to generate private keys on an exposed web server which could be hacked.

Using an extended pubkey to receive funds allows the sender to verify the correct receiver statically without reusing addresses. Though this is not yet common.

Considering that the donor's ability to deduct donations is lost completely for donations over $250 if the recipient cannot issue receipts, and in the US an organization accepting quid-pro-quo donations without issuing receipts (which they cannot do if they're reusing addresses) is in violation of the tax code and could be subject to fines, I question your cost/benefit analysis in that context.

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.)