|
Title: Should "long Namecoins" cost the same as short ones? Post by: ripper234 on November 22, 2011, 08:15:19 AM I'm thinking about building a distributed GLBSE (https://bitcointalk.org/index.php?topic=52494.0) (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. Title: Re: Should "long Namecoins" cost the same as short ones? Post by: bulanula on November 24, 2011, 01:16:06 PM I'm thinking about building a distributed GLBSE (https://bitcointalk.org/index.php?topic=52494.0) (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 ;D Title: Re: Should "long Namecoins" cost the same as short ones? Post by: MaxSan on November 24, 2011, 02:33:22 PM 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 Title: Re: Should "long Namecoins" cost the same as short ones? Post by: jtimon on November 24, 2011, 02:53:50 PM 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. Title: Re: Should "long Namecoins" cost the same as short ones? Post by: ripper234 on November 24, 2011, 09:49:52 PM 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. Title: Re: Should "long Namecoins" cost the same as short ones? Post by: ripper234 on November 24, 2011, 09:53:03 PM 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 (http://bitcoin.stackexchange.com/questions/2039/is-a-distributed-version-of-glbse-possible-how-would-you-design-it) including perhaps Smart Property (https://en.bitcoin.it/wiki/Smart_Property). |