Bitcoin Forum
December 13, 2024, 08:40:47 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [better]coin eats bitcoin  (Read 1567 times)
asdf (OP)
Hero Member
*****
Offline Offline

Activity: 527
Merit: 500


View Profile
April 28, 2011, 02:18:49 PM
 #1

There has been some debate over the ability of the xtfee/mining economy to function. You know, the whole tragedy of the commons thing.
http://bitcointalk.org/index.php?topic=6284.0

If a solution is found, it may involve a drastic protocol change, which at this stage of bitcoin may be impossible. However, I believe I have come up with a way to bootstrap the new system off of bitcoin, sidestepping the whole get-currency-into-the-economy problem and allowing us to keep our hard earned value.

The idea is to spend bitcoins into the new currency (bettercoin). First generate a keypair in bettercoin. There will be a function F, which maps a bettercoin address, x,  to a bitcoin address, F(x). The function isn't so important in implementation except that it's output must be a valid bitcoin address. F could be a hash or it could truncate the bettercoin address (if it's longer), flip the bits, whatever.

Now, in bitcoin, to transfer bitcoins to better coins you simply spend your bitcoins to F(x). As far as bitcoin is concerned, these coins are lost forever, because no one has the private key of F(x). This eliminates the possibility of double spends. Bettercoin systems have to read the bitcoin blockchain to check if coins have been spent to F(x). If so the bettercoin address x has the equivalent amount in bettercoins.

If bettercoin is indeed superior, all bitcoins will soon be spent into the new system in this fashion.
asdf (OP)
Hero Member
*****
Offline Offline

Activity: 527
Merit: 500


View Profile
April 29, 2011, 04:47:12 AM
 #2

Really? not feedback on this?

bump
FreeMoney
Legendary
*
Offline Offline

Activity: 1246
Merit: 1016


Strength in numbers


View Profile WWW
April 29, 2011, 05:16:47 AM
 #3

Seems like it would work. So now improvements don't have to be the enemy, yay.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416
Merit: 277


View Profile
April 29, 2011, 11:04:07 AM
 #4

Your post got me thinking about how such a handover should be managed, hence my thread http://bitcointalk.org/index.php?topic=6753.0

I don't see the need for your function F. People could just send to any agreed valid address which doesn't have a known public key associated with it such as 11111111111111111111BZbvjr. Spends to this address would generate magical crediting transaction on the "bettercoin" system.

A more difficult problem is managing the handover of mining power ie what to set the difficulty to on the new network and how to ramp it up as mining pools join. Also on the old network, how to prevent attacks when most miners have left but there are some normal users wanting to leave.

ByteCoin
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
April 29, 2011, 12:54:41 PM
 #5

Neat idea, but the main problem I see is that the bettercoin protocol needs to specify what the exchange rate between bitcoin and bettercoin is (whether it's 1:1, or a function of time, or whatever). But their individual values should vary independently based on the popularity of each. I think it will be better to simply set up an exchange between bitcoins and bettercoins.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
LZ
Legendary
*
Offline Offline

Activity: 1722
Merit: 1072


P2P Cryptocurrency


View Profile
April 29, 2011, 11:59:03 PM
 #6

I think that we do not need something like 'bettercoin' right now or in the foreseeable future.

Maybe in the 22nd century? Undecided

My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
asdf (OP)
Hero Member
*****
Offline Offline

Activity: 527
Merit: 500


View Profile
April 30, 2011, 01:04:54 AM
 #7

Your post got me thinking about how such a handover should be managed, hence my thread http://bitcointalk.org/index.php?topic=6753.0

I don't see the need for your function F. People could just send to any agreed valid address which doesn't have a known public key associated with it such as 11111111111111111111BZbvjr. Spends to this address would generate magical crediting transaction on the "bettercoin" system.

A more difficult problem is managing the handover of mining power ie what to set the difficulty to on the new network and how to ramp it up as mining pools join. Also on the old network, how to prevent attacks when most miners have left but there are some normal users wanting to leave.

ByteCoin

The reason you need a function is because without it you'll need a database full of matching keys to figure out which bitcoin "sinkhole" address corresponds to the bettercoin address. This is unnecessary much overhead. Whereas a hash function can be computed in microseconds and has no storage requirements.

The weakness of the dying bitcoin network will be an issue which I haven't resolved. The maintainers of the bettercoin p2p network will have to decide how to treat the blockchain.

Neat idea, but the main problem I see is that the bettercoin protocol needs to specify what the exchange rate between bitcoin and bettercoin is (whether it's 1:1, or a function of time, or whatever). But their individual values should vary independently based on the popularity of each. I think it will be better to simply set up an exchange between bitcoins and bettercoins.

The exchange rate would just be 1:1 or perhaps 1:100 would be nice if bitcoin were @ .01 = $1. It doesn't really matter though as long as the rate is fixed.
Pages: [1]
  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!