I went and added a note to PuertoLibre's post. I will never stop being amazed by people's inability to read!

It is reasonable and customary to replace misleading thread titles.

People gave BFL coin— if the value of the coin went down (potentially to zero) you would still be demanding to receive valuable mining hardware. If the value of coin went up (as it had) you seem to expect to be able to demand a refund at the new market rate (and then be presumably able to turn around and make a new order with fewer coins).  That would be a pretty awesome hedge if they'd let you make it.

I'm getting a lot of complaints that people though the subject meant the BFL wasn't honoring refunds, and people are irritated that they're getting worked up before discovering that becoin just wanted BFL refunds to act as a hedge against bitcoin's exchange rate relative to the dollar changing.... so I've changed the thread's subject.

You removed important information as I _specifically_ described here, and I didn't see anything important added. By commenting here shortly after I made sure that you wouldn't miss the change. You made _103_ consecutive overlapping commits to the the script page but change very little besides removing information with the result of the page being less complete and accurate.  Improving it is good, but not at the expense of accuracy.

One of the edits you've made on the wiki was so deeply incorrect— editing in direct opposition to the clear meaning of the pages— that I wondered if you were being intentionally wrong.   Your interest in Bitcoin is certainly welcome, but your ignorance of your ignorance and your disrespect towards others is unlikely to result in useful cooperation.

I do not oppose you continuing to participate here and on the Bitcoin wiki— but I think you will find more satisfaction if you participate with a softer hand.

Every word of this is false except "Whatever", and potentially "AFAIK".

I encourage everyone to just press ignore on the OP.

I'm not sure if he's just confused or if the crazyness is performance art— but he won't revise his positions on correction... but whatever the cause his arguments are wrong and misguided and will potentially make you stupider by reading them.

You can't merge-mine without running your foocoin code. ::shrugs::   the pool miner slaves don't but they don't have to no matter what you do.

I'd generally advise against creating a fork— unless you have some really novel ideas to try out as no one really wants or needs more of the same. If you do have novel ideas the forking itself will be the smallest part of the work.

If you do fork be sure to change the network bytes otherwise you'll be quite sad.

How about, I dunno, FIXING THE SOFTWARE instead of a risky (soft)fork creating change the perpetually limits the functionality and STILL doesn't resolve the issue?

There is no fundamental reason that anyone should need to have the inputs in memory— and even with a fairly restrictive 100k limit someone could cause a someone who loads all the inputs currently into memory to use 300 mbytes to process a transaction.

Please stop claiming that unconfirmed transactions are safe*†‡™.  

It is not the case, has never been the case, and never will be the case. The policy miners use to determine what transactions they accept into block is not knowable to clients.  Because of that when you have an unconfirmed transaction all you can do is speculate if it will be mined in minutes, hours, or never. Because of this it is very hard to reason about how long one might be before its accepted and what the odds are that a conflicting transaction could make it in first.

Unconfirmed transactions _may_ be an acceptable risk in certain contexts— a transaction which is safe because the sender would never rip you off, or because you have a copy of their street address, or which is safe because you can revoke service— those are safe on their own merits, and safe with or without a 'few lines'. Accepting an unconfirmed transaction is nearly equivalent to accepting signed email promising to pay. It's evidence of an intention, but it's not very binding. The people who can safely handle unconfirmeds after your fix are the same who could handle them without: those who don't depend on security from Bitcoin.

The unfortunate status quo is that a lot of parties are accepting unconfirmed transactions who shouldn't be— who are highly exposed, who have no other security mechanism— they're getting away with it because no one is even bothering to try to attack.

Without disclosing retep's issue, I'll point to one that is already public:    I create a long series of unconfirmed transactions, weighing in at 72 megabytes.  I pay you with a transaction who takes this long chain as one of its inputs.   The soonest this transaction can be confirmed is twelve hours from now, but it's likely it would take much longer.  In that time I can happily provide a conflict on one of the inputs to one of several pools that ignore zero/low fee transactions, and twelve hours is more than enough for them to solve a block.  You will not be paid but the transaction looked okay to you, you likely will not ever hear about the conflict until it is in the chain, as the nodes surrounding the miner in question will not relay it.

Does your few lines of code fix this?  There an infinite number of ways which transactions may be differentially attractive to different nodes, and so there are an infinite number of reasons miners may take a later transaction rather than an earlier one. Only confirmation is persuasive evidence of eventual confirmation.

Good catch. I've reverted— as in a quick review removed a bunch of useful information (e.g. removing the sizes of the returned types).

Chinese you say? Basted on the attitude, cluelessness, and wiki editing volume I would have guessed it was atlas.

How many exploitable issues must arise before you change that position?

Seems that the post is creating a ton of questions. So here are some of the answers I'm giving.

