Feature proposal to include data when sending safecoin to another person

safecoin

#1

A simple feature that could add a lot of benefits.

That is to allow datafields to be included in each SAFEcoin that is sent to another ID.

Many coins now allow additional data to be included in a transaction. E.G. bitcoin. This idea is to allow use of the remaining space in a safecoin’s MD to be able to send details of the payment to the receiver.

The idea came when answering a query about what exchanges might need to do to accept SAFEcoins and trade them.

One method is for the exchange to have one ID per user and monitor each ID for received coin. Using this idea then the exchange could have one ID for receiving coin and the user uses a APP that allows the insertion of data to the safecoins being sent. So then when a person sends their coin to the exchange the user’s username for the exchange could be added to each coin being sent. This way the exchange monitors only one ID and simply credits the user specified in the safecoin data field.

How to implement it?

The send safecoin API would allow a supplied data block to be written into the safecoin’s MD before actually sending the safecoin.

Will coins be filled up with data?

No the API would delete any fields in the safecoin always to ensure anonymity and privacy of previous senders. If a person wanted to include the previous data then they would need to first read the safecoin’s MD contents and include that in the data block included in the API call.

Will the data block be optional?

Yes, it needs to be (see below). The current field(s) in the safecoin will be deleted always so no need to supply a blank data block

Will there be a cost?

YES, it will cost a put charge to place data within the safecoin when sending. While a simple sending of safecoin will remain free the addition of the data block is preformed prior to sending but as a single API call. If the users writes to the safecoin’s MD prior to sending it then it would be wiped.


#2

Alt perspective might be easier to understand… would it not be equally simple to send coin coupled to data?.. so, anything can carry a coin. That would keep the coin clean and simple to understand… and you could send coin with any message, rather than be perhaps limited in the size of message.


#3

I don’t think so since each safecoin is a MD object already. So no not anything can carry a coin.

If size is a problem then simply use the datamap (pointer) as the data block and this can then access data of any size.

The issue here is that the safecoin is already a data structure (MD) with a specific address and to try and make the coin any data structure then why could you not have 2^256 coins being created by people and then what use is the coin. (that is if I understood you correctly)

And the other issue is that once you can store any data then it can be pointers or data maps and you can have any size data beig sent.


#4

When you make bank transfers sometimes you are asked to send a reference in the notes. With block chain tech, endless random public-private key generation made sure you have a unique key to send crypto to your account. With safecoin a notes field as part of a wallet on a transaction might be a good idea.


#5

A reference allows, in addition, to use several accounts for the same payment and to accelerate, thanks to the parallelism of the network, the rapid transfer of large amounts.

In fact it would be interesting to create several Type-tags integrated into the safecoin, something like this:
.-Reference
.-Date
.-Issuer
.-Consignee
.-Beneficiary
.-Amount…


#6

Would they simply be fields of the MD.

And then we can make the data block into a multiple set of field-data


#7

Solid idea! Completely support it!


#8

I think that I will make myself a reminder for the future about this topic beacause it seems very relevant to work on when Safecoin will become more active in the development phase. Right now the focus seems to be very much on getting to alpha 3 and it feels like there is not much room for topics related to development that will follow a bit further in the future.