• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

short address (same as domains, dns)

P

poiuty

Active member
On master node we can be made short addresses DNS service.
Register short address -> reg_address market.drk
Register for a year. The cost of registration N DRK.

Profit for registration is divided between all the master nodes.
When someone wants to transfer coins -> darkcoind sendaddress market.drk 100

Wallet makes a request to the master node N.
Know the real address. If N cases it is the same - send coins.

https://github.com/darkcoin/darkcoin/issues/117
 
poiuty said:
On master node we can be made short addresses DNS service.
Register short address -> reg_address market.drk
Register for a year. The cost of registration N DRK.

Profit for registration is divided between all the master nodes.
When someone wants to transfer coins -> darkcoind sendaddress market.drk 100

Wallet makes a request to the master node N.
Know the real address. If N cases it is the same - send coins.

https://github.com/darkcoin/darkcoin/issues/117
Click to expand...
I used Google Translate to read your full description in Russian. Good idea but I think short names also have limitation and problems, like spelling errors and such. For example,
«Пожалуйста, пополните ваш счет shop.dkr» is different than
sendtoaddress shop.drk 10
Click to expand...
 
If the master node will say that this address is not registered. Wallet displays an error.

Store register address -> shop.drk
Also, store can create a lot of "sub address", for example -> client-1.shop.drk
To pay for the store makes a unique address to each client.

Friendly when -> "send coins to client-1.shop.drk"
Unfriendly -> "send coins to JGN3n435y4hgr...."

Or another example.
- Hello! To what address do I send you the money?
- One moment, I'll tell...
- Big J, small x, 1, 7...
 
When wrong address. We get this message.
Code: 
darkcoind sendtoaddress xxx 0.001
error: {"code":-5,"message":"Invalid Darkcoin address"}
So, in this moment we can get real address from masternodes.
And change xxx to real address.
Code: 
Value sendtoaddress(const Array& params, bool fHelp)
{
    if (fHelp || params.size() < 2 || params.size() > 4)
        throw runtime_error(
            "sendtoaddress \"darkcoinaddress\" amount ( \"comment\" \"comment-to\" )\n"
            "\nSent an amount to a given address. The amount is a real and is rounded to the nearest 0.00000001\n"
            + HelpRequiringPassphrase() +
            "\nArguments:\n"
            "1. \"darkcoinaddress\"  (string, required) The darkcoin address to send to.\n"
            "2. \"amount\"      (numeric, required) The amount in btc to send. eg 0.1\n"
            "3. \"comment\"     (string, optional) A comment used to store what the transaction is for. \n"
            "                             This is not part of the transaction, just kept in your wallet.\n"
            "4. \"comment-to\"  (string, optional) A comment to store the name of the person or organization \n"
            "                             to which you're sending the transaction. This is not part of the \n"
            "                             transaction, just kept in your wallet.\n"
            "\nResult:\n"
            "\"transactionid\"  (string) The transaction id.\n"
            "\nExamples:\n"
            + HelpExampleCli("sendtoaddress", "\"XwnLY9Tf7Zsef8gMGL2fhWA9ZmMjt4KPwg\" 0.1")
            + HelpExampleCli("sendtoaddress", "\"XwnLY9Tf7Zsef8gMGL2fhWA9ZmMjt4KPwg\" 0.1 \"donation\" \"seans outpost\"")
            + HelpExampleRpc("sendtoaddress", "\"XwnLY9Tf7Zsef8gMGL2fhWA9ZmMjt4KPwg\", 0.1, \"donation\", \"seans outpost\"")
        );

    CBitcoinAddress address(params[0].get_str());
    if (!address.IsValid())
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Invalid Darkcoin address");

    // Amount
    int64_t nAmount = AmountFromValue(params[1]);

    // Wallet comments
    CWalletTx wtx;
    if (params.size() > 2 && params[2].type() != null_type && !params[2].get_str().empty())
        wtx.mapValue["comment"] = params[2].get_str();
    if (params.size() > 3 && params[3].type() != null_type && !params[3].get_str().empty())
        wtx.mapValue["to"]      = params[3].get_str();

    EnsureWalletIsUnlocked();

    string strError = pwalletMain->SendMoneyToDestination(address.Get(), nAmount, wtx);
    if (strError != "")
        throw JSONRPCError(RPC_WALLET_ERROR, strError);

    return wtx.GetHash().GetHex();
}
But I dont know, how I can save real address on masternodes.
 
Hi poiuty

Interesting idea, however I see quite few problems here:
1. Changing standard bitcoin api that way is not a good idea imo, i would suggest to some new rpc command for this
2. Data storing solution (safety, versioning etc) could be quite easy if you stay smth like peers.dat Is it a good solution? I doubt because storing a separate unlinked data on each masternode and hope that 90 of 100 are honest is a weak point imo. In IX for "no consensus" situations there is a fallback to original mining confirmations and all is good, no risk for loosing your money, and there is no such mechanism here so that risk (though it's rare) is still there. There are some advanced solutions like namecoin https://wiki.namecoin.info/index.php?title=Domain_Name_Specification but that's far away from our closest goals. There is also dht/torrent-like system of what I can think of as a good solution but again that's not what we can afford to implement for non-main features imo.
3. Asking masternodes and getting result from them is asyncronos so you can't just send RPc request and get response from 100 masternodes in a reasonable time. That also could open new DDoS vectors. Most likely this should be periodically synced information just like it's for masternode list now. But if this feature go to production scale you will have list that is way bigger than 2-3K records for root addresses + tons of subaddresses + cheap spam to this list at cost of few $ per year and you end up with huge traffic/sync time for (unnecessary for most users?) functionality which will take more resources than core functions. That's not good. And again dht could be the answer but... I already stated above.
4. How to share payments among masternodes? Where it goes at the first place? You can't accumulate it and then send to everyone so you'll need to pay to some right when you execute rpc command. Let's say you pay top 10 (20?) with max rank on this blockheight. This txes are quite rare (1 per address per year) i.e it's not like mixing rewards on continious regular base, it goes to some lucky ones but everyone is here to host. You can choose another approach and introduce another list however just like masternode list. But this can be easily tricked without proper solving such consensus issue.
5. What about squatters? Playing with letter substitution for popular addresses, hijacking of expired addresses etc - every DNS problem but now for money. What is good in bitcoin addresses is that they are easily verifiable by software - switching lettters and typos make invalid and they never expire (because they are just result of some math that is done against your public key).

All of the above doesn't mean however that this kind of feature will never be implemented - if there will be huge demand for it there will be a solution one way or another. But amount of problems to be solved is fairly large, not every piece of it is clear even in principal, additional gain for masternode owners is tiny and potentially unfair. So priority for implementing this is quite low at this point of time imo.

No offence :smile:
 
You must log in or register to reply here.
Back
Top