Author

Topic: Should "long Namecoins" cost the same as short ones? (Read 1462 times)

legendary
Activity: 1358
Merit: 1003
Ron Gross
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.
legendary
Activity: 1358
Merit: 1003
Ron Gross
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.
legendary
Activity: 1372
Merit: 1002
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.
sr. member
Activity: 369
Merit: 250
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
hero member
Activity: 518
Merit: 500
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
legendary
Activity: 1358
Merit: 1003
Ron Gross
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.
Jump to: