I like this idea at first glance.
Choosing an arbitrary xorname for MD was a concern to me (eg data density attacks). Being able to use the content of AD to derive the xorname should be more secure. It also allows simpler caching of AD, whereas caching MD is very complex and challenging.
Having an initially blank field next_data_xor_name that can be updated just once (ie the append operation, which would not affect the original xorname) allows arbitrarily large appendable data sets, but comes with a cost of needing more lookups to fully download the data or reach the latest point in the chain. I think there are ways to simplify this though, eg via communications rather than storage, maybe some overlay network recording AD-LATEST-XORNAMES. I feel like there’s a strong parallel between bitcoin segregated witness and the ‘appendable’ part of AD. Navigating the ‘next_data’ direction of AD is an interesting problem.
This maybe has implications for safecoin history and privacy since the new owner must be appended rather than replaced. But with a suitable signature scheme privacy should be retained. Hard to imagine this would still permit free txs though.
AD also really challenges (and strengthens) the idea of volatile vs permanent data. Is SAFE used to ‘store data forever’ or is it used to ‘securely arrange meetings with other people and then transfer data p2p in a volatile way’? A bit of both I guess… I think AD progresses this concept in the right direction. A bit like how lightning network is used transfer the day-to-day data (volatile) then every so often the aggregate result is written to the ledger (permanent), where the bitcoin blockchain and lightning are acting as “a highly accessible and perfectly trustworthy robotic judge and conduct most of our business outside of the court room” source. MD feels like a pre-lightning-network bitcoin, AD like bitcoin + lightning-network because AD encourages volatile data transfer using efficient ‘off-chain’ ways.
Will we get to hear more details about how AD has been discussed within maidsafe?
Very cool. I know nothing of this technology, but having read the medium article posted by @dirvine it will be interesting to see if this particular drawback ends up being significant or trivial:
BLS signature verification is order of magnitude harder than ECDSA. Signature aggregation for the whole block with 1000 transactions still requires to compute 1000 pairing, so verifying one tiny signature in a block may take longer than verifying 1000 separate ECDSA signatures.