Regarding the maximum transaction size...

[Sergio_Demian_Lerner]

I'm testing the poll system to see if it can be used to achieve consensus. It's more an experiment with the Bitcoin community than a voting on any change.

If I see a pattern on the answers for smaller sizes, then that justifies writing a Bitcoin Improvement Proposal (BIP) to do a soft-fork to reduce the maximum size, which can protect the clients from memory exhaustion problems.

Thanks you for your participation!

[1714025396]

1714025396

[1714025396]

1714025396

[1714025396]

1714025396

[1714025396]

1714025396

[1714025396]

1714025396

[blueadept]

In the situation of assurance and dominant assurance contracts, the transactions could have thousands of inputs. This wouldn't really trigger the transaction fetch memory exhaustion vulnerability as there's only a handful of outputs at most, and the output would be unlikely to be redeemed with a whole lot of other large transactions.  In the future, when payroll and affiliate commissions are paid in bitcoins, you'll also see legitimate transactions with many outputs.

[gmaxwell]

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.

[Sergio_Demian_Lerner]

A size reduction is not justified by your posts.

I disagree.
Suppose you are implementing the following two-party protocol for an antivirus web server:

1. Client. Uploads a file.
2. Server. Checks the file for viruses and sends a respond to the user with the result

Would you let the user send files as long as 4 Gb ?
Why? What implications would that have to your antivirus infrastructure?
What would be the additional cost and complexity of designing an antivirus checking module that can handle such files, assuming such files won't fit in RAM.
What if some programmer forgets that such a file can be uploaded?
What if many users sends such big files at the same time?
There are too many "whats if" for such an unused "feature".

You see, Bitcoin has the same problem. Transactions can required more than 4 Gb to be processed by any existing client. You can either handle it by reducing very little the transaction size, or you can wait to see when a smart hacker notices how to exploit the problem.

And a simply pool of a not well informed audience is not a good mechanism to make decisions.

To "inform the audience", first you have to make them think for themselves about something. I have no authority to make ANY decision. I'm nobody, not a core dev, not a mining pool owner, not a merchant. I don't even own BTC, apart from the ones in my testnet.

I'm here because I like Bitcoin.
 

[gmaxwell]

You see, Bitcoin has the same problem. Transactions can required more than 4 Gb to be processed by any existing client. You can either handle it by reducing very little the transaction size, or you can wait to see when a smart hacker notices how to exploit the problem.

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.

[istar]

January 09, 2013, 01:29:00 AM

So with only 4000 BTC you can execute an attack that disconnects all Windows clients at once. The attack takes 14 days to be prepared, so that gives enough time for users to upgrade (or if the core dev develops a patch fast enough)

This is the cheapest attack to the whole network ever seen.

2 days later

Over 4k BTC bought in one shot
http://www.reddit.com/r/Bitcoin/comments/16bf98/over_4k_btc_bought_in_one_shot/

Coincidence?