Unfortunately, both described schemes fail the same way as
'require TXOs to be consolidated by the owner', by the fact that with
muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in
[1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban
musig for the bonds' is
В Mon, 5 Aug 2019 20:04:26 +0100
Chris Belcher wrote:
> So what's needed is a way to make renting out TXOs impossible or very
> difficult.
You can make renting the TXOs risky for the attacker. Make it so that
the entity that rented out the TXO can revoke the participation of said
TXO in the
On 8/6/19 10:27 PM, Chris Belcher via bitcoin-dev wrote:
> I think this is absolutely wrong, because sybil attackers give up some
> fee income. Here is a worked example:
>
> Let's say the sybil attacker is operating the top 5 most valuable maker
> bots. If this attacker has X coins they would
Hi,
I'm working as (software) test specialist and run private a full bitcoin node
(based upon Raspberry Pi 4).
I've been trying to figure out the tests performed during
installation/upgrade/compilation of the software for the node.
Is there any overview on what's the (common) test approach, or
On 06/08/2019 02:51, Leo Wandersleb via bitcoin-dev wrote:
> On 8/6/19 7:04 AM, Chris Belcher via bitcoin-dev wrote:
>> However, there _is_ a cost to being a sybil attacker. If we define
>> honest makers as entities who run just one maker bot, and dishonest
>> makers as entities who run multiple
