[bitcoin-dev] [Meta] bitcoin-dev moderation
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 pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
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. The main concern is that people won't want to actually follow the
spec for proprietary types and instead just use some unused type value.
So I think instead we should do:
{0xFC}|{private_type}
and the prefix string can be optional (and strongly recommended) after that.
Since public parsers won't really be enforcing the rules for proprietary
types, I don't think it really makes sense to specify and enforce how
they should be. After all, the key is really just an opaque data blob.
In the same vein, it would probably be useful to allow multiple types
for proprietary use as originally proposed to make implementation of
these easier. If more type are needed, then the private type
construction can be used.
Andrew
On 8/1/19 1:57 PM, Andrew Chow wrote:
>
> It seems like the consensus is that we should use Compact Size Unsigned
> Integers for the field types, so we will do that. The types will be
> minimally encoded CSUints.
>
> For the proprietary types, I will use Dimitry's and Andrew Poelstra's
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.html)
> suggestion. There will be one proprietary type, 0xFC. This will be
> followed by a variable length string that is a vendor specific prefix
> that serves as a unique identifier to help with preventing usage of
> proprietary types outside of private contexts. This will then be
> followed by the actual type for the data, as defined by the user of the
> proprietary type.
>
> The prefix will just be a string, prefixed with a compact size unsigned
> integer. If no prefix is wanted, then a single 0x00 byte can be used.
>
> For public software, there is no need to handle these proprietary types
> at all so they do not need to check the string or the data type. It is
> not necessary to enforce the above rules about proprietary types except
> that they use the proprietary type value.
>
>
> Andrew Chow
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
It seems like the consensus is that we should use Compact Size Unsigned Integers for the field types, so we will do that. The types will be minimally encoded CSUints. For the proprietary types, I will use Dimitry's and Andrew Poelstra's (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.html) suggestion. There will be one proprietary type, 0xFC. This will be followed by a variable length string that is a vendor specific prefix that serves as a unique identifier to help with preventing usage of proprietary types outside of private contexts. This will then be followed by the actual type for the data, as defined by the user of the proprietary type. The prefix will just be a string, prefixed with a compact size unsigned integer. If no prefix is wanted, then a single 0x00 byte can be used. For public software, there is no need to handle these proprietary types at all so they do not need to check the string or the data type. It is not necessary to enforce the above rules about proprietary types except that they use the proprietary type value. Andrew Chow ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
> why not use Bitcoin compact uint, which most PSBT consumers already implement? I totally agree with that, compact int parsing is already implemented in all bitcoin applications, wallets and libraries. Also, for certain (mb proprietary) applications I will be willing to use multi-byte keys where the first byte defines the application type and next bytes define application-specific fields. I would suggest to set proprietary bytes to 0xF0-0xFC or to 0xE0-0xEF then (E for Enterprise?). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
mm you are right, then the "moving checkpoint" rule needs to have some limits to allow the network self-heal instead of requiring humans detecting the splits or stopping nodes. Let's suppose than a 51% attack can be detected and the developers can release a new version of the software with a new mining protocol in about 3 days. Then the complementary rule could be something like this: - If 2 forks have a block height difference of 432 blocks (about 3 days) or more, then the moving checkpoint rule is ignored and everything works as with the current protocol. With this rule, the network can self-heal in a 100% automated way. This would prevent a history rewrite of more than 24 hours during a 51% attack during 3 days, which should give enough time to change the protocol. If instead of a 51% attack what happens is a network split, then nodes should converge to the longest chain in a few days. But maybe I'm missing something here, I'm still learning. Regards, From: Alistair Mann Sent: Thursday, August 1, 2019 1:28 To: Kenshiro [] Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol On Wednesday 31 Jul 2019 14:53:25 Kenshiro [] wrote: >> 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. A netsplit cannot be detected but merely be suspected where the p2p protocol does allow arbitrary connecting/disconnecting of any peer: there's no difference between a remote net being split off, that net having nothing to say, and that net choosing to disconnect. Detection then mandates manual, out- of-band communications, which is error prone and centralising. I also observe 'stopping nodes' during netsplits introduces several attack vectors. Among them: create a netsplit, which stops the nodes, turn off the netsplit, repeat. A sequence of 365 actors causing their own small netsplits could effectively stop Bitcoin at the cost (to them) of no Internet for one day a year as the rolling netsplit could never be 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. > > P.S.: To be clearer, in this example I set an N value of 144 blocks, which > is approximately 24 hours. I've seen estimates of China hosting more than 51% of hashpower. Say they conduct a netsplit. Does your suggestion mean that it's the rest of the world that has to delete their local history because they lack the hashpower to assert themselves as the proper branch? If so, I think having to delete actual history everywhere across the globe but China is not a price worth paying to limit reorgs to 24 hours. I am unconvinced that the moving checkpoint you describe would improve Bitcoin. -- Alistair Mann ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
