Bitcoin Forum

The Bitcoin network is hard to change, and that's mostly a good thing, but it also makes certain upgrades very hard. Assuming there absolutely had to be a hard fork, what would you like to see added to Bitcoin?

miners cannot be picky, ignoring certain transactions. going back to basics of accepting all tx's into a block

I agree.  I even started a thread about this in the dev section.
https://bitcointalk.org/index.php?topic=582386.0

This would minimize damage from a 51% attack,
however, people do not think it is easy to do.

Just to confirm, franky1: you are not suggesting a protocol change to try to force miners to doing this.  You are suggesting that through education, awareness and social pressure that miners decide to do this on their own, as they realize it is better for everyone. (E.g., Peter Todd recently showed how P_{0-confirm-double-spend} increases as the homogeneity of the TX-selection criteria decreases).

I think this is true in general: protocol "features" to fix perceived "weaknesses" instead make the system less usable and robust.  

How do they pick actually ? I guess its not a manual process. So inserting any filter in the code ?

The problem that Franky1 is referring to is that certain miners will not mine transactions from on-chain gambling sites.  Peter Todd showed how he could use this information (heterogeneous TX selection criteria) to his benefit (if he were an attacker) to increase the chances that his 0-confirm double-spend would be successful.  

This in an example of how someone thought they were doing a good thing (Eligius by blocking what they perceived as "blockchain spam") but it had unintended negative consequences for everyone (made 0-confirm double-spend attempts a bit more likely to succeed).  

I would like speed of light transactions with processing, maybe someone will figure out how to implement something like that, I had a few ideas

I think Bitcoin needs an open source/free Vendor's program that is easy for Brick & Mortar stores to use. It may exist already, but i haven't found it and i've been looking so how would others find it. I saw a video of somone making a sale using those square data transfer things(not sure what they are called). I'd guess you'd also need to be able to email an address to someone as well for those with laptops. Many store transactions are small enough that just seeing them in the transaction que is good enough. If some one rips you off for $30 or less, ya just don't sell to them again.

I like franky's idea. I wouldn't want any fundamental changes to bitcoin. Just make it so that miners push transactions through at an equal pace.

 read somewhere about the horrifying maths required to encrypt the inputs and outputs so you could still verify they were the same sums, just not what they actually were.
That’s be pretty cool.

This isn't really a hard fork requirement since bitcoins don't exist at all in the protocol, only satoshis, but I'm 100% on board! I think the price of bitcoin has will continue to seriously hurt adoption. People think it's like buying an ounce of gold. Nice to have, but unrealistic for any transactions. Really, that's not the case at all!

Faster transactionand confirmation, multisignature ability, option for biometric passwords, two factor authentication, and much more

Transactions already happen in seconds.  Bitcoin already has multisig capabilities.

Biometrics would involve hardware, so this doesn't apply in the code.
2FA also is implemented at a different level (online services)

I'd like to see some "standard" scripts integrated into the wallet, but that's not a hardfork issue. 

For a hardfork, I think there ought to be script instructions to load the current block height, some other basic statistical information about recent transactions, and the results of specific queries such as 'has txid XXXX been confirmed?'  into the top of the stack; it would drastically extend the capabilities of scripts.

Move the decimal point so that 1 bitcoin = 100 satoshi, and all balances, including the block reward becomes 1 million times larger.

What would I like to see added to Bitcoin? nothing. it's absolutely great!

Currently it is possible to hash (eg, in a pool) without knowing the hash of the block you're trying to build on; that's a security problem because pool miners can be diverted into attacks on other coins, into building a hidden chain, or otherwise away from the chain they think they're working on, without their knowledge.  We could fix this by altering the hashing algorithm in a way to make it require separate knowledge of the previous block's hash. 

This will never happen in BTC though because it would destroy the value of the sunk cost of miners in ASIC rigs. 

Something like coinjoin automatically done to all transactions in every block.  That would fix the "we are going to black/red/white list coins" people but good.

if it was easier to change between BTC and real money, it was much better.
new people that still don't trust virtual cois, afraid of this and it can down the panic sometimes...

Most miners "choose" by setting three parameters in bitcoind (or a modified version of bitcoind).
1) The block size
2) The amount of space devoted to high priority txs with no fees.
3) The min fee for the rest of the block space.

Bitcoind sorts and ranks transactions and then as many tx as will fit that criteria are used.  For the "free" portion of the block tx are ranked by priority.  For the "paying" portion of the block they are ranked by fee/KB.  For default implementation for the transactions to be added to the memory pool (and thus be eligible for inclusion) they must be "standard" (pass the IsStandard checks).

For example setting 500KB, 50KB, and 0.1 mBTC the software would analyze the memory pool (list of tx waiting to be confirmed) and add free txs in order by priority until the next tx would make the total >50KB.  It would then add paying txs ranked by fee/KB until the next transaction would make the block larger than 500KB.

I don't see any reason to introduce major changes.  Thankfully, Satoshi and the core developers have designed a great system already.  Only minor changes, mostly related to further securing and solidifying the protocol, are necessary IMO.  Unless a major fault is found with the core protocol, then no changes are needed.  All 2.0 services can be built on top.  Avoiding unintended consequences of protocol changes such as what happened with the March 2013 fork should be the highest priority.  Leave experimenting to testnet and the alts and if a major change is deemed absolutely necessary, then reevaluate.

Agreed however the March 2013 fork was due to an implementation issue not a change in the protocol. 

I'd like to see it hardened against rainbow table attacks so Brainwallets are less risky.

Would the easiest way to do this be with a website like bitaddress.org implementing this hardening clientside.

something like   Sha256(bcrypt(Passphrase))