(1) Yes, retep's post has substance.
(2) It's really not specific to any particular client software.
(3) Some people will consider this obvious / old news / not-a-bug: but—
(4) many things accepting unconfirmed transactions are vulnerable, and more vulnerable then they believed themselves to be which substantiates that it really is news
(5) Generally accepting unconfirmed transactions is really risky for a multitude of reasons, one of these reasons being in fact the meta-risk that it's harder to reason about the safety of unconfirmed transactions than confirmed ones.
(6) People are being hesitant with details until vulnerable sites are fixed and improved software is made available that helps lower exposure for those foolhardy enough to continue to accept unconfirmed transactions.
(7) In the meantime, stop doing it. If you run software that doesn't have an option to stop accepting them, throw out and replace your software because its dangerous and probably has other flaws. There may be times in the future where network instability requires you to increase your confirmation counts.
(8) For those of you who figure it out on your own, you can feel free to brag to me in private, but please have respect for the hard working people who are running businesses that are vulnerable and don't do anything to cause them trouble.
(9) If you're already not accepting unconfirmed txn then this isn't an issue you need to worry about.

A size reduction is not justified by your posts.  And a simply pool of a not well informed audience is not a good mechanism to make decisions.

Your transaction doesn't qualify as free, so it's applying 0.0005  BTC per 1000 bytes of transaction data. Your transaction is 43kilobytes in size. A basic transaction is about 230 bytes in size. Your transaction is likely so large because something has been paying you in very tiny coins.

E.g. it's like you asked for all your change in pennies and now that bank wants a fee to handle the big sack you're turning in to deposit.

Pedantically, an electrum server can put you on a not-longest fork, and from there could give you fake payments which look confirmed (electrum is gradually getting better too, so in six months this may no longer be true).

More generally, if most Bitcoin users follow your reasoning bitcoin itself will be insecure— subject to theft, inflation, etc.  Because the marginal personal security/privacy cost is low (and likely to be underestimated due to hyperbolic discounting and underestimation of small risks) in running a reduced node we have a tragidy of the commons risks where almost no one honest runs full nodes (except attackers as they have a clear incentive!) and the network dies.  To address this we should strive to minimize the cost of running a full node (relative to technology) and we should produce altruistic software which automatically runs a full node on hardware that can handle it without burdening the user.

It does not for spent transactions in GIT, and won't by default (at least, and probably not at all) in 0.8.

Echoing what Jeff said— agreement isn't what will make a difference here, working on it will. Even if you don't have the time or background to contribute specifically the features you want contributing to testing will help get more done. (We appear to be primarily testing constrained, as we'd like to advance the level of software quality in the reference client but have a large preexisting deficit)

For the most part thoughts like this aren't "no don't!" they're "sure, that sounds like a fine idea … someday when someone has time" and anyone technically sophisticated enough to find bitcoin and post in the form can probably do something to help that someday come about a bit sooner.

It's cheaper than invalid transactions that crash most/every node how?

Gimme a testnet address I'll send you 16000 TN BTC, feel free to see if you can actually trigger it there. (Edit: On seeing this message again it seemed to me that I might have sounded dismissive there— it wasn't my intention.  I'm just offering to help out with PoCing it on testnet)

No, thats not the security model we seek to have for obvious reasons.

In general, there are many dos attack vectors which are possible but which are not interesting because they are not transitive— and so get no amplification e.g. the attacker sends 10gigabytes to waste 10gigbytes of one nodes bandwidth (something which can't be prevented no matter how the software is written); or which are potentially transitive but require mining large number of malicious blocks that extend the current chain (which has a very high computing cost, and under a situation were a malicious party were mining lots of best blocks we'd be lucky if all they did was a dos attack).

Attacks that involve mining orphans are good to reduce, but they don't form transitive attacks so the attacker tends to get no amplification.

You're over thinking this, it's not that crazy.  A lot of people expected— for good reasons! the hash-rate to drop like a rock around the time of the subsidy halving, after all— the return just halved and anyone paying higher electrical prices went from making a small amount to losing money. But it didn't drop, it _went_ up a bit.

Someone running an asic farm could be happily monitoring the network hashrate minus themselves and slowly increasing their rate over time so that the network rate just increases gradually, with most of their power coming online as GPUs go offline due to declining profitability.

I'm not saying it's proven... but it's possible. And for all the people who were insisting the hashrate would tank it's a viable competing theory.

Not quite, the accepting side would still see the mining of the non-accepting side. It's not mutually exclusive.

Of course, the value of bitcoin depends on it not biurficating. That would be a maximally bad outcome: basically everyone with funds before the split would double their funds. So thats obviously highly unstable.

We don't use encryption in bitcoin. Perhaps you meant signatures? We can actually upgrade signature algorithms without a hard fork.