Bitcoin Forum
June 14, 2024, 07:33:22 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Lets talk about bitcoin which features would you like to be implemented?  (Read 1291 times)
hackjack (OP)
Member
**
Offline Offline

Activity: 63
Merit: 10


View Profile
April 26, 2014, 01:14:27 PM
 #1

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?

franky1
Legendary
*
Offline Offline

Activity: 4256
Merit: 4521



View Profile
April 26, 2014, 02:05:31 PM
 #2

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 26, 2014, 02:09:39 PM
 #3

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.

Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
April 26, 2014, 03:21:45 PM
Last edit: April 26, 2014, 11:16:16 PM by Peter R
 #4

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

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

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
BitCoinDream
Legendary
*
Offline Offline

Activity: 2338
Merit: 1204

The revolution will be digital


View Profile
April 26, 2014, 03:26:05 PM
 #5

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

Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
April 26, 2014, 03:34:02 PM
Last edit: April 26, 2014, 11:16:28 PM by Peter R
 #6

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


Run Bitcoin Unlimited (www.bitcoinunlimited.info)
sana8410
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
April 26, 2014, 11:58:18 PM
 #7

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

RENT MY SIG FOR A DAY
Trongersoll
Hero Member
*****
Offline Offline

Activity: 490
Merit: 501



View Profile
April 27, 2014, 06:15:40 PM
 #8

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.
tins
Hero Member
*****
Offline Offline

Activity: 882
Merit: 500


View Profile
April 27, 2014, 11:00:18 PM
 #9


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.
noviapriani
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250


View Profile
April 30, 2014, 09:49:00 AM
 #10

 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.

sana8410
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
April 30, 2014, 10:27:30 AM
 #11

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!

RENT MY SIG FOR A DAY
cuddaloreappu
Hero Member
*****
Offline Offline

Activity: 756
Merit: 502


View Profile
April 30, 2014, 10:45:48 AM
 #12

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

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 30, 2014, 04:21:38 PM
 #13

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)

Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1129


View Profile
April 30, 2014, 08:04:07 PM
 #14

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.

zolace
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
May 01, 2014, 04:44:35 PM
 #15

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

⚂⚄ Pocket Dice — Real dice experienceProvably Fair
Free BTC Faucet
⚅⚁
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
DNScode
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
May 01, 2014, 08:57:59 PM
 #16

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

Activity: 924
Merit: 1129


View Profile
May 10, 2014, 07:18:52 PM
 #17

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. 




BurtW
Legendary
*
Offline Offline

Activity: 2646
Merit: 1136

All paid signature campaigns should be banned.


View Profile WWW
May 10, 2014, 07:32:14 PM
 #18

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
CarlesPuyol
Legendary
*
Offline Offline

Activity: 1148
Merit: 1000



View Profile
May 10, 2014, 07:36:47 PM
 #19

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...
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 10, 2014, 07:51:04 PM
 #20

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

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!