There were indeed way too many Bitcoinduit topics. I have locked many of them. When things get out of hand like this and reports aren't getting results, PM me.

Ignoring those, it seems to be mostly non-Ponzi gambling still.

Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
2 KeyA KeyB 2 OP_CHECKMULTISIG OP_DUP OP_NOTIF KeyBackup OP_CHECKSIG OP_ENDIF

I was thinking recently that it might be a good idea to write the code for all of the proposed (and agreed-upon) changes to Bitcoin's core structure and put them in place, but keep them disabled until a transaction version increase is forced by some critical bugfix.

An enhanced version of OP_CHECKSIG could also specify which hash algorithm is used for hashing the transaction before signing.

I don't think it's reasonable to put the burden on the sender (in the general case, at least). The large addresses will be annoying to work with, and fees will be higher due to larger data sizes. There may even be programs made to transform "expensive" addresses into "cheap" addresses by changing the version and removing all but one address.

The recipient should receive on a normal address and then resend to himself with the odd transactions. Then the recipient pays the extra fees, and no one will have to deal with huge addresses. There will be a short period of time when the funds are unprotected, but I don't think this will usually be a problem, and it's worth the benefits.

I don't see why it's necessary to support addresses for backup and secure-device transactions. Bitcoin can remember the public keys before they are exported to the backup or device.

With an additional device:
KeyA is a local key known by Bitcoin. KeyB is probably remembered from previous use; if not, it can be transferred in a QR code without much trouble (~90 base64 characters is fine).

With a backup:
KeyBackup is static, remembered by Bitcoin. KeyNormal is a local key.

Done.

I'll resend donated funds to the main address so you can see the proper received amount. (As always, note that balances and sent BTC amounts will not be correct.)

If ScriptPubKey says:
Then ScriptSig must provide signatures for exactly two of A-C, listed in order.

If ScriptPubKey says:
Then ScriptSig must only provide one of A-C.

It's not sane to allow the scriptSig to provide the sig count, since it would be legal for them to set it to 0.

It's not fiat because, as you mentioned, people can choose to accept or reject the changes.

It will be easy to see which transactions came first, since the blocks containing those transactions were broadcast and then later "replaced". There may be problems with innocent people losing confirmed transactions that were based on double-spent coins, but hopefully the problem can be dealt with before this happens much.

The client should probably require 120+ confirmations for transactions that seem to be double-spends, since these transactions could be reversed later on. Maybe if this kind of attack becomes an issue, a peer warning system for double-spent transactions could be developed to trigger this protection.

Bitcoin could also enter safe mode automatically whenever a reorg longer than 6 blocks is observed, or when smaller reorgs happen too many times within some time period.


Their wallets will be drained in any case. The hardcoded changes might return some of the coins.

It's an interesting use of the block chain. This is actually one of the only five topics I'm receiving notifications for...

I think it deserves a place somewhere on the forum, so I've restored it to off-topic.

DiabloD3 deleted it.

Any serious attacker is going to take down this forum, Freenode, and any other IRC network we use while he attacks Bitcoin. This will seriously disrupt efforts to fix the problem.

For example, if #bitcoin-dev and the forum had not been available during the overflow incident, lfm (IIRC) would have had to report the bug directly to someone via email. Maybe he would have waited hours/days to do this. There was also rapid-fire collaboration on #bitcoin-dev to create a fix and spread the word.

Some alternative to #bitcoin-dev needs to be prepared for emergencies like the overflow incident, when #bitcoin-dev might not be available. IRC-like real-time communication would be ideal, as it allows quick collaboration.

Initially I was thinking that in case of a Freenode outage, we could get several people to temporarily donate servers to the LFnet IRC network and relocate there. However, laszlo has told me that IRC is inherently weak to denial of service attacks and is unsuitable.

Other methods:
- This forum could certainly be taken down easily, so it is not suitable.
- I'm not sure how easy the mailing list is to take down. My guess is that flooding would kill it pretty easily. Maybe an invite-only or moderated list would be more resilient. If Bitcoin gets very big, it might become economical for the attacker to take down or corrupt SourceForge.
- I think Usenet is pretty resilient, but can groups be easily flooded into oblivion?
- Freenet would work nicely, but it's too difficult to use. Requiring it would prevent most people from joining the discussion. (I don't even run it any more, since it takes up too many resources.)
- Tor/I2P hidden services are worse than non-anonymized centralized services for DoS-resistance.

Are there any alternatives to IRC that can withstand powerful DDoS attacks and spamming?

It won't be difficult when an alert is issued and everyone's clients are saying "EMERGENCY: DO NOT ACCEPT TRANSACTIONS UNTIL YOU HAVE UPGRADED".


There are various techniques that can force the attacker to get larger percentages of computational power before getting control. These would be developed if necessary. We'd also get better at handling alerts (probably alert-enabled safe mode would be re-introduced) and detecting attacks automatically.

Legitimate miners would have an excuse to charge higher fees, which would allow them to get more hardware.

The attacker will run out of money eventually. It'll never be profitable.


I don't really care about the price. The network will survive, which is what counts.

If someone tries that, an alert will be issued and payments will stop for as long as the botnet owner is willing to waste money. Once the botnet gives up, any damage they've caused will be reversed by hardcoding correct values into the client. Only a few people will end up losing money, and the botnet owner will be worse off than if they had stuck with normal botnet activities or legitimate mining.

There is a backup once per day, which basically takes down the forum for 5-10 minutes. I've never actually been on the forum while this was running on its own, though: I've only seen it when I've manually created the backup.

There's also an update of membergroups every 10 minutes that slows things down for a few seconds.

He'll say, "Hey Ben, print me up some more money."

I think that would be annoying.

Start a topic about it in the Portuguese section. Because I can't read Portuguese, I can't decide whether a subsection is necessary.