One of the great advantages of safecoin is it’s anonymity. It seems very much as if it will be digital cash in a very real sense.
While a receipt for physical cash can easily be managed face-to-face with cash, putting it in an envelope and sending it requires a high degree of trust between parties. With bitcoin and the like, there is the blockchain. With other electronic currency transactions, there are counterparties such as banks and credit card companies to show proof of receipt.
I haven’t seen anything so far that deals with this aspect of safecoin transactions–i.e., verification or proof of transmission and receipt between the parties involved that can provide validation and audit, even if on a voluntary basis only, like writing a cash receipt. It seems that this is a vital aspect for safecoin to be useful as a currency beyond purchase network resources, etc.
@dirvine (or anyone else who actually knows): How is this aspect of economic action with safecoin dealt with?
If we develop a “Gift Code” APP. Then maybe we can include a proof of receipt feature. Here’s how I imagine it working.
Standard Gift Code Process
Alfred sends a “gift code” representing X Safecoins to Becky.
Becky logs into the SAFE Network and redeems the “gift code”.
If no one redeems the “gift code” in X days, the Safecoins are returned back to the original owner.
Because of condition #3, the APP (a 3rd party delivery system) has to know if the Safecoins were redeemed or not. It’s like signing for a package to accept delivery from UPS.
The APP knows Alfred sent the gift code (Safecoins). And it will know “who” redeemed it, Becky or someone else. The redeemer has to log into the SAFE Network with a wallet ID to receive the Safecoins. All the APP has to do is record the ID of the redeemer, giving us a proof of receipt.
Proof of Receipt
I would make it a private record, viewable only by the sender and receiver. Alfred opens up the “Gift Code” APP to check if it has been redeemed. If it has, then it should show the ID of who redeemed the Safecoins.
Q: Doesn’t this mean Safecoin’s history can be tracked?
A: Yes and No. It only tracks Safecoin transferred via “Gift Code.” If the Sender does not require proof of receipt, they should send Safecoin directly.
I’m sure there are better ways to do this. Hopefully someone will add it to this thread.
Open Transactions will use so called voting pools for lightning fast transaction with BTC or other crypto’s. Trades can be done in a 10th of a second at very low cost. I know Ethereum will cooperate with OT. Maybe Maidsafe can do the same. There’s no system in crypto which will be good at everything. Safecoins are great inside the Safenetwork, outside of it, just like said above you like a proof of receipt.
This is from the whitepaper, is that what you’re looking for (the Third Party Transaction Validator)? It is essentially a notification to the upper layer API, which I imagine can be used by for example a web store to validate the transaction. Since it can read the pending and updated transactions, I imagine it can also make a copy that can serve as a receipt. They are after all signed with the sender’s private key (and I think by the transaction managers?).
Transactions will generate a receipt automatically, from what I read a few months back. Essentially, you can prove that you were involved in the transaction, but it isn’t broadcast.
If you need to prove that you sent or received a payment, you would provide the stored receipt to the third party.
Naturally, the receipt will be unique and would provide full certainty that the transaction occurred.
Careful - this is credit clearing, not settlement. Until the Bitcoin transaction has been committed to the blockchain, you are trusting other people/systems.
OT sounds great, but like ripple, no asset is being transferred any faster - credit is bridging the gap.
Safecoin on the other hand, provides almost immediate settlement, anywhere in the world. This will be new and unique to Safecoin and will be very powerful. No trusted parties needed for instant asset transfer.
Yup, you have to trust the OT servers (which I think will be more secure than the BTC blockchain). But it’s not one server, it’s like a number of servers. Anybody can run a server if they like, each transaction is agreed on by all the servers (or say 95%). So, let’s say the Ethereum people run a server, the Maidsafe team, the OT people themselves of course, and maybe Poloniex, and a number of other exchanges. If I connect to one server, do some transactions, all transactions are signed by them alll. This happends all in a tenth of a second. So, when trading using voting pools you don’t have to wait for the blockchain. You just connect to the server run by the Maidsafe team, they can never steal any coins, the only thing they can do to hurt you is not take your transaction (and don’t make a little money because you went off to another server). So you connect to them, trade some BTC for Safecoin within a second, you (with your private key) sign the thing, the servers sign them and trades are done. Even if Mt. Gox comes back, uses OT and you trade with them they can never steal any of your coins because 95% of the server should sign. Trades are gonna be cheap like hell. probabaly over a 1000 times cheaper than Bitcoin using the blockchain. Again, that’s why I think no project can do it all on it’s own. Ethereum will probably be great for consensus about time, a blochchain etc. Maidsafe will be great to store stuff online, create websites without servers etc. OT might offer a decentralized group of serves you don’t have to trust where you can trade all coins safely using voting pools.
My understanding is that SAFEcoin can never leave the underlying mesh…a proof of receipt is merely the fact your balance went up I’d think?
OT and Blockchain utilize ‘Triple entry accounting’ to achieve ‘proof of receipt’ i.e the receipt is the transaction. This scheme has the potential to wipe out all forms of electronic fraud as we head towards becoming fully digital…a huge change in society via ‘transparency’ and ‘accountability’
Triple Entry is the perfect mechanisms to keep all players in check …but I don’t see any way, we as individuals can avoid being totally transparent and accountable either, if we interact with Public and Corporate systems. This has to fundamentally change human behavior as we get the ‘observer effect’ and other such effects through total transparency of our movements and interactions.
But then we have SAFE…it’s like the feeling you get when arriving home from a hard days work…a private place. So I see two diametrically opposed systems operating within the wires and waves…and boy, will we need it, I’d think we’d go crazy otherwise…there’s SAFEcoin value right there.
Triple Entry Accounting
Financial contracts operate on the same fundamental principles as the contract of a lawnmower loan described above. A stock certificate is a representation of a company’s agreement to give a share of profits and decision-making authority to a shareholder – a contract. A bank account balance statement is a representation of a bank’s agreement with a depositor to redeem a certain amount of currency on demand – another contract. A check expresses an agreement between a depositor and a payee that the payee is entitled to a specified portion of the bank’s obligation to the depositor – also a contract. Financial contracts gain the same benefits of tangible representation as other contracts, and the tangible representations of these contracts are called financial instruments.
Triple entry accounting is a concept developed by a number of cryptographers. Triple entry account is a method of representing financial instruments in digital form, using cryptographic signatures. The “triple” portion of the name comes from how it implements a two-party contract: the instrument is signed by both parties involved, plus a witness. Another name for triple entry accounting is “triple signed receipts”.
Triple entry accounting is the cryptographic equivalent of having every contract notarized. Triple entry accounting is superior to other ways of creating financial instruments because cryptographic signatures can not be forged, and because the additional security of a notary can be provided at a low cost. Additionally, any system that implements triple entry accounting can also implement smart contracts – contracts which execute software to automate some or all of the terms.
Not sure where you got the rebate idea. Maybe I’m using the wrong terminology (redeem) to describe things. I agree, scripting language would be very helpful.
This is a follow-up explanation. I’m sure it’s already understood.
The “Gift Code” is more like a check. I brought it up because it would aid network adoption and can be used as proof of receipt, if we proxy Safecoins outside the Network.
Assume the SAFE Network is a special internet bank. However, members can only transact with each other. So how does one send Safecoin outside of the SAFE Network to non-members?
Example Scenario
Bob wants to give/donate Safecoins to Larry. But Larry doesn’t have an account with the SAFE Network. They’re both busy, and don’t have time to wait for Larry to set up an account.
Luckily, Larry has an email address. So Bob creates a gift code for X Safecoins via his smart phone, and emails it to Larry. Or he can write it down on a piece of paper and physically give it to Larry. Just like a check!
Hey that’s not a bad idea! Safecoin paper checks. The paper check has the SAFE Network download address and a space to fill in the code and amount. Brilliant!
Larry goes home, checks his email, and sees the gift code with a link to setup an account. He can take his time, making sure he has a login and password he can remember. Then he cashes the gift code.
I actually think the Safecoin paper check is more secure because it prevents: email interception, and phishing scams. Also, face to face transactions are timeless!
This is actually pretty neat, and if that’s all that’s available it will make use of SafeCoin interesting. It will make safecoin very useful in applications which are (a) automatic and (b) between trusted peers. It will make it more difficult in other uses, such as anywhere you need to prove you made a payment for which you did not receive the expected exchange.
@Traktion says above “Transactions will generate a receipt automatically, from what I read a few months back. Essentially, you can prove that you were involved in the transaction, but it isn’t broadcast.”
This would also be interesting. I’m just trying to get a grip on how this is likely to work. I can see advantages and disadvantages either way.
I can see some advantage to having the OPTION of somehow linking an additional communication cryptographically to a specific transaction (or at least reference the transaction precisely) to indicate not only that a payment has been made but what it is for. This could allow one not only prove that a transaction was made, but to keep some accounting of where certain money came from. The difference would be that this would be private, such as giving a hand-written receipt for a cash exchange, by option not by default.
Of course, this could also be accomplished clearing of exchanges by a trusted third party or multisig, which would then provide the transcript of the exchange, but that would be a bit burdensome for general use.
I suspect you could do something like this easily in maidsafe. You could create a contract definition document which includes the receipt along with digitally signed receipts from both parties. The hash of this document would both be the file identifier (read: unique to document) and could be referenced by both (or additional) parties.
This would create an immutable record of the contract and associated payment, until all references to the file are removed (ie everyone who knows of the file, marks it as deleted).
There maybe better ways, but something simple sounds trivial.
EDIT: In fact, if you can add a note on the transaction (which is included in the receipt), you could just link the file identifier (hash) of the contract document to the receipt. This would bind the document and the transaction together, irreversibly.
It may be uber trustworthy, but until the transaction appears on the blockchain, the Bitcoin transfer has yet to occur - a trade of a promise to transfer has occurred instead.
In most cases the difference may not be important, but the two transfers are not equivalent. If a Bitcoin wallet gets hacked and the subsequent promised Bitcoin transaction can no longer occur, the difference will feel very acute.
