Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMø<div class="post">Still thinking this idea through...<br/><br/>The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.<br/><br/>If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:<br/>- the value<br/>- the association of inpoints and outpoints in one transaction<br/><br/>The network would track a bunch of independent outpoints.&nbsp; It doesn't know what transactions or amounts they belong to.&nbsp; A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent.&nbsp; The network keeps the outpoint and the first valid inpoint that proves it spent.&nbsp; The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.<br/><br/>I believe the clients would have to keep the entire history back to the original generated coins.&nbsp; Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend.&nbsp; Maybe the data transfer could be done as an e-mail attachment.<br/><br/>The fact that clients have to keep the entire history reduces the privacy benefit.&nbsp; Someone handling a lot of money still gets to see a lot of transaction history.&nbsp; The way it retrospectively fans out, they might end up seeing a majority of the history.&nbsp; Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.<br/></div> text/html