[bisq-contrib] Comment on Account Age Witness

[Manfred Karrer]

> On 2 Nov 2017, at 16:43, sqrrm <sqrrm1 at gmail.com> wrote:
> 
> I've looked through the account age code and feel I have a reasonable grasp of it now. The checks and non network stuff look reasonable and well contained.

Thanks for taking time!
> 
> I just have a few questions on the handling of unseen accounts.
> 
> 1. It looks like a new  AccountAgeWitness is created if none is found when a trade is initiated (AccountAgeWitnessService::getWitness()). ... After starting to ask this question i realize that's fine, even if there would somehow be a mismatch with the seednodes witness data. Also, there is no good reason there would be a mismatch.

The hash is the key which is derived from account data + seed + key. so there should not be any conflict. There might be several witness data for the same account data if the seed changes at a new Bisq setup. But that is not a problem (beside that the users starts with a fresh witness and low limits). To clean up old outdated witness data might be needed some day, but that I would postpone.
I think sha/ripemd160 collusion risks can be ignored.

> 
> 2. The request for data from seednodes doesn't really save data by specifying which witnesses are not needed if I understood it right. Each hash will be sent as an id for the unneeded witnesses, and that's the data - time. So maybe 8 bytes saved, unless that's eaten up by overhead.

Good spot. Initially there was more data in the witness but now with only hash + date where we use the  hash as key it is only 8 byte to safe and the overhead + performance costs are eating up the benefits. i will remove that.

> That shouldn't be a problem at this point but in the example of 1 million users, with say all of them already in the local storage, that's still more than 20MB in the exclude req on startup. I guess with witnesses shipped with Bisq then it would only need to specify which version it is to avoid sending all the data from before that version.

Good point. We should have only sent those keys which are not already shipped but that is a bit complicate as it would require to track the version and snapshot of the shipped data.
But as we remove the delta request completely that is solved anyway.
But might be a problem for the trade statistics some day. But that is another open issue. Current solution will have scaling problems at some point. Though we will still have some time to get there. There are some rough ideas (only send recent history and older history is shipped anyway or will get loaded only on demand) but lets postpone that once we get closer to the problem.

> 
> 3. Is there a need to have account age check done by buyers of the sellers account? I'm not very well versed in scams so it might well be that there is a need for that too.

True the buyer is the one who could do a chargeback so yes the sellers check is not really that important. I would prefer to keep it in still, maybe there are some cases which we missed and any abuse would cause problems for the peer earlier. The check has not much costs as far I am aware. The sig check is prob. the most costly operation but also that is in the very low ms range.

Br,
Manfred

> 
> Cheers
> 
> 
> _______________________________________________
> bisq-contrib mailing list
> bisq-contrib at lists.bisq.network
> https://lists.bisq.network/listinfo/bisq-contrib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.bisq.network/pipermail/bisq-contrib/attachments/20171102/cff02bf4/attachment.sig>