thanks. after reading anonymints back and forth with you guys i was under the impression that pruning the bc was questionable and he seems to think it can't be done. it way over my head but he does seem to know his stuff. to clarify he did say it's not possible right? i saw the bbr guy pruned or is pruning some stuff but anonymint claims it's not near enough, correct?
i've seen people talk about the transaction provability part several times but forget the specific phrase they used. i'll check into it and get back to you.
so if i send you some xmr for something and you say you did not get it is there a transaction hash on the bc i can point to and prove it?
thanks for your time.
Both
AnonyMint and I agree that pruning, in the Bitcoin sense of the term, is not possible with any of the CryptoNote currencies. That does not mean that other reductions in storage aren't possible, but there will always be a need to keep more data than with Bitcoin and its clones. Specifically, the utxoset *and* the key image set is required, and the key image set is unpruneable. The pruning that BBR does is to remove ring signature proofs, a purely linear pruning and one that I am hesitant about from a cryptographic soundness perspective.
You get a transaction ID for your transaction, most definitely. Here's a transaction of 335 XMR sent to my Monero address (49VNLa9K5ecJo13bwKYt5HCmA8GkgLwpyFjgGKG6qmp8dqoXww8TKPU2PJaLfAAtoZGgtHfJ1nYY8G2
YaewycB4f72yFT6u) on all 3 block explorers:
http://monerochain.info/tx/047c2c11632120f7cd1565c312f94f76135a45f0b2194bbe958826280878fc3dhttp://chainradar.com/xmr/transaction/047c2c11632120f7cd1565c312f94f76135a45f0b2194bbe958826280878fc3dhttps://minergate.com/blockchain/mro/transaction/047c2c11632120f7cd1565c312f94f76135a45f0b2194bbe958826280878fc3dAs you can see, there's no way to track where it came from, where it went to, or even ascertain the correct amount. However, the very act of being able to provide the transaction ID to me (coupled with me receiving it) is normally sufficient to prove a transaction, since only the sender and recipient will know the transaction ID and the amount.
Of course, this isn't the robust or cryptographically sound way of doing it, which is why we're adding tooling to allow someone to reveal the one-time key (which is different to the transaction ID) for their transaction, and the person (or persons) they send that key to can see the exactly details of their transaction on a blockchain explorer or similar. In other words, this functionality is inherent in the protocol and in each transaction, but we just have to give people the ability to both retrieve this information and for someone else to verify it.
great info man, thanks. the one-time key feature will solve the provability problem i've seen brought up but i still can't think of the damn technical name they were using
sounds like what bitshares x is doing with a secret key to prove transaction to a third party type escrow. the whole anon scene is very exciting!
only other real issues is the bloating and (visa level) scalability that anonymint always talks about. what are y'alls plans to fix that?