<p>Yes, I am just not so sure if we should combine too closely together both proposals (delayed payout) as that would let inherit that proposal the properties we have set in the other.<br>
I mean if we make the signature after the 30 days account age is reached then the signature will be considered valid if 30 days have passed. If we want to change that 30 days delay we automatically would change the signature handling as well. Also if the scammer has waited 30 day without using the account he would not have any delay and the trusted peer would sign directly.</p>
<p>If we keep it separate we are more flexible. E.g. If it is signed at confirm payment received we know the trader has used that account but we don't know it it might be chargebacked. So we treat such signatures less trustworthy. Only after a certain time (e.g. 2 months) we consider it safe. If a chargeback happens in the meantime it will get escalated anyway and the scammers account get banned. That banning is a centralized element but as its only exceptionally used I think its not a problem. We want to make the system so that scammers don't use it in the first place as they have no chance to succeed so if the meachnism for detecting and banning is fully decentralized or not is not that relevant IMO.</p>
<p>Also keeping all those protection tools separate will make it easier to combine it. Some future ideas like the certificacte or BSQ bonding might get added and they all in sum create a trust score. E.g. A new user who is willing to lock up 10000 BSQ can be considered trustworthy even if his signature is just 1 day old. If we would not publish the signature before 30 days is over that information that he has traded with a trusted peer and used his account would not visible. But as it is valuable information we should make it visible and leave the interpretation to another layer.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/78#issuecomment-485592272">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNTY65NEPN5G6OCMVKTPRZF5BANCNFSM4HHTGH4Q">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNTOXUA5S7QKJB4BGDTPRZF5BANCNFSM4HHTGH4Q.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/proposals","title":"bisq-network/proposals","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/proposals"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ManfredKarrer in #78: Yes, I am just not so sure if we should combine too closely together both proposals (delayed payout) as that would let inherit that proposal the properties we have set in the other.\r\nI mean if we make the signature after the 30 days account age is reached then the signature will be considered valid if 30 days have passed. If we want to change that 30 days delay we automatically would change the signature handling as well. Also if the scammer has waited 30 day without using the account he would not have any delay and the trusted peer would sign directly. \r\n\r\nIf we keep it separate we are more flexible. E.g. If it is signed at confirm payment received we know the trader has used that account but we don't know it it might be chargebacked. So we treat such signatures less trustworthy. Only after a certain time (e.g. 2 months) we consider it safe. If a chargeback happens in the meantime it will get escalated anyway and the scammers account get banned. That banning is a centralized element but as its only exceptionally used I think its not a problem. We want to make the system so that scammers don't use it in the first place as they have no chance to succeed so if the meachnism for detecting and banning is fully decentralized or not is not that relevant IMO.\r\n\r\nAlso keeping all those protection tools separate will make it easier to combine it. Some future ideas like the certificacte or BSQ bonding might get added and they all in sum create a trust score. E.g. A new user who is willing to lock up 10000 BSQ can be considered trustworthy even if his signature is just 1 day old. If we would not publish the signature before 30 days is over that information that he has traded with a trusted peer and used his account would not visible. But as it is valuable information we should make it visible and leave the interpretation to another layer. "}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/proposals/issues/78#issuecomment-485592272"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/78#issuecomment-485592272",
"url": "https://github.com/bisq-network/proposals/issues/78#issuecomment-485592272",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>