Bitcoin Forum
December 09, 2016, 10:04:09 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Should "long Namecoins" cost the same as short ones?  (Read 1211 times)
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
November 22, 2011, 08:15:19 AM
 #1

I'm thinking about building a distributed GLBSE (if enough developers join in - I don't have the time to do this alone). I think an implementation could be built on top of Bitcoin & Namecoin, instead of a separate blockchain.

So, imagine this: To register a new asset, you buy a long Namecoin address that is the signature on a contract (published into the bitcoin blockchain itself as a text message). You might want to have 1,000,000 different stocks of this asset, that will each require a Namecoin address in order to be uniquely transferable (let's not worry about stock splits for the moment).

Currently, this might be very expensive, since each Namecoin registration costs a given amount of money, and 1M of them will cost a lot.

Is there a feasible way to change the Namecoin protocol such that long addresses/names will cost less to register?
This seems fair to me, since there a lot more long addresses, so the "inherent value" of a long address is smaller than a short one (compare the "abc.com" domain to "21z980347sd9fhase43wsadf.com")

Would anyone even consider making such a change in Namecoin? Would this cause an influx of spam in the Namecoin blockchain? There would be a minimal fee for an address, of course, it would just be lower than the current fee (which is what btw?)

The reason I think this should be implemented on top of current chains is that they already have a large hash rate, and any new chain we start will be prone to 51% attacks until merged mining is introduced ... which won't be for some time. If this can be reasonably implemented on top of existing chains, we benefit from all the existing hash power from day 1.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481277849
Hero Member
*
Offline Offline

Posts: 1481277849

View Profile Personal Message (Offline)

Ignore
1481277849
Reply with quote  #2

1481277849
Report to moderator
1481277849
Hero Member
*
Offline Offline

Posts: 1481277849

View Profile Personal Message (Offline)

Ignore
1481277849
Reply with quote  #2

1481277849
Report to moderator
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
November 24, 2011, 01:16:06 PM
 #2

I'm thinking about building a distributed GLBSE (if enough developers join in - I don't have the time to do this alone). I think an implementation could be built on top of Bitcoin & Namecoin, instead of a separate blockchain.

So, imagine this: To register a new asset, you buy a long Namecoin address that is the signature on a contract (published into the bitcoin blockchain itself as a text message). You might want to have 1,000,000 different stocks of this asset, that will each require a Namecoin address in order to be uniquely transferable (let's not worry about stock splits for the moment).

Currently, this might be very expensive, since each Namecoin registration costs a given amount of money, and 1M of them will cost a lot.

Is there a feasible way to change the Namecoin protocol such that long addresses/names will cost less to register?
This seems fair to me, since there a lot more long addresses, so the "inherent value" of a long address is smaller than a short one (compare the "abc.com" domain to "21z980347sd9fhase43wsadf.com")

Would anyone even consider making such a change in Namecoin? Would this cause an influx of spam in the Namecoin blockchain? There would be a minimal fee for an address, of course, it would just be lower than the current fee (which is what btw?)

The reason I think this should be implemented on top of current chains is that they already have a large hash rate, and any new chain we start will be prone to 51% attacks until merged mining is introduced ... which won't be for some time. If this can be reasonably implemented on top of existing chains, we benefit from all the existing hash power from day 1.

Not really. Try ScamCoin with cop nodes Grin
MaxSan
Sr. Member
****
Offline Offline

Activity: 368


View Profile
November 24, 2011, 02:33:22 PM
 #3

Below seem to be the full list of namespaces currently. As far as im aware its not so difficult to implement extra namespaces for such a thing and have registration be very low. I think the main issue would be having a million registrations per company. Surely it would quickly blow way out of proportion?

Namespaces

prefix    protocol    status    notes
d/    Domain names    active    .bit TLD
dd/ or s/    Domain names    draft    non-resolvable Domain data
p/    Personal Namespace    draft    
m/    Messaging System    draft    
x/          alternate domain?
i/    Domain names    idea    I2P
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
November 24, 2011, 02:53:50 PM
 #4

The reason I think this should be implemented on top of current chains is that they already have a large hash rate, and any new chain we start will be prone to 51% attacks until merged mining is introduced ... which won't be for some time. If this can be reasonably implemented on top of existing chains, we benefit from all the existing hash power from day 1.

If you start and new chain, you can have merged mining from day one. You just have to wait for pools to merge mine you.

But I think I've not understood your proposal.
The contract is in bitcoin but the shares are in namecoin?
Why do you need namecoin to represent the shares?

I feel I'm missing something.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
November 24, 2011, 09:49:52 PM
 #5

Below seem to be the full list of namespaces currently. As far as im aware its not so difficult to implement extra namespaces for such a thing and have registration be very low. I think the main issue would be having a million registrations per company. Surely it would quickly blow way out of proportion?

Cool, I was't aware Namcoin had namespaces.
But I'm not sure they would be open to charging differently per namespace. And I can't find a way around the spam argument.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
November 24, 2011, 09:53:03 PM
 #6

The reason I think this should be implemented on top of current chains is that they already have a large hash rate, and any new chain we start will be prone to 51% attacks until merged mining is introduced ... which won't be for some time. If this can be reasonably implemented on top of existing chains, we benefit from all the existing hash power from day 1.

If you start and new chain, you can have merged mining from day one. You just have to wait for pools to merge mine you.

Hard to achieve mass adoption with a new chain (even merged), since a new chain will have zero value at inception. Only if it succeeds does it become profitable to mine it.

But I think I've not understood your proposal.
The contract is in bitcoin but the shares are in namecoin?
Why do you need namecoin to represent the shares?

I feel I'm missing something.

I thought about registering any assets by issuing a new Namecoin. But never mind that, I haven't worked out the details, it's just an idea, and there are better answers for this problem including perhaps Smart Property.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!