[bitcoin-dev] bitcoin-dev Digest, Vol 51, Issue 3

Steven Blinn blinnpr at gmail.com
Fri Aug 2 16:44:01 UTC 2019 

Emil,

Re: [Meta] bitcoin-dev moderation (Emil Engler)

Since my coding skills are in the infancy stage and I can't contribute much
in that area, at least not yet, I'm looking for other ways to get involved
and moderating the mailing list sounds like an ideal situation.  If you
need help in this area I'm more than happy to volunteer and pick up the
slack.

Steven

On Fri, Aug 2, 2019 at 8:50 AM <
bitcoin-dev-request at lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. [Meta] bitcoin-dev moderation (Emil Engler)
>    2. Re: Improving JoinMarket's resistance to sybil attacks using
>       fidelity bonds (Chris Belcher)
>    3. Re: Proposed Extensions to BIP 174 for Future Extensibility
>       (Dmitry Petukhov)
>    4. Re: [Meta] bitcoin-dev moderation (Bryan Bishop)
>    5. Re: Add a moving checkpoint to the Bitcoin protocol
>       (Ethan Heilman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 Aug 2019 21:47:40 +0200
> From: Emil Engler <me at emilengler.com>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] [Meta] bitcoin-dev moderation
> Message-ID: <53b75074-59ff-9890-419d-d5e6fcb44a7c at emilengler.com>
> Content-Type: text/plain; charset="utf-8"
>
> In the last #bitcoin-core-dev IRC meeting, the mailing list moderation
> was slightly discussed. It was decided to do this discussion mainly on
> this mailing list (which makes sense).
>
> The current situation is that the moderation is slow and takes around
> >24h for a E-Mail to be on the mailing list.
>
> Jonas Schnelli proposed: "I propose that we add more moderators to
> shorten the moderation lag which has been between >24h, thus makes
> debates cumbersome"
>
> Beside this I had the idea of people who already contributed n e-mails
> to the mailing list don't need an approval for any e-mail anymore (Where
> n is the number of previous e-mails). Does this exists already?
>
> Greetings,
> Emil Engler
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: pEpkey.asc
> Type: application/pgp-keys
> Size: 3147 bytes
> Desc: not available
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190801/a78795b7/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 Aug 2019 10:21:57 +0100
> From: Chris Belcher <belcher at riseup.net>
> To: Dmitry Petukhov <dp at simplexum.com>,
>         bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
>         attacks using fidelity bonds
> Message-ID: <ae32dcbb-c950-3b3f-22b9-d152d6b221cb at riseup.net>
> Content-Type: text/plain; charset=utf-8
>
> On 31/07/2019 16:50, Dmitry Petukhov wrote:
> > ? Tue, 30 Jul 2019 22:39:14 +0100
> > Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> > wrote:
> >
> >> This is where a sacrifice of V bitcoins creates a
> >> bond of value V^2. The formula provides a strong incentive for
> >> profit-motivated makers to use all their fidelity bond coins with just
> >> one maker, not spread them out over many makers.
> >
> > The attacker derives additional value from the use of
> > locked utxo - the deanonimyzation capabilities.
> >
> > An entity M can use all of its locked coins to run a maker, and then
> > earn value X. It will also incur some operational expenses in the course
> > of running the maker, so the profit will be less than X.
> >
> > If these locked coins are given to the attacker A as a package, an
> > attacker can derive a value of X+D where D is a value of increased
> > deanonymization capabilities for an attacker. Operational expenses
> > for an attacker are the same as before (without timelocked bonds),
> > because they need to operate a lot of makers either way.
> >
> > If M is profit-driven and non-ideological, it can rent out all of its
> > coins to A as a package, for the price X, and get the same value without
> > running a maker and dedicating any resources and time to it, not
> > incurring any operatinal expenses (thus having a bigger profit in the
> > end).
> >
> > Attacker A will run a maker with M's coins, get profit X, pay X to M,
> > get increased deanonymization capabilities.
> >
> > If renting out of utxo is done in a way that the owner always gets X
> > after the lock expires, the operation will be riskless for the owner.
> > The attacker will need to lock amount X along with owner's coins, but
> > hopefully makes X back by running a maker operation.
> >
> > The price for renting out the coins will be determined on the size of
> > the 'coin package', so it will not be feasible for the owners of the
> > coins to rent them out separately.
> >
> > An attacker can even rent coins from several entities and combine them
> > to create a more 'powerful' maker. If I understand correctly, such
> > 'powerful' maker can have bigger profit than two less 'powerful'
> > makers. It seems like a centralization risk to me.
> >
>
> There's a few different issues here.
>
> Yes TXO fidelity bonds can be rented out, but that doesn't make a sybil
> attack cheaper. The aim of the fidelity bond scheme is to require makers
> to sacrifice value, renting out their fidelity bond coins doesn't avoid
> that sacrifice because the sacrifice is the paid rent. Because of the
> maths and market forces the rent paid by the attacker should be about
> the same as the cost of just buying the bitcoins and locking them.
>
> Centralization and decentralization are not ends in themselves, the main
> aim in JoinMarket is to improve privacy while keeping the other
> properties of bitcoin (e.g. censorship resistance). A single maker can
> never deanonoymize coinjoins no matter how valuable their bond is,
> because takers always choose multiple makers, and all of them need to be
> controlled by the sybil attacker for the attack to succeed. If a sybil
> attacker splits up their fidelity bonds (rented or not) amongst multiple
> maker bots then they reduce the value of their bonds because of the V^2
> term.
>
> Rented TXOs does destroy the effect of "A long-term holder probably
> won't want to attack a system like JoinMarket which makes his own
> investment coins more private and more fungible". However this is not
> the main effect which would protect JoinMarket's privacy. The main
> effect is the cost which for real-life numbers would be about 45-120
> bitcoin sent to burner outputs.
>
> Perhaps then rented TXOs is an argument against using coin age as a way
> to create fidelity bonds. Hodlers would be far less likely to rent out
> their coins if they have to specifically move them to a special
> time-locked address. Another point is that for privacy reasons creators
> of fidelity bonds should mix their coins before and after using them,
> because those TXOs are revealed to the world. So it's likely that
> fidelity bonds creators will need to install and run JoinMarket anyway.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 Aug 2019 14:18:36 +0500
> From: Dmitry Petukhov <dp at simplexum.com>
> To: Andrew Chow <achow101-lists at achow101.com>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
>         Extensibility
> Message-ID: <20190802141836.15771ad6 at simplexum.com>
> Content-Type: text/plain; charset=UTF-8
>
> ? Thu, 01 Aug 2019 19:01:06 +0000
> Andrew Chow <achow101-lists at achow101.com> wrote:
>
> > I spoke to some people OOB and they said that they didn't really like
> > the idea of having a prefix string (partially because they've already
> > implemented some proprietary types by simply squatting on unused
> > types). Matching the prefix string adds additional complexity to the
> > parser code.
>
> I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
> would like to note that for those who do not want to deal with
> additional complexity of handling a prefixed string, they can simply
> not use it at all. Since this is a private construction, and their
> private format specifies 'no prefix', they can just ignore everything
> that does not start with "{0xFC}|{0x00}", thus any further complexity
> regarding the prefix is also ignored. The only added complexity is one
> condition check: second_byte_of_the_key != 0
>
> My other argument for conflict-avoidance prefix as a first thing after
> 0xFC is that the set of future users of PSBT and private types is
> most likely much larger than the current set of those who already
> implemented proprietary types on their own, and thus the overall benefit
> for the whole industry will likely be bigger when 'i do not want
> conflict avoidance' decision have to be explicit, by setting the prefix
> to 0x00, and the set of possible conflicting types are limited only to
> those entities that made this explicit decision.
>
> Regarding the 'squatted' types, it seems to me that this only matters
> in the discussed context if they squatted on 0xFC type in particular.
> In other cases, they will need to implement changes anyway, to be
> compatible with the BIP. Maybe they could consider that one additional
> condition check is a small burden, and maybe they can tolerate that,
> for the benefit of reducing possibility of interoperability problems
> between other future PSBT/private types implementors.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 2 Aug 2019 06:43:27 -0500
> From: Bryan Bishop <kanzure at gmail.com>
> To: Emil Engler <me at emilengler.com>,    Bitcoin Protocol Discussion
>         <bitcoin-dev at lists.linuxfoundation.org>,        Bryan Bishop
>         <kanzure at gmail.com>
> Subject: Re: [bitcoin-dev] [Meta] bitcoin-dev moderation
> Message-ID:
>         <CABaSBay1w6ncJX2wVKWotp-FkzkDH4Nkve=
> QBz90S1G_-SzpZA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The current situation is that the moderation is slow and takes around
> > >24h for a E-Mail to be on the mailing list
>
> It really shouldn't be 24 hours. Our strategy was to have a few
> moderators in different timezones to cover sleep shifts or other
> disruptions of service. Evidently this has not been adequate.
>
> > Jonas Schnelli proposed: "I propose that we add more moderators to
> > shorten the moderation lag which has been between >24h, thus makes
> > debates cumbersome"
>
> Makes sense. I'll go find a few people.
>
> > Beside this I had the idea of people who already contributed n e-mails
> > to the mailing list don't need an approval for any e-mail anymore (Where
> > n is the number of previous e-mails). Does this exists already?
>
> There is an active software vulnerability which requires moderation to
> be enabled. This version of mailman is unmaintained, and Linux
> Foundation is migrating away from or abandoning the email protocol so
> they are less willing to do backend infrastructure work. This
> manifests in other ways, like downtime, but also weird situations like
> missing emails that never hit the moderation queue. I get pings from
> different people about two times a year where they report an email
> that they think I missed, but in fact it never hit the moderation
> queue at all. Email clearly isn't the greatest protocol.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 2 Aug 2019 08:19:03 -0400
> From: Ethan Heilman <eth3rs at gmail.com>
> To: "Kenshiro []" <tensiam at hotmail.com>,        Bitcoin Dev
>         <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
>         protocol
> Message-ID:
>         <CAEM=
> y+UCdW2__nmQhWuL2FYvL6WKdBsF31WDFZUSdXPvgM2bvg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Attack 1:
> I partition (i.e. eclipse) a bunch of nodes from the network this partition
> contains no mining power . I then mine 145 blocks for this partition. I
> don't even need 51% of the mining power because I'm not competing with any
> other miners. Under this rule this partition will hardfork from the network
> permanently. Under current rules this partition will be able to rejoin the
> network as the least weight chain will be orphaned.
>
> Attack 2:
> I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I
> feed it 145 blocks which fork off from the consensus chain. I have 24+24
> hours to mine these 145 blocks so I should be able to do this with 25% of
> the current hash rate at the time the node went offline. Under your rule
> each of these offline-->online nodes I attack this way will hardfork
> themselves from the rest of the network.
>
> I believe a moving-checkpoint rule as describe above would make Bitcoin
> more vulnerable to 51% attacks.
>
> A safer rule would be if a node detects a fork with both sides of the split
> having  length > 144 blocks, it halts and requests user intervention to
> determine which chain to follow.  I don't think 144 blocks is a great
> number to use here as 24 hours is very short. I suspect you could improve
> the security of the rule by making the number of blocks a fork most reach
> to halt the network proportional to the difference in time between the
> timestamp in the block prior to the fork and the current time. I am **NOT**
> proposing Bitcoin adopt such a rule.
>
> NXT has a fundamentally different security model as it uses Proof-of-stake
> rather than Proof-of-Work.
>
> On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > P.S.: To be clearer, in this example I set an N value of 144 blocks,
> which
> > is approximately 24 hours.
> >
> > ------------------------------
> > *From:* Kenshiro [] <tensiam at hotmail.com>
> > *Sent:* Wednesday, July 31, 2019 16:40
> > *To:* Alistair Mann <al at pectw.net>; Bitcoin Protocol Discussion <
> > bitcoin-dev at lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > >>> How would a (potentially, state-sponsored) netsplit lasting longer
> > than N be
> > handled?
> >
> > It would be detected by the community much before reaching the reorg
> limit
> > of N blocks (it's 24 hours) so nodes could stop until the netsplit is
> > fixed.
> >
> > In the extreme case no one notice the network split during more than N
> > blocks (24 hours) and there are 2 permanent forks longer than N, nodes
> > from one branch could delete their local history so they would join the
> > other branch.
> >
> > Regards,
> >
> >
> > ------------------------------
> > *From:* Alistair Mann <al at pectw.net>
> > *Sent:* Wednesday, July 31, 2019 15:59
> > *To:* Kenshiro [] <tensiam at hotmail.com>; Bitcoin Protocol Discussion <
> > bitcoin-dev at lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:
> >
> > > I would like to propose that a "moving checkpoint" is added to the
> > Bitcoin
> > > protocol. It's a very simple rule already implemented in NXT coin:
> > >
> > > - A node will ignore any new block under nodeBlockHeight - N, so the
> > > blockchain becomes truly immutable after N blocks, even during a 51%
> > attack
> > > which thanks to the moving checkpoint can't rewrite history older than
> > the
> > > last N blocks.
> >
> > How would a (potentially, state-sponsored) netsplit lasting longer than N
> > be
> > handled?
> > --
> > Alistair Mann
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/9071fcc3/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 51, Issue 3
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/97a230b4/attachment-0001.html>

More information about the bitcoin-dev mailing list