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
Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Hi, On 7/31/19 12:19 PM, Dmitry Petukhov wrote: > > I think private formats should have at least a basic format: they > should start with a prefix. This way different prviate formats can be > distinguished by this prefix, and there will be no risk of > unintentional confusion. > > Private types can start with the size of the prefix, and then > organization can choose any prefix they like, or no prefix, if > the size is of the prefix is 0 (means they are fine with possible > conflicts with other empty-prefix private types) > I don't think that should something that is required for people to do, but perhaps it can be something that is strongly recommended and suggested in the BIP itself. > > Why not just say that the types should be encoded as 'compact size > unsigned integer' ? This format for variable length integer encoding is > already used in the BIP for other fields, and thus will not add any > additional complexity to the parsing. > On 7/31/19 10:32 AM, jan matejek via bitcoin-dev wrote:> > > why not use Bitcoin compact uint, which most PSBT consumers already > implement? > There are a few issues with using a compact size uint. The main issue is that it doesn't translate well to the proprietary use types. If we used CSUint for the type, then all of type values for proprietary use need to be reserved instead of allowing them to be infinitely expanded from the initial set of proprietary use types. There is also the fact that CSUints are malleable as the same value can be represented in many different ways, just with different amounts of leading zeroes. But I suppose that isn't really that big of an issue. I am not opposed to using a CSUint, I just felt that it made things a bit harder and was unnecessary. Andrew ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
On Tue, Jul 30, 2019 at 10:27:17PM +0100, Chris Belcher wrote: > And any ECC-alternative or hash-function-alternative fork will > probably take a couple of months to be designed, implemented and > deployed as well, giving a chance for lockers to move coins. Probably. A stronger form of my argument would apply to single-wallet (or wallet library) problems of the type we see with depressing regularity, such as reused nonces, weak nonces, brainwallets, and weak HD seeds. In some cases, this leads directly to theft and loss---but in others, the problem is detected by a friendly party and funds can be moved to a secure address before the problem is publicly disclosed and attackers try to exploit it themselves. If funds are timelocked, there's a greater chance that the issue will become publicly known and easily exploitable while the funds are inaccessible. Then, at the time the lock expires, it'll become a race between attackers and the coin owner to see who can get a spending transaction confirmed first. > This scheme could be attacked using address reuse. An attacker could > create an aged coin on a heavily-reused address, which would force an > SPV client using this scheme to download all the blocks which contain > this reused address which could result in many gigabytes of extra > download requirement. Good point. There's also the case that some Electrum-style indexers don't index more than a certain number of outputs sent to the same address. E.g., I believe Electrs[1] stops indexing by default after 100 outputs to the same address. [1] https://github.com/romanz/electrs > So to fix this: a condition for aged coins is that their address has not > been reused, if the coin is on a reused address then the value of the > fidelity bond becomes zero. I don't think that works. If Bob sends 100 BTC to bc1foo and then uses that UTXO as his fidelity bond, Mallory can subsequently send some dust to bc1foo to invalidate Bob's bond. To use compact block filters in a way that prevents spamming, I think we'd need a different filter type that allowed you to filter by outpoint. -Dave ___ 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
В Wed, 31 Jul 2019 01:13:46 + Andrew Chow via bitcoin-dev wrote: > Firstly, I would like to propose that some types be reserved for > proprietary use. These proprietary use types are, in general, for > private use by individuals and organizations who want to use PSBT in > their processes. These are usefule when there are additional data that > they need attached to a PSBT but such data are not useful (or > available) for the general public. I think private formats should have at least a basic format: they should start with a prefix. This way different prviate formats can be distinguished by this prefix, and there will be no risk of unintentional confusion. Private types can start with the size of the prefix, and then organization can choose any prefix they like, or no prefix, if the size is of the prefix is 0 (means they are fine with possible conflicts with other empty-prefix private types) > Lastly, I would like to propose the canonical method for mult-byte > types. We designate a specific type to indicate that the type is > multiple bytes. When such types are observed, parsers should move onto > the next byte and interpret that as the type, keeping in mind the > number of bytes that were read in for the type. > > I propose that we use 0xFF as this designated type. When a parser sees > an 0xFF value as the type, it reads the next byte as being part of the > type. So two byte types will be of the form 0xFFXX. This method allows > us to do a prefix match in order to quickly identify the type being > used. For types with more bytes, simply use another 0xFF byte. So > three byte types would be of the form 0xXX, four byte, > 0xFFXX, and so on. When multi-byte types are specified in the > BIP, they should be specified in this full length form, i.e. two byte > types as 0xFFXX. Why not just say that the types should be encoded as 'compact size unsigned integer' ? This format for variable length integer encoding is already used in the BIP for other fields, and thus will not add any additional complexity to the parsing. ___ 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
P.S.: To be clearer, in this example I set an N value of 144 blocks, which is approximately 24 hours. From: Kenshiro [] Sent: Wednesday, July 31, 2019 16:40 To: Alistair Mann ; Bitcoin Protocol Discussion 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 Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] ; Bitcoin Protocol Discussion 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] ; Bitcoin Protocol Discussion 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
hello, On 31. 07. 19 3:13, Andrew Chow via bitcoin-dev wrote: > Lastly, I would like to propose the canonical method for mult-byte > types. We designate a specific type to indicate that the type is > multiple bytes. When such types are observed, parsers should move onto > the next byte and interpret that as the type, keeping in mind the number > of bytes that were read in for the type. why not use Bitcoin compact uint, which most PSBT consumers already implement? regards m. ___ 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
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
В Tue, 30 Jul 2019 22:39:14 +0100 Chris Belcher via bitcoin-dev 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Hi all, 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. NXT coin has a N value of 720 blocks, like 12 hours of blocks. To be more conservative, Bitcoin could have a N value of 144 blocks (like 24 hours). So users and exchanges could plan their operations with big amounts of BTC knowing that only after 24 hours a transaction is truly immutable. Maybe a 51% attack never happens but if it does it would be nice to be 100% sure that history rewrite is limited to only 24 hours. Regards, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility
Hi All, I would like to propose some types that allow for BIP 174 PSBT to be extended more in the future. Firstly, I would like to propose that some types be reserved for proprietary use. These proprietary use types are, in general, for private use by individuals and organizations who want to use PSBT in their processes. These are usefule when there are additional data that they need attached to a PSBT but such data are not useful (or available) for the general public. These types will be guaranteed to not be used by the public specification and there is no expectation that any publicly available software be able to understand any specific meanings of these types. These types should be used for internal processes only. The types I would like to reserve for proprietary use are the 15 types from 0xF0 to 0xFE inclusive. These 15 type values will be the same for global, per-input, and per-output types. If 15 types are not enough, additional types can be obtained using the multi-byte type method described later. Next, I would like to propose a global version type and field. The version type is 0xEF with only the type as the key, and the value is a 32-bit unsigned little endian integer representing the version number. A PSBT without a version number is to be considered version 0. If a parser sees a version number that it does not understand, it should exit immediately as the PSBT will contain types that are not safe to ignore. This version number is a safeguard in the event that a backwards incompatible change is introduce to PSBT. While PSBT is designed and intended to be forwards compatible by allowing parsers to ignore types that they do not understand, it is possible that at ype is added in the future which breaks this assumption and it would be unsafe for a type to be ignored. Updaters and combiners that need to add a version number to a PSBT should use the highest version number required. For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1. If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified. It is not expected that the version number will ever be used. We try to make PSBT fields safe to ignore. The version number is only being included here as a safeguard in the event that breaking compatibilty is required. Lastly, I would like to propose the canonical method for mult-byte types. We designate a specific type to indicate that the type is multiple bytes. When such types are observed, parsers should move onto the next byte and interpret that as the type, keeping in mind the number of bytes that were read in for the type. I propose that we use 0xFF as this designated type. When a parser sees an 0xFF value as the type, it reads the next byte as being part of the type. So two byte types will be of the form 0xFFXX. This method allows us to do a prefix match in order to quickly identify the type being used. For types with more bytes, simply use another 0xFF byte. So three byte types would be of the form 0xXX, four byte, 0xFFXX, and so on. When multi-byte types are specified in the BIP, they should be specified in this full length form, i.e. two byte types as 0xFFXX. The same mechanism can be used for the proprietary use types, just with a different value as the designated multi-byte indicator. For example, one could use 0xFE as the designated type as that is in the proprietary types range. Of course any type within the proprietary type range could be used as the indicator, it is up to the users to determine this themselves. While other methods of indicating multiple bytes and lengths may be more space efficient and allow us to have more types represented in a smaller space, I am choosing this method because of its simplicity. This is easy to understand and implement. Furthermore, I do not expect that we will use so many types. I don't think that we will need to have more than one byte types for a very long time. Please let me know your thoughts on these extensions. I will open a PR to the bips repo to add these to BIP 174 if there are no objections. Andrew Chow ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
On 26/07/2019 10:38, Dmitry Petukhov via bitcoin-dev wrote: > > If the attacker is the entity who provides this 'maker outsourcing', > and it captures significant portion of that maker-outsourcing/utxo-rent > market, it can even receive some profit from the convenience fee, while > deanonymizing the joins. > > And with pseudonymous entities, you cannot be sure how much of that > market the attacker controls. > No the attacker does not. I believe renting out UTXO proofs does not change the privacy properties, because of the quadratic term in the fidelity bond formula. 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. JoinMarket takers always use multiple makers, so a single maker can never deanonymize a coinjoin just they get chosen by takers a lot. (But they would make loads of money in coinjoin fees, which should encourage other makers to also sacrifice coins in order to compete with them and capture some of that fee income) If a sybil attacker wants to run multiple makers for the purpose of deanomyization then they will take a substantial quadratic hit in their effectiveness. This is explored the other document "Financial mathematics of JoinMarket fidelity bonds" https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b Regards CB ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
On 27/07/2019 20:34, David A. Harding wrote: > > Timelocking bitcoins, especially for long periods, carries some special > risks in Bitcoin: > > 1. Inability to sell fork coins, also creating an inability to influence > the price signals that help determine the outcome of chainsplits. > > 2. Possible inability to transition to new security mechanisms if > a major weakness is discovered in ECC or a hash function. > Far future locks are problematic. In my proposal I've only considered locked coins for only 6 months because of exactly these reasons. The market competition between airdrops should still exist after 6 months so lockers will still get a chance to sell their airdrops. And any ECC-alternative or hash-function-alternative fork will probably take a couple of months to be designed, implemented and deployed as well, giving a chance for lockers to move coins. > An alternative to timelocks might be coin age---the value of a UTXO > multiplied by the time since that UTXO was confirmed. Coin age may be > even harder for an attacker to acquire given that it is a measure of > past patience rather than future sacrifice. It also doesn't require > using any particular script and so is flexible no matter what policy the > coin owner wants to use (especially if proof-of-funds signatures are > generated using something like BIP322). I'm becoming more and more convinced that coin age is also a valid method of proving a sacrifice. Using coin age also has a benefit that less block space is used, because using timelocks requires a new on-chain transaction to be made every 6 months or whatever the locking period is. Perhaps JoinMarket should accept all three methods of proving a sacrifice: burning, timelocking and aging. I could imagine that makers would first lock coins for 6 months to create a fidelity bond they could immediately use, and after the timelock expires leave that coin unspent and use its age as the fidelity bond. For what its worth, I mostly considered burning coins because the maths for it is easy (the value of such a bond is just V^2), and because it provides a boundary condition (locking up coins for infinity time is the same as burning them). I doubt anybody will actually do it in practice. > - BIP158 users who have saved their past filters to disk can use them to > determine which blocks subsequent to the one including the UTXO may > contain a spend from it. However, since a UTXO can be spent in the > same block, they'd always need to download the block containing the > UTXO (alternatively, the script could contain a 1-block CSV delay > ensuring any spend occurred in a later block). If BIP158 filters > become committed at some point, this mechanism is upgraded to SPV-level > security. This scheme could be attacked using address reuse. An attacker could create an aged coin on a heavily-reused address, which would force an SPV client using this scheme to download all the blocks which contain this reused address which could result in many gigabytes of extra download requirement. So to fix this: a condition for aged coins is that their address has not been reused, if the coin is on a reused address then the value of the fidelity bond becomes zero. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
