On 1/3/17, Jonas Schnelli via bitcoin-dev
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 examp
On 01/04/2017 12:06 AM, adiabat via bitcoin-dev wrote:
> 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
I would assume that the controversial part of op_cat comes from the fact
that it enables covenants. Are there more concerns than that?
On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> For the record, the OP_CAT limit of 520 bytes was added
I think this discussion started from the block bloom filter where
there is a bloom filter commitment in the block which can be
downloaded and is much smaller than the block. An SPV node based on
that model would download headers and bloom filters, verify the bloom
filter is committed to, and test
There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?
Now I feel I was miss
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 ha
