bfd at cock.lu [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-05-09 to 2017-06-20
💬 Posted a total of 16 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:02:14

- reply

📅 Original date posted:2017-06-20
📝 Original message:On 2017-06-20 12:52, Tom Zander via bitcoin-dev wrote:
> Second, stating that a bloom filter is a "total loss of privacy" is
> equally
> baseless and doesn’t need debunking.
>
"On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin
Clients"
> We show analytically and empirically that the reliance on Bloom filters
> within existing SPV clients leaks considerable information about the
> addresses of Bitcoin users. Our results show that an SPV client who
> uses a modest number of Bitcoin addresses (e.g., < 20) risks revealing
> almost all of his addresses.
https://eprint.iacr.org/2014/763.pdf

2023-06-07 20:02:10

- reply

📅 Original date posted:2017-06-19
📝 Original message:Several times. It's been debated if unconfirmed transactions are
necessary, methods of doing more private filtering have been suggested,
along with simply not filtering unconfirmed transactions at all. My
collected data suggests that there is very little use of BIP37 at
present, based on incoming connections to nodes I know end up in the DNS
seed responses (no "SPV" clients do their own peer management).
On 2017-06-19 12:58, Andreas Schildbach via bitcoin-dev wrote:
> I'm not sure if this has been brought up elsewhere in this thread.
>
> This proposal doesn't seem to be a complete replacement of BIP37: It
> doesn't provide a filter for unconfirmed transactions like BIP37 does.
>
> That means that most light clients will continue to use BIP37 even if
> they may use this BIP as a supplement. Otherwise users would not get
> timely notification of incoming payments any more.
>
>
> On 06/01/2017 09:01 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
>> Hi y'all,
>>
>> Alex Akselrod and I would like to propose a new light client BIP for
>> consideration:
>> *
>> https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
>> [...]
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:00:15

- reply

📅 Original date posted:2017-04-16
📝 Original message:On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote:
> This is a great solution.
>
> 8 or more secure hashes, each of which can be implemented on GPU/CPU,
> but rotate through them - per block round robin.
>
> Hardware, infrastructue investment is protected. ASIC is not.
>
The write time for configuring a FPGA with a fresh bitstream is measured
in tens of milliseconds.
> ASIC will never beat this - because it will be 8x more expensive to
> maintain the cold circuits.
>
Unused circuits don't consume power, which is the main cost in running a
miner.

2023-06-07 19:59:22

- reply

📅 Original date posted:2017-04-06
📝 Original message:Miners blocking SegWit due to ASICBOOST requirements also means they
would block future deployment of committed bloom filters.
On 2017-04-06 00:37, Gregory Maxwell via bitcoin-dev wrote:
> A month ago I was explaining the attack on Bitcoin's SHA2 hashcash
> which
> is exploited by ASICBOOST and the various steps which could be used to
> block it in the network if it became a problem.
>
> While most discussion of ASICBOOST has focused on the overt method
> of implementing it, there also exists a covert method for using it.
>
> As I explained one of the approaches to inhibit covert ASICBOOST I
> realized that my words were pretty much also describing the SegWit
> commitment structure.
>
> The authors of the SegWit proposal made a specific effort to not be
> incompatible with any mining system and, in particular, changed the
> design at one point to accommodate mining chips with forced payout
> addresses.
>
> Had there been awareness of exploitation of this attack an effort
> would have been made to avoid incompatibility-- simply to separate
> concerns. But the best methods of implementing the covert attack
> are significantly incompatible with virtually any method of
> extending Bitcoin's transaction capabilities; with the notable
> exception of extension blocks (which have their own problems).
>
> An incompatibility would go a long way to explain some of the
> more inexplicable behavior from some parties in the mining
> ecosystem so I began looking for supporting evidence.
>
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
>
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
>
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
>
> The specific activation height is something I currently don't have
> a strong opinion, so I've left it unspecified for the moment.
>
> <pre>
> BIP: TBD
> Layer: Consensus
> Title: Inhibiting a covert attack on the Bitcoin POW function
> Author: Greg Maxwell <greg at xiph.org>
> Status: Draft
> Type: Standards Track
> Created: 2016-04-05
> License: PD
> </pre>
>
> ==Abstract==
>
> This proposal inhibits the covert exploitation of a known
> vulnerability in Bitcoin Proof of Work function.
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
>
> ==Motivation==
>
> Due to a design oversight the Bitcoin proof of work function has a
> potential
> attack which can allow an attacking miner to save up-to 30% of their
> energy
> costs (though closer to 20% is more likely due to implementation
> overheads).
>
> Timo Hanke and Sergio Demian Lerner claim to hold a patent on this
> attack,
> which they have so far not licensed for free and open use by the
> public.
> They have been marketing their patent licenses under the trade-name
> ASICBOOST. The document takes no position on the validity or
> enforceability
> of the patent.
>
> There are two major ways of exploiting the underlying vulnerability:
> One
> obvious way which is highly detectable and is not in use on the network
> today and a covert way which has significant interaction and potential
> interference with the Bitcoin protocol. The covert mechanism is not
> easily detected except through its interference with the protocol.
>
> In particular, the protocol interactions of the covert method can block
> the
> implementation of virtuous improvements such as segregated witness.
>
> Exploitation of this vulnerability could result in payoff of as much as
> $100 million USD per year at the time this was written (Assuming at
> 50% hash-power miner was gaining a 30% power advantage and that mining
> was otherwise at profit equilibrium). This could have a phenomenal
> centralizing effect by pushing mining out of profitability for all
> other participants, and the income from secretly using this
> optimization could be abused to significantly distort the Bitcoin
> ecosystem in order to preserve the advantage.
>
> Reverse engineering of a mining ASIC from a major manufacture has
> revealed that it contains an undocumented, undisclosed ability
> to make use of this attack. (The parties claiming to hold a
> patent on this technique were completely unaware of this use.)
>
> On the above basis the potential for covert exploitation of this
> vulnerability and the resulting inequality in the mining process
> and interference with useful improvements presents a clear and
> present danger to the Bitcoin system which requires a response.
>
> ==Background==
>
> The general idea of this attack is that SHA2-256 is a merkle damgard
> hash
> function which consumes 64 bytes of data at a time.
>
> The Bitcoin mining process repeatedly hashes an 80-byte 'block header'
> while
> incriminating a 32-bit nonce which is at the end of this header data.
> This
> means that the processing of the header involves two runs of the
> compression
> function run-- one that consumes the first 64 bytes of the header and a
> second which processes the remaining 16 bytes and padding.
>
> The initial 'message expansion' operations in each step of the SHA2-256
> function operate exclusively on that step's 64-bytes of input with no
> influence from prior data that entered the hash.
>
> Because of this if a miner is able to prepare a block header with
> multiple distinct first 64-byte chunks but identical 16-byte
> second chunks they can reuse the computation of the initial
> expansion for multiple trials. This reduces power consumption.
>
> There are two broad ways of making use of this attack. The obvious
> way is to try candidates with different version numbers. Beyond
> upsetting the soft-fork detection logic in Bitcoin nodes this has
> little negative effect but it is highly conspicuous and easily
> blocked.
>
> The other method is based on the fact that the merkle root
> committing to the transactions is contained in the first 64-bytes
> except for the last 4 bytes of it. If the miner finds multiple
> candidate root values which have the same final 32-bit then they
> can use the attack.
>
> To find multiple roots with the same trailing 32-bits the miner can
> use efficient collision finding mechanism which will find a match
> with as little as 2^16 candidate roots expected, 2^24 operations to
> find a 4-way hit, though low memory approaches require more
> computation.
>
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
>
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right side of the tree using transaction permutation or
> substitution of a small number of transactions. All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
>
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> extra-nonce grinding which would substantially erode the
> benefit of the attack.
>
> It is this final optimization which this proposal blocks.
>
> ==New consensus rule==
>
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
>
> (See BIP-141 "Commitment structure" for details)
>
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
>
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.
>
> ==Discussion==
>
> The commitment in the left side of the tree to all transactions
> in the right side completely prevents the final sqrt speedup.
>
> A stronger inhibition of the covert attack in the form of
> requiring the least significant bits of the block timestamp
> to be equal to a hash of the first 64-bytes of the header. This
> would increase the collision space from 32 to 40 or more bits.
> The root value could be required to meet a specific hash prefix
> requirement in order to increase the computational work required
> to try candidate roots. These change would be more disruptive and
> there is no reason to believe that it is currently necessary.
>
> The proposed rule automatically sunsets. If it is no longer needed
> due to the introduction of stronger rules or the acceptance of the
> version-grinding form then there would be no reason to continue
> with this requirement. If it is still useful at the expiration
> time the rule can simply be extended with a new softfork that
> sets longer date ranges.
>
> This sun-setting avoids the accumulation of technical debt due
> to retaining enforcement of this rule when it is no longer needed
> without requiring a hard fork to remove it.
>
> == Overt attack ==
>
> The non-covert form can be trivially blocked by requiring that
> the header version match the coinbase transaction version.
>
> This proposal does not include this block because this method
> may become generally available without restriction in the future,
> does not generally interfere with improvements in the protocol,
> and because it is so easily detected that it could be blocked if
> it becomes an issue in the future.
>
> ==Backward compatibility==
>
>
> ==Implementation==
>
>
> ==Acknowledgments==
>
>
> ==Copyright==
>
> This document is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:58:57

- reply

📅 Original date posted:2017-04-01
📝 Original message:On 2017-02-17 11:28, Chris Belcher via bitcoin-dev wrote:
> I think this committed bloom filter idea is very good and much better
> than bip37, but for good privacy for when bitcoin is used often still
> requires certain behavior namely downloading blocks
> from many different peers with new tor circuits.
>
> Note that I've been dealing with counting transaction subgraphs but
> actually finding them from blocks might also be computationally
> infeasible. Although a Bayesian approach worked very
> well for similar transaction subgraph linking
> [https://arxiv.org/pdf/1612.06747v3.pdf]
>
> It would also be interesting to analyze what information a spy can get
> if they are missing some blocks that the wallet downloaded.
>
> For the long term, private and high-volume bitcoin use will be best
> served by off-chain transactions. They will probably be a huge win just
> because the large and public blockchain is such a non-private
> way of doing things.
>
Thank you for the analysis, this generally matches my views about the
properties offered by the system.
I've generally developed the opinion that BIP37 is effectively unused
by all but a very small number of wallets and services now, setting up
sinkhole nodes in the network to monitor `filterload` commands seems
to back that up.

2023-06-07 19:58:55

- reply

📅 Original date posted:2017-04-01
📝 Original message:If a wallet is unaware of spends of its own coins (ie, transactions
were made it can't have known about), there's probably bigger problems
going on. You might enjoy the topic on this mailing list on committed
bloom filters however, as this solves a similar issue without needing
an ever-growing list of hundreds of millions of spent outputs.
On 2017-04-02 06:04, praxeology_guy via bitcoin-dev wrote:
> Bitcoin nodes could also keep a spentness status list, where each bit
> in the spentness status list corresponds to whether a txo in the MMR
> is spent. This could make it so that disconnected wallets didn't have
> to guess the pruned relative spentness status when it reconnects to
> the network... and help prevent DoS attacks.

2023-06-07 19:57:18

- reply

📅 Original date posted:2017-03-15
📝 Original message:Sorry, this is not the case.
Your slides gloss over the simple fact that compact fraud proofs in
Bitcoin aren't possible, and that the "SPV" implemented today bears
absolutely no resemblance in security properties to the version
described in the Bitcoin white paper. In the white paper SPV clients
have the same security as fully validating nodes, in the implementation
of BIP37 they have absolutely no security except the vague hope that
they are not being lied to, and that the chain with the most work they
are seeing is actually valid, both are very weak assumptions.
The suggested solution in no way precludes unconfirmed transactions from
being used with a commitment scheme, my comments and others are just
recognising that they are an almost useless indicator for people who
aren't validating.
During the validationless mining failure around the BIP66 activation
miners produced 6 invalid blocks in a chain, and many more invalid
blocks in isolated bursts for a period lasting several months. Due to
the instability of the network you are completely unreasonable to accept
anything except multiple confirmations, the true number for safety is
probably more like 60 or 120, not 6, or 3, or 1 as some Bitcoin
exchanges use today.
0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99.bin
bad-version(0x00000002)
0000000000000000032527aa796d3672e32e5f85a452d3a584a28fc7efbcd5d0.bin
bad-version(0x00000002)
000000000000000003ae1223f4926ec86100885cfe1484dc52fd67e042a19b12.bin
bad-version(0x00000002)
0000000000000000083cbdbb25c1607527c8f3fdb16f0d048c4439a73b501cb6.bin
bad-version(0x00000002)
00000000000000000954ed93eda1e79e8261137548fa9ccf4d516bb384a3660b.bin
bad-version(0x00000002)
00000000000000000afc9fbe7cfe8a6b50502d509ba626beb2e2d6c15d1d3ee3.bin
bad-version(0x00000002)
00000000000000000b6adf92bc192b3c21210f456ab21b5e46951665c74cfab2.bin
bad-version(0x00000002)
00000000000000000c9bb4a508fff34f5450d9c62ef2cb833e53909a4c549de5.bin
bad-version(0x00000002)
0000000000000000116322b5f25826787b01f7a70fb322837b68dff8216cefc4.bin
bad-version(0x00000002)
000000000000000012aac0664cd8b6cbc3ea485921a05f2c4340f928b0226d3c.bin
bad-version(0x00000002)
"SPV" like you're describing can exist, or validationless mining can
exist, both can not simultaneously.
On 2017-03-16 09:36, Tom Harding via bitcoin-dev wrote:
> Agreed.
>
> In contrast, BIP37 as used today is totally decentralized, and can me
> made much more secure, private, and scalable -- without giving up the
> utility of unconfirmed transactions.
>
> Please don't read into this statement a belief that all the coffees
> should go on the chain, or that the security or privacy of BIP37
> compare favorably to any other particular thing.
>
> https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA
>
>
>
> On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:
>> You might as well replace Bitcoin with a system where these parties
>> sign transactions and skip mining altogether, it would have the same
>> properties and be significantly more effient.
>>
>>
>> On 2017-01-04 23:06, Chris Priest wrote:
>>> On 1/3/17, Jonas Schnelli via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> There are plenty, more sane options. If you can't run your own
>>>> full-node
>>>> as a merchant (trivial), maybe co-use a wallet-service with
>>>> centralized
>>>> verification (maybe use two of them), I guess Copay would be one of
>>>> those wallets (as an example). Use them in watch-only mode.
>>>
>>> The best way is to connect to the mempool of each miner and check to
>>> see if they have your txid in their mempool.
>>>
>>> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
>>> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
>>> https://bw.com/api/is_in_mempool?txid=334847bb...
>>> https://bitfury.com/api/is_in_mempool?txid=334847bb...
>>> https://btcc.com/api/is_in_mempool?txid=334847bb...
>>>
>>> If each of these services return "True", and you know those services
>>> so not engage in RBF, then you can assume with great confidence that
>>> your transaction will be in the next block, or in a block very soon.
>>> If any one of those services return "False", then you must assume
>>> that
>>> it is possible that there is a double spend floating around, and that
>>> you should wait to see if that tx gets confirmed. The problem is that
>>> not every pool runs such a service to check the contents of their
>>> mempool...
>>>
>>> This is an example of mining centralization increasing the security
>>> of
>>> zero confirm. If more people mined, this method will not work as well
>>> because it would require you to call the API of hundreds of different
>>> potential block creators.
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:57:07

- reply

📅 Original date posted:2017-03-07
📝 Original message:Having a commitment to a "balance" of an "address" (I assume you mean
P2SH/P2PKH script) is extremely expensive to create and validate, does
not scale and is not a particularly useful thing for a client to use.
Validating clients should never expect their UTXO to be
inconsistent with that of the network, if something has happened to
cause this loosely committing to the UTXO is of no value.
On 2017-03-08 08:28, praxeology_guy via bitcoin-dev wrote:
> A Commitment-suitable UTXO set "Balances" file data structure
>
> - Allows pruned nodes to satisfy SPV nodes
>
> - Allows pruned nodes to trustlessly start synchronizing at a Balances
> file's block height instead of the genesis block
>
> - Allows all nodes in the network to verify their UTXO set's data
> integrity
>
> For this to work, Bitcoin would need a new policy:
>
> - A UTXO commitment is made every "Balances/UTXO Commitment Period"
> (BCP) blocks. The UTXO commitment is made on the state of the UTXO at
> BCP blocks ago. For example, if BCP is 5000, and we are creating
> block 20,000, then block 20,000 would contain a commitment on what the
> state of the UTXO was at block 15,000, right before any changes due to
> block 15,001.
>
> - The commitment is made on the state of the UTXO "BCP blocks ago"
> instead of the UTXO state at the tip because: 1. Such a commitment can
> be made in a background thread and not delay mining/synchronizing node
> operations; 2. The work of creating the commitment doesn't have to be
> redone in the case of a fork.
>
> - The file/commitment is made in a background thread, starting at
> least BCP/2 blocks after the last block containing a utxo commitment.
>
> Balances file summary:
>
> {
>
> Header: 48 bytes
>
> {
>
> File Type: 4 bytes
>
> File version: 4 bytes
>
> size of balances: 8 bytes
>
> root hash: 32 bytes
>
> }
>
> balances: "size of balances" bytes
>
> balance index: "piece count" * (N + 4) bytes, N=4 proposed
>
> merkle tree hashes: ~ 2 * "piece count" * 32 bytes
>
> }
>
> balances: is a list of balances sorted by txid:
>
> {
>
> length: 4 bytes
>
> txid: 32 bytes
>
> CCoins: variable length, depends on UTXO size
>
> }
>
> A "piece" is like in bittorrent's piece. I propose piece size =
> 32*1024 bytes. 2GB of balance data would then be divided into 65536
> pieces.
>
> transaction index is an array (with "piece count" elements) of:
>
> {
>
> txix: the first N bytes of a txid. I'm proposing N = 4
>
> piece offset: 4 bytes, location of the first balance in the piece.
>
> }
>
> merkle tree hashes:
>
> - array of "piece count" leaf hashes, hashing the balance pieces
>
> - array of "(child layer count + 1)/2" node hashes, hashing pairs of
> child hashes, or copying up if only one child
>
> - repeat ^ until the root hash is written
>
> ... except reverse the layer order. In other words, it should be
> breadth first.
>
> ==========
>
> Data structure design notes:
>
> - Most of the file's space is used by the balances. For example,
> given a 32kB piece size and 2GB balances, the non-balances data only
> consumes about 4.5MB. If N was increased to 32, ~6.5MB.
>
> - piece size should be small enough that not that much effort is
> wasted when invalid pieces are received.
>
> - piece size should also be small in the case that this data structure
> is used instead of block history for SPV proof. Then pruned nodes can
> satisfy SPV clients.
>
> - The child count = 2 merkle tree structure is only necessary for if
> this data structure is to be used to satisfy SPV clients. If not used
> for such a purpose, then technically the root hash could have the leaf
> hashes as it's direct children. But practically this doesn't make a
> difference: merkle tree size is nothing compared to sizeof(balances).
>
> - The only purpose of the balance index is to support SPV clients
>
> - txix is a truncation of txid to reduce memory usage for a fully
> in-memory index to support SPV nodes. Maybe this truncation isn't
> worthwhile.
>
> Other notes:
>
> - We could make BCP 4383 blocks, which would be 12 times per year,
> given block period was exactly 10 minutes. But since block period is
> not exactly 10 minutes, and file names generated with period 4283 are
> much less comprehensible than file names generated with period 5000...
> I propose 5000.
>
> - Having a shorter BCP period would result in more frequent checks on
> UTXO set integrity, and permit new pruning nodes to start synching
> closer to the tip. But it may require nodes to keep more copies of
> the balances file to satisfy the same backup period, and require more
> background work of creating more balances files.
>
> ===========
>
> Suggested design change to the chainstate "CCoinsViewDB" utxo
> database:
>
> - As it is designed now, the above proposal would require maintaining
> a duplicate but lagging UTXO database.
>
> - I propose changing the "CCoins" data structure so that it can keep
> track of spends that shouldn't be included in the commitment. Maybe
> call it "vtipspends".
>
> Then the process for updating the CCoinsViewDB would be:
>
> 1. Mark a txo as spent by adding the vout_ix to vtipspends.
>
> 2. SetNull() and Cleanup() during the background thread that creates
> Balances commitments. vtipspends would also need to be cleaned.
>
> - The method for checking whether a txo was spent would need to be
> changed to check vtipspends.
>
> At the same time, I know there is currently a lot of code complexity
> with handling forks and txo spends. Let me propose something to
> handle this better too:
>
> - vtipspends could hold {vout_ix, blockhash } instead of just vout_ix.
>
> - Checking whether a txo is spent will then require a parameter that
> specifies the "fork tip hash" or "fork chain"
>
> Then in the case of a fork, no work has to be done to update the utxo
> database... it is immediately ready to handle answering spend
> questions for a different fork.
>
> Feedback welcome. FYI I have coded up the creation of such a file
> already... So I am working on the implementation, not just the spec.
> I'd really like to hear what you guys think about my proposed changes
> to CCoins.
>
> Cheers,
>
> Praxeology
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:56:58

- reply

📅 Original date posted:2017-03-08
📝 Original message:>> I feel you're conflating social identifiability with technical
>> identifiability. Sure, a node operator must always be able to remain
>> anonymous, but nodes themselves require a certain level of
>> identifiability otherwise there would be no means to communicate
>> between them.
Nodes running through networks like cjdns, onion, and i2p can
effectively communicate with no knowledge of the counterparty
whatsoever. Bitcoin does make an assumption that you are connected to
at least one non-partitioned peer, and that there is a cost in having
a large number of sybil nodes in many different ranges. Nothing
says you have to do your communication exclusively on one network or
another, so long as you have *some* source of information which is not
partitioned.
On 2017-03-08 05:44, Eric Voskuil via bitcoin-dev wrote:
> On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>> Nodes are by design not supposed to be identifiable in any way
>
> This is of course my objection to BIP150 ("a way for peers to ...
> guarantee node ownership").
>
>> I feel you're conflating social identifiability with technical
>> identifiability. Sure, a node operator must always be able to remain
>> anonymous, but nodes themselves require a certain level of
>> identifiability otherwise there would be no means to communicate
>> between them.
>
> Anonymous node identity is pointless, and is why I object to BIP151.
> It provides no actual security/privacy benefit and is a stepping stone
> to non-anonymous node identity (e.g. BIP150).
>
>> I agree that absolute node counts have their limitations, but that
>> doesn't stop them being used as a measure and even propaganda tool.
>> If something like this is a way to help highlight the latter when it
>> is occurring I think it has value. I 'm not convinced that node
>> identifiers or identity persistence would have any meaningful impact
>> on privacy, though am open to being convinced otherwise.
>
> Bitcoin does not require node counts, and this proposal is redundant
> with BIP150.
>
> e
>
>> -------------------------
>>
>> FROM: Btc Drak <btcdrak at gmail.com>
>> SENT: Sunday, March 5, 2017 1:27 PM
>> TO: John Hardy; Bitcoin Protocol Discussion
>> SUBJECT: Re: [bitcoin-dev] Unique node identifiers
>>
>> Nodes are by design not supposed to be identifiable in any way,
>> including persisting identities across IPs changes or when
>> connecting over different networks (e.g. clearnet/tor). Anything
>> that makes Bitcoin less private is a step backwards. Also absolute
>> node count is pretty meaningless since only fully validating nodes
>> that participate in economic activity really matter.
>>
>> As a side note, this should probably have started out as a
>> bitcoin-discuss post.
>>
>> On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> The discussion of UASF got me thinking about whether such a method
>>> might lead to sybil attacks, with new nodes created purely to
>>> inflate the node count for a particular implementation in an
>>> attempt at social engineering.
>>> I had an idea for an anonymous, opt-in, unique node identification
>>> mechanism to help counter this.
>>> This would give every node the opportunity to create a node
>>> ‘address’/unique identifier. This could even come in the form
>>> of a Bitcoin address.
>>> The node on first installation generates and backs up a private
>>> key. The corresponding public key becomes that node’s unique
>>> identifier. If the node switches to a new software version or a
>>> new IP, the identifier can remain constant if the node operator
>>> chooses.
>>> Asking a node for its identifier can be done by sending a message
>>> the command ‘identify’ and a challenge. The node can then
>>> respond with its unique identifier and a signature for the
>>> challenge to prove it. The node can also include what software it
>>> is running and sign this information so it can be verified as
>>> legitimate by third parties.
>>> Why would we do this?
>>> Well, it adds a small but very useful piece of data when compiling
>>> lists of active nodes.
>>> Any register of active nodes can have a record of when a node
>>> identifier was “first seen”, and how many IPs the same
>>> identifier has broadcast from. Also, crucially, we could see what
>>> software the node operator has been seen running historically.
>>> This information would make it easy to identify patterns. For
>>> example if a huge new group of nodes appeared on the network with
>>> no history for their identifier they could likely be dismissed as
>>> sybil attacks. If a huge number of nodes that had been reporting
>>> as Bitcoin Core for an extended period of time started switching
>>> to a rival implementation, this would add credibility but not
>>> certainty (keys could be traded), that the shift was more organic.
>>>
>>> This would be trivial to implement, is (to me?) non-controversial,
>>> and would give a way for a node to link itself to a
>>> pseudo-anonymous identity, but with the freedom to opt-out at any
>>> time.
>>> Keen to hear any thoughts?
>>> Thanks,
>>> John Hardy
>>>
>>> john at seebitcoin.com
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:55:12

- reply

📅 Original date posted:2017-01-03
📝 Original message:I believe the filter can be more compact than this, but even if not an
order of magnitude saving of disk space is still significant.
On 2016-05-11 13:29, Bob McElrath wrote:
> Eerrrr....let me revise that last paragraph. That's 12 *GB* of filters
> at
> today's block height (at fixed false-positive rate 1e-6. Compared to
> block
> headers only which are about 33 MB today. So this proposal is not
> really
> compatible with such a wallet being "light"...
>
> Damn units...
>
> Bob McElrath via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
> wrote:
>> I like this idea, but let's run some numbers...
>>
>> bfd--- via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
>> > A Bloom Filter Digest is deterministically created of every block
>>
>> Bloom filters completely obfuscate the required size of the filter for
>> a desired
>> false-positive rate. But, an optimal filter is linear in the number
>> of elements
>> it contains for fixed false-positive rate, and logarithmic in the
>> false-positive
>> rate. (This comment applies to a RLL encoded Bloom filter Greg
>> mentioned, but
>> that's not the only way) That is for N elements and false positive
>> rate
>> \epsilon:
>>
>> filter size = - N \log_2 \epsilon
>>
>> Given that the data that would be put into this particular filter is
>> *already*
>> hashed, it makes more sense and is faster to use a Cuckoo[1] filter,
>> choosing a
>> fixed false-positive rate, given expected wallet sizes. For Bloom
>> filters,
>> multiply the above formula by 1.44.
>>
>> To prevent light clients from downloading more blocks than necessary,
>> the
>> false-positive rate should be roughly less than 1/(block height). If
>> we take
>> the false positive rate to be 1e-6 for today's block height ~ 410000,
>> this is
>> about 20 bits per element. So for todays block's, this is a 30kb
>> filter, for a
>> 3% increase in block size, if blocks commit to the filter. Thus the
>> required
>> size of the filter commitment is roughly:
>>
>> filter size = N \log_2 H
>>
>> where H is the block height. If bitcoin had these filters from the
>> beginning, a
>> light client today would have to download about 12MB of data in
>> filters. My
>> personal SPV wallet is using 31MB currently. It's not clear this is a
>> bandwidth
>> win, though it's definitely a win for computing load on full nodes.
>>
>>
>> [1] https://www.cs.cmu.edu/~dga/papers/cuckoo-conext2014.pdf
>>
>> --
>> Cheers, Bob McElrath
>>
>> "For every complex problem, there is a solution that is simple, neat,
>> and wrong."
>> -- H. L. Mencken
>>
>>
>>
>> !DSPAM:5733934b206851108912031!
>
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> !DSPAM:5733934b206851108912031!
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat,
> and wrong."
> -- H. L. Mencken

2023-06-07 19:55:11

- reply

📅 Original date posted:2017-01-06
📝 Original message:You might as well replace Bitcoin with a system where these parties
sign transactions and skip mining altogether, it would have the same
properties and be significantly more effient.
On 2017-01-04 23:06, Chris Priest wrote:
> On 1/3/17, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> There are plenty, more sane options. If you can't run your own
>> full-node
>> as a merchant (trivial), maybe co-use a wallet-service with
>> centralized
>> verification (maybe use two of them), I guess Copay would be one of
>> those wallets (as an example). Use them in watch-only mode.
>
> The best way is to connect to the mempool of each miner and check to
> see if they have your txid in their mempool.
>
> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
> https://bw.com/api/is_in_mempool?txid=334847bb...
> https://bitfury.com/api/is_in_mempool?txid=334847bb...
> https://btcc.com/api/is_in_mempool?txid=334847bb...
>
> If each of these services return "True", and you know those services
> so not engage in RBF, then you can assume with great confidence that
> your transaction will be in the next block, or in a block very soon.
> If any one of those services return "False", then you must assume that
> it is possible that there is a double spend floating around, and that
> you should wait to see if that tx gets confirmed. The problem is that
> not every pool runs such a service to check the contents of their
> mempool...
>
> This is an example of mining centralization increasing the security of
> zero confirm. If more people mined, this method will not work as well
> because it would require you to call the API of hundreds of different
> potential block creators.

2023-06-07 19:55:09

- reply

📅 Original date posted:2017-01-06
📝 Original message:With a credit card you have an institution worth billions of dollars
asserting that a payment has been made, with the option that it may be
retracted under special circumstances by the card issuer.
Unconfirmed Bitcoin transactions with a SPV client has you trusting
that the un-authenticated DNS seed lookup has not been tampered with,
the connection to the random node that you connect to has not been
tampered with, and that the seed nor the node are attempting to
manipulate you.
The two scenarios aren’t even remotely comparable.
On 2017-01-04 00:56, Aaron Voisine wrote:
> It's easy enough to mark a transaction as "pending". People with bank
> accounts are familiar with the concept.
>
> Although the risk of accepting gossip information from multiple random
> peers, in the case where the sender does not control the receivers
> network is still minimal. Random node operators have no incentive to
> send fake transactions, and would need to control all the nodes a
> client connects to, and find a non-false-positive address belonging to
> the victims wallet.
>
> It's not impossible, but it's non trivial, would only temporarily show
> a pending transaction, and provide no benefit to the node operator.
> There are much juicier targets for an attacker with the ability to
> sybil attack the entire bitcoin p2p network.
>
> Aaron
>
> On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev at jonasschnelli.ch>
> wrote:
>
>> Hi
>>
>>> Unconfirmed transactions are incredibly important for real world
>> use.
>>
>>> Merchants for instance are willing to accept credit card payments
>> of
>>
>>> thousands of dollars and ship the goods despite the fact that the
>>
>>> transaction can be reversed up to 60 days later. There is a very
>> large
>>
>>> cost to losing the ability to have instant transactions in many or
>>
>>> even most situations. This cost is typically well above the fraud
>> risk.
>>
>>>
>>
>>> It's important to recognize that bitcoin serves a wide variety of
>> use
>>
>>> cases with different profiles for time sensitivity and fraud risk.
>>
>>>
>>
>> I agree that unconfirmed transactions are incredibly important, but
>> not
>>
>> over SPV against random peers.
>>
>> If you offer users/merchants a feature (SPV 0-conf against random
>>
>> peers), that is fundamentally insecure, it will – sooner or later
>> – lead
>>
>> to some large scale fiasco, hurting Bitcoins reputation and trust
>> from
>>
>> merchants.
>>
>> Merchants using and trusting 0-conf SPV transactions (retrieved from
>>
>> random peers) is something we should **really eliminate** through
>>
>> education and by offering different solution.
>>
>> There are plenty, more sane options. If you can't run your own
>> full-node
>>
>> as a merchant (trivial), maybe co-use a wallet-service with
>> centralized
>>
>> verification (maybe use two of them), I guess Copay would be one of
>>
>> those wallets (as an example). Use them in watch-only mode.
>>
>> For end-users SPV software, I think it would be recommended to...
>>
>> ... disable unconfirmed transactions during SPV against random peers
>>
>> ... enable unconfirmed transactions when using SPV against a trusted
>>
>> peer with preshared keys after BIP150
>>
>> ... if unconfirmed transactions are disabled, show how it can be
>> enabled
>>
>> (how to run a full-node [in a box, etc.])
>>
>> ... educate, inform users that a transaction with no confirmation
>> can be
>>
>> "stopped" or "redirected" any time, also inform about the risks
>> during
>>
>> low-conf phase (1-5).
>>
>> I though see the point that it's nice to make use of the "incoming
>>
>> funds..." feature in SPV wallets. But – for the sake of stability
>> and
>>
>> (risk-)scaling – we may want to recommend to scarify this feature
>> and –
>>
>> in the same turn – to use privacy-preserving BFD's.
>>
>> </jonas>

2023-06-07 19:55:05

- reply

📅 Original date posted:2017-01-03
📝 Original message:Unfortunately a non validating SPV wallet has absolutely no idea if
the information about an unconfirmed transaction they are seeing is
anything but properly formatted. They are connecting to an easily
manipulated, sybil attacked, and untrusted network and then asking
them for financial information. Seeing an unconfirmed transaction in a
wallet that's not also fully validating is at best meaningless.
On 2017-01-03 15:46, Aaron Voisine wrote:
> If the sender doesn't control the receiver's network connection, then
> the information the receiver gains by watching the mempool is if the
> transaction has propagated across the bitcoin network. This is useful
> to know in all kinds of situations.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet [2]
> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx at awsomnet.org> wrote:
>
>> Mempool transactions have their place, but "unconfirmed" and "SPV"
>> don't belong together. Only a full node can tell if a transaction
>> may get confirmed, or is nonsense. Unfortunately all the light /
>> SPV wallets I know of show mempool transactions, which makes it hard
>> to go back... (e.g. "why doesn't your software show 0-conf! your
>> wallet is broken!", somewhat akin to people complaining about RBF)
>>
>> So, this is easy, just don't worry about mempool filtering. Why are
>> light clients looking at the mempool anyway? Maybe if there were
>> some way to provide SPV proofs of all inputs, but that's a bit of a
>> mess for full nodes to do.
>>
>> Without mempool filtering, I think the committed bloom filters would
>> be a great improvement over the current bloom filter setup,
>> especially for lightning network use cases (with lightning, not
>> finding out about a transaction can make you lose money). I want to
>> work on it and may be able to at some point as it's somewhat related
>> to lightning.
>>
>> Also, if you're running a light client, and storing the filters the
>> way you store block headers, there's really no reason to go all the
>> way back to height 0. You can start grabbing headers at some point
>> a while ago, before your set of keys was generated. I think it'd be
>> very worth it even with GB-scale disk usage.
>>
>> -Tadge
>>
>> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Unconfirmed transactions are incredibly important for real world
>> use. Merchants for instance are willing to accept credit card
>> payments of thousands of dollars and ship the goods despite the fact
>> that the transaction can be reversed up to 60 days later. There is a
>> very large cost to losing the ability to have instant transactions
>> in many or even most situations. This cost is typically well above
>> the fraud risk.
>>
>> It's important to recognize that bitcoin serves a wide variety of
>> use cases with different profiles for time sensitivity and fraud
>> risk.
>>
>> Aaron
>>
>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The concept combined with the weak blocks system where miners commit
>>
>> to potential transaction inclusion with fractional difficulty blocks
>>
>> is possible. I'm not personally convinced that unconfirmed
>> transaction
>>
>> display in a wallet is worth the privacy trade-off. The user has
>> very
>>
>> little to gain from this knowledge until the txn is in a block.
>>
>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>
>>> Hi
>>
>>>> We introduce several concepts that rework the lightweight Bitcoin
>>
>>>> client model in a manner which is secure, efficient and privacy
>>
>>>> compatible.
>>
>>>>
>>
>>>> The BFD can be used verbatim in replacement of BIP37, where the
>> filter
>>
>>>> can be cached between clients without needing to be recomputed.
>> It can
>>
>>>> also be used by normal pruned nodes to do re-scans locally of
>> their
>>
>>>> wallet without needing to have the block data available to scan,
>> or
>>
>>>> without reading the entire block chain from disk.
>>
>>> I started exploring the potential of BFD after this specification.
>>
>>>
>>
>>> What would be the preferred/recommended way to handle
>> 0-conf/mempool
>>
>>> filtering – if & once BDF would have been deployed (any type,
>>
>>> semi-trusted oracles or protocol-level/softfork)?
>>
>>>
>>
>>> From the user-experience perspective, this is probably pretty
>> important
>>
>>> (otherwise the experience will be that incoming funds can take
>> serval
>>
>>> minutes to hours until they appear).
>>
>>> Using BIP37 bloom filters just for mempool filtering would
>> obviously
>>
>>> result in the same unwanted privacy-setup.
>>
>>>
>>
>>> </jonas>
>>
>>>
>>
>>>
>>
>>> _______________________________________________
>>
>>> bitcoin-dev mailing list
>>
>>> bitcoin-dev at lists.linuxfoundation.org
>>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>
>> _______________________________________________
>>
>> bitcoin-dev mailing list
>>
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] http://breadwallet.com

2023-06-07 19:55:04

- reply

📅 Original date posted:2017-01-03
📝 Original message:The concept was not particularly targeted towards businesses, but
allowing for significantly improved wallet performance and reducing
privacy for lite clients. You would expect that a business has the
capacity to run a fully validating, fully storing node of their own.
If they’re not something is fundamentally broken with Bitcoin, or
their rationale of continuing to use it.
On 2017-01-03 14:18, Aaron Voisine wrote:
> Unconfirmed transactions are incredibly important for real world use.
> Merchants for instance are willing to accept credit card payments of
> thousands of dollars and ship the goods despite the fact that the
> transaction can be reversed up to 60 days later. There is a very large
> cost to losing the ability to have instant transactions in many or
> even most situations. This cost is typically well above the fraud
> risk.
>
> It's important to recognize that bitcoin serves a wide variety of use
> cases with different profiles for time sensitivity and fraud risk.
>
> Aaron
>
> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The concept combined with the weak blocks system where miners commit
>>
>> to potential transaction inclusion with fractional difficulty blocks
>>
>> is possible. I'm not personally convinced that unconfirmed
>> transaction
>>
>> display in a wallet is worth the privacy trade-off. The user has
>> very
>>
>> little to gain from this knowledge until the txn is in a block.
>>
>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>
>>> Hi
>>
>>>> We introduce several concepts that rework the lightweight Bitcoin
>>
>>>> client model in a manner which is secure, efficient and privacy
>>
>>>> compatible.
>>
>>>>
>>
>>>> The BFD can be used verbatim in replacement of BIP37, where the
>> filter
>>
>>>> can be cached between clients without needing to be recomputed.
>> It can
>>
>>>> also be used by normal pruned nodes to do re-scans locally of
>> their
>>
>>>> wallet without needing to have the block data available to scan,
>> or
>>
>>>> without reading the entire block chain from disk.
>>
>>> I started exploring the potential of BFD after this specification.
>>
>>>
>>
>>> What would be the preferred/recommended way to handle
>> 0-conf/mempool
>>
>>> filtering – if & once BDF would have been deployed (any type,
>>
>>> semi-trusted oracles or protocol-level/softfork)?
>>
>>>
>>
>>> From the user-experience perspective, this is probably pretty
>> important
>>
>>> (otherwise the experience will be that incoming funds can take
>> serval
>>
>>> minutes to hours until they appear).
>>
>>> Using BIP37 bloom filters just for mempool filtering would
>> obviously
>>
>>> result in the same unwanted privacy-setup.
>>
>>>
>>
>>> </jonas>
>>
>>>
>>
>>>
>>
>>> _______________________________________________
>>
>>> bitcoin-dev mailing list
>>
>>> bitcoin-dev at lists.linuxfoundation.org
>>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>>
>> bitcoin-dev mailing list
>>
>> bitcoin-dev at lists.linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:55:03

- reply

📅 Original date posted:2017-01-03
📝 Original message:The concept combined with the weak blocks system where miners commit
to potential transaction inclusion with fractional difficulty blocks
is possible. I'm not personally convinced that unconfirmed transaction
display in a wallet is worth the privacy trade-off. The user has very
little to gain from this knowledge until the txn is in a block.
On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
> Hi
>> We introduce several concepts that rework the lightweight Bitcoin
>> client model in a manner which is secure, efficient and privacy
>> compatible.
>>
>> The BFD can be used verbatim in replacement of BIP37, where the filter
>> can be cached between clients without needing to be recomputed. It can
>> also be used by normal pruned nodes to do re-scans locally of their
>> wallet without needing to have the block data available to scan, or
>> without reading the entire block chain from disk.
> I started exploring the potential of BFD after this specification.
>
> What would be the preferred/recommended way to handle 0-conf/mempool
> filtering – if & once BDF would have been deployed (any type,
> semi-trusted oracles or protocol-level/softfork)?
>
> From the user-experience perspective, this is probably pretty important
> (otherwise the experience will be that incoming funds can take serval
> minutes to hours until they appear).
> Using BIP37 bloom filters just for mempool filtering would obviously
> result in the same unwanted privacy-setup.
>
> </jonas>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:50:26

- reply

📅 Original date posted:2016-05-09
📝 Original message:We introduce several concepts that rework the lightweight Bitcoin
client model in a manner which is secure, efficient and privacy
compatible.
Thea properties of BIP37 SPV [0] are unfortunately not as strong as
originally thought:
* The expected privacy of the probabilistic nature of bloom
filters does not exist [1][2], any user with a BIP37 SPV wallet
should be operating under no expectation of privacy.
Implementation flaws make this effect significantly worse, the
behavior meaning that no matter how high the false positive
rate (up to simply downloading the whole blocks verbatim) the
intent of the client connection is recoverable.
* Significant processing load is placed on nodes in the Bitcoin
network by lightweight clients, a single syncing wallet causes
(at the time of writing) 80GB of disk reads and a large amount
of CPU time to be consumed processing this data. This carries
significant denial of service risk [3], non-distinguishable
clients can repeatedly request taxing blocks causing
reprocessing on every request. Processed data is unique to every
client, and can not be cached or made more efficient while
staying within specification.
* Wallet clients can not have strong consistency or security
expectations, BIP37 merkle paths allow for a wallet to validate
that an output was spendable at some point in time but does not
prove that this output is not spent today.
* Nodes in the network can denial of service attack all BIP37 SPV
wallet clients by simply returning null filter results for
requests, the wallet has no way of discerning if it has been
lied to and may be made simply unaware that any payment has been
made to them. Many nodes can be queried in a probabilistic manor
but this increases the already heavy network load with little
benefit.
We propose a new concept which can work towards addressing these
shortcomings.
A Bloom Filter Digest is deterministically created of every block
encompassing the inputs and outputs of the containing transactions,
the filter parameters being tuned such that the filter is a small
portion of the size of the total block data. To determine if a block
has contents which may be interesting a second bloom filter of all
relevant key material is created. A binary comparison between the two
filters returns true if there is probably matching transactions, and
false if there is certainly no matching transactions. Any matched
blocks can be downloaded in full and processed for transactions which
may be relevant.
The BFD can be used verbatim in replacement of BIP37, where the filter
can be cached between clients without needing to be recomputed. It can
also be used by normal pruned nodes to do re-scans locally of their
wallet without needing to have the block data available to scan, or
without reading the entire block chain from disk.
-
For improved probabilistic security the bloom filters can be presented
to lightweight clients by semi-trusted oracles. A client wallet makes
an assumption that they trust a set, or subset of remote parties
(wallet vendors, services) which all all sign the BFD for each block.
The BFD can be downloaded from a single remote source, and the hash of
the filters compared against others in the trust set. Agreement is a
weak suggestion that the filter has not been tampered with, assuming
that these parties are not conspiring to defraud the client.
The oracles do not learn any additional information about the client
wallet, the client can download the block data from either nodes on
the network, HTTP services, NTTP, or any other out of band
communication method that provides the privacy desired by the client.
-
The security model of the oracle bloom filter can be vastly improved
by instead committing a hash of the BFD inside every block as a soft-
fork consensus rule change. After this, every node in the network would
build the filter and validate that the hash in the block is correct,
then make a conscious choice discard it for space savings or cache the
data to disk.
With a commitment to the filter it becomes impossible to lie to
lightweight clients by omission. Lightweight clients are provided with
a block header, merkle path, and the BFD. Altering the BFD invalidates
the merkle proof, it's validity is a strong indicator that the client
has an unadulterated picture of the UTXO condition without needing to
build one itself. A strong assurance that the hash of the BFD means
that the filters can be downloaded out of band along with the block
data at the leisure of the client, allowing for significantly greater
privacy and taking load away from the P2P Bitcoin network.
Committing the BFD is not a hard forking change, and does not require
alterations to mining software so long as the coinbase transaction
scriptSig is not included in the bloom filter.
[0] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
[1] https://eprint.iacr.org/2014/763.pdf
[2] https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
[3] https://github.com/petertodd/bloom-io-attack