Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Andreas Schildbach via bitcoin-dev]

Most SPV wallets make it quite clear that unconfirmed transactions are
just that.


On 06/19/2017 06:36 PM, adiabat via bitcoin-dev wrote:
> This has been brought up several times in the past, and I agree with
> Jonas' comments about users being unaware of the privacy losses due to
> BIP37.  One thing also mentioned before but not int he current thread
> is that the entire concept of SPV is not applicable to unconfirmed
> transactions.  SPV uses the fact that miners have committed to a
> transaction with work to give the user an assurance that the
> transaction is valid; if the transaction were invalid, it would be
> costly for the miner to include it in a block with valid work.
> 
> Transactions in the mempool have no such assurance, and are costlessly
> forgeable by anyone, including your ISP.  I wasn't involved in any
> debate over BIP37 when it was being written up, so I don't know how
> mempool filtering got in, but it never made any sense to me.  The fact
> that lots of lite clients are using this is a problem as it gives
> false assurance to users that there is a valid but yet-to-be-confirmed
> transaction sending them money.
> 
> -Tadge
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat

[Moral Agent via bitcoin-dev]

Here is the text of a post to reddit from Feb 2017, discussing a similar
idea, and wondering if it could reduce the incentive to delay broadcast of
solved blocks:

# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain

# Steps:

1. Soft fork Bitcoin to enable side chains

2. Create a side chain that is secured with Proof of Stake. Call blocks on
this chain "POS-blocks." The original chain is made of "POW-blocks."

3. Side chain mints one POS-block after each POW-block on the main chain,
and contains the hash of the POW-block, and the hash of the previous
POS-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png
)

4. Side chain Minters must make a deposit in order to mint. If they mint an
invalid POS-block, they lose the deposit.

5. Side chain blocks are small enough to broadcast and validate quickly
(e.g. 100 - 300 KB).

6. Soft fork a new rule into Bitcoin that encourages POW-blocks to include
the hash of the prior POS-block. Specifically, penalize POW-blocks which do
not point to the prior POS-block by doubling the difficulty necessary for
them to be valid. Call POW-blocks which do not point to the prior POS-block
but are valid because of their very high POW "hard blocks."

In the following diagram POW2 and POW4 are valid because they point to the
prior POS-block and also satisfy the difficulty requirement. POW3 does not
point to the prior POS-bock, but is valid anyway because it contains proof
of work at twice the normal difficulty.

https://s27.postimg.org/6hc0b8ejn/Pos_Sf2.png

# Advantages:

1. Allow people who do not control ASICs to influence which transactions
happen.

2. Allow people who do not control ASICs to influence which chain gets
extended.

3. Reduce the incentive to selfish mine. Once a miner discovers a block,
they should broadcast it immediately in the hopes that a Minter will build
on it, because that is the most likely way their block will not go stale.
Miners will also immediately start trying to build a hard block. (Maybe
statistics could tell us what is the proper range for the Hardness
Multiplier. I guessed 2 would be good.)

4. Reduces the effective block interval while reducing the incidence of
stale blocks, empty blocks and SPV mining. After a POW-block is mined, it
is immediately broadcast to the network, seeking a qualified Minter to
extend it. Minters have a deposit, which they will lose if they mint an
invalid block. Pointing to the hash of an invalid POW-block would produce
an invalid minted block, so Minters have a strong incentive to completely
validate the POW-block before they mint on top of it. After validating,
they mint a block and broadcast it. While the Minter is validating the
previous POW-block, competing miners also have time to fully validate the
previous POW-block. By the time the Miners receive the POS-block, they know
what transactions they can and cannot include in their own block, because
the Minter only processes transactions on the side chain. There is less
reason to mine empty blocks, because there is adequate time to update the
mempool before mining the next soft block begins, and because hard blocks
take a long time to produce. The risks involved with mining on an
un-validated POS-block can be made small by the fact that there is a
deposit that will be destroyed if the POS-block is invalid. POS-blocks can
be validated quickly because they are small.

Here is a gantt chart of the schedule described above:

https://s22.postimg.org/hvnkyac5d/Pos_Sf3.png

5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaply
hatch an alternate history. Much less imperative for nodes to go to a
trusted peer and ask whether the chain they are being fed is legitimate.

6. After step 6 above, the side chain would have essentially the same
security characteristics as the main chain, and could be used
interchangeably.

7. No hard fork required, and this soft fork could be deployed even if the
miners do not consent to it. Some hybrid POS system would be my
recommendation as preferable to simply changing POW algorithms in the face
of miners abusing their power.

8. Users can opt into the POS sidechain, and it can fully prove itself in
production before there is any attempt to anchor the main chain back to it.
Even if consensus cannot be obtained to execute step 6, the mere existence
of such a chain could deter tomfoolery on the part of POW miners, lest they
galvanize the community into throwing the switch.

Original reddit post here:

https://www.reddit.com/r/Bitcoin/comments/5vy4qc/how_an_anchored_proof_of_stake_sidechain_can_help/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)

[Mark Friedenbach via bitcoin-dev]

It is essential that BIP-148 nodes connect to at least two other BIP-148 nodes 
to prevent a network partition in August 1st. The temporary service but is how 
such nodes are able to detect each other.

> On Jun 19, 2017, at 12:46 PM, Tom Zander via bitcoin-dev 
>  wrote:
> 
>> On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
>> To ease the transition to BIP148 and to minimise risks in the event miners
>> choose to perform a chain split attack, at least Bitcoin Knots will be
>> using the temporary service bit (1 << 27) to indicate BIP148 support.
>> 
>> Once the transition is complete, this will no longer be necessary, and the
>> bit will be (manually) returned for reuse.
>> 
>> I encourage other software implementing BIP148 (both full and light nodes)
>> to set and use this service bit to avoid network partitioning risks.
> 
> I'm curious what you action on the finding (or not) of a peer with this bit 
> set (or not).
> Can you link to the github commit where you implemented this?
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
> To ease the transition to BIP148 and to minimise risks in the event miners
> choose to perform a chain split attack, at least Bitcoin Knots will be
> using the temporary service bit (1 << 27) to indicate BIP148 support.
> 
> Once the transition is complete, this will no longer be necessary, and the
> bit will be (manually) returned for reuse.
> 
> I encourage other software implementing BIP148 (both full and light nodes)
> to set and use this service bit to avoid network partitioning risks.

I'm curious what you action on the finding (or not) of a peer with this bit 
set (or not).
Can you link to the github commit where you implemented this?
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP148 temporary service bit (1 << 27)

[Luke Dashjr via bitcoin-dev]

To ease the transition to BIP148 and to minimise risks in the event miners 
choose to perform a chain split attack, at least Bitcoin Knots will be using 
the temporary service bit (1 << 27) to indicate BIP148 support.

Once the transition is complete, this will no longer be necessary, and the bit 
will be (manually) returned for reuse.

I encourage other software implementing BIP148 (both full and light nodes) to 
set and use this service bit to avoid network partitioning risks.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat

[Peter Todd via bitcoin-dev]

On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote:
> There has been proposal to change the PoW in case of potential 51% attacks
> from malicious miners during a fork. But such a change in PoW renders
> multi-billion-dollar of ASIC into worthless. which hurts economy so much
> and the average innocent mining users. I would propose, instead of PoW
> change, we could change the system to the same double sha256 PoW but mix it
> with PoS features. Such a PoW+PoS system has several advantages:


You have to specify what you mean by "PoS" - there's dozens of variations.
Equally, existing pure PoS schemes probably don't make sense as a "bolt-on"
add-on, as once you introduce PoW to it you should design something that uses
the capabilities of both systems.

FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure PoS
and are now trying to design a PoW + staking system instead.

> * It protects existing multi-billion dollar investments from innocent
> mining users,

To be clear, you mean such a scheme would protect the multi-billion dollar
investments non-malicious miners have made in SHA256^2 hardware by ensuring it
remains useful, right?

> * A malicious miner cannot launch attacks and rewrite the blockchain with
> 51% or even more hashrate,
> * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block
> time span, that solves the long confirmation time problem,

Note that if those PoS blocks are *pure* PoS, you'll create a significant risk
of double-spend attacks, as there's zero inherent cost to creating a pure-PoS
block. Such blocks can't be relied on for confirmations; even "slasher" schemes
have significant problems with sybil attacks.

> * We'll suddenly have 5 times of block space, that solves the scaling
> problem,

The scaling problem is one of scalability; PoS does nothing to improve
scalability (though many in the ETH community have been making dishonest
statements to the contrary).

> * The PoS blocks only mine transaction fees, so the 21M cap remains,
> * With careful design, the PoW+PoS transition _might_ be able to deploy
> with a soft fork.

As a sidechain yes, but in what you propose above the extra blocks wouldn't
contain transactions that non-PoS-aware nodes could understand in a
backwards-compatible way.


All the above aside, I don't think it's inherently wrong to look at adding PoS
block *approval* mechanisms, where a block isn't considered valid without some
kind of coin owner approval. While pure-PoS is fundamentally broken in a
decentralized setting, it may be possible to mitigate the reasons it's broken
with PoW and get a system that has a stronger security model than PoW alone.

FWIW there's some early discussions by myself and others about this type of
approach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] An alternative way to protect the network from 51% attacks threat

[Wang Chun via bitcoin-dev]

There has been proposal to change the PoW in case of potential 51% attacks
from malicious miners during a fork. But such a change in PoW renders
multi-billion-dollar of ASIC into worthless. which hurts economy so much
and the average innocent mining users. I would propose, instead of PoW
change, we could change the system to the same double sha256 PoW but mix it
with PoS features. Such a PoW+PoS system has several advantages:
* It protects existing multi-billion dollar investments from innocent
mining users,
* A malicious miner cannot launch attacks and rewrite the blockchain with
51% or even more hashrate,
* If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block
time span, that solves the long confirmation time problem,
* We'll suddenly have 5 times of block space, that solves the scaling
problem,
* The PoS blocks only mine transaction fees, so the 21M cap remains,
* With careful design, the PoW+PoS transition _might_ be able to deploy
with a soft fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 18:30:18 CEST Jonas Schnelli wrote:
> I personally would ALWAYS [snip]

I mentioned that it was a usability point for a reason, and your personal 
behavior makes me want to quote one of the main UX guidelines; 
  “You are not your user”

http://uxmyths.com/post/715988395/myth-you-are-like-your-users
older;
http://52weeksofux.com/post/385981879/you-are-not-your-user

I think we should defer to actual real numbers and user reseach, as has been 
quoted by Andreas. You disagreeing based on your own experience and behavior 
is worse than useless. As the above links show.

Don’t fall in that trap :)
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[adiabat via bitcoin-dev]

This has been brought up several times in the past, and I agree with
Jonas' comments about users being unaware of the privacy losses due to
BIP37.  One thing also mentioned before but not int he current thread
is that the entire concept of SPV is not applicable to unconfirmed
transactions.  SPV uses the fact that miners have committed to a
transaction with work to give the user an assurance that the
transaction is valid; if the transaction were invalid, it would be
costly for the miner to include it in a block with valid work.

Transactions in the mempool have no such assurance, and are costlessly
forgeable by anyone, including your ISP.  I wasn't involved in any
debate over BIP37 when it was being written up, so I don't know how
mempool filtering got in, but it never made any sense to me.  The fact
that lots of lite clients are using this is a problem as it gives
false assurance to users that there is a valid but yet-to-be-confirmed
transaction sending them money.

-Tadge
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

>> 
>> I think many users would be willing ...
>> a) … to trade higher privacy (using client side filtering) for not having
>> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
>> all inved transactions
> 
> You seem to misunderstand the usecase.
> If you send me a transaction, both of use are using our phones, then I need
> to be able to have immediate feedback on the transaction being broadcast on
> the network.
> This is not about zero-conf, this is simple seeing what is happening while
> it is happening.
> 
> Additionally, when the transaction that is meant for my wallet is broadcast,
> I want my SPV wallet to parse and check the actual transaction.
> It is not just to see that *something* was actually send, but also to be
> able to see how much is being paid to me. Maybe If the transaction is marked
> as RBF-able, etc.
> 
> Really basic usability: provide information to your users when you can,
> should they want to, and by default on.

I see this use case.
But I did receive bank wire transfers for the last decades without 
_immediately_ knowing that someone sent funds to me.
I personally would ALWAYS trade the higher bandwidth consumption (300MB mempool 
filtering) or slower notification time (maybe ~1h) for preserving privacy.
I agree, there are use cases where you want immediate notification, those use 
cases could probably be solved by not trowing away privacy („parsing“ all 
transactions and running in the background).

/jonas


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

> 
> On the other hand, I remember only 1 (one) inquiry about the privacy
> problems of BIP37 (or privacy at all).

IMO privacy its something developers should make sure users have it.
Also, I think, todays SPV wallets should make users more aware of the possible 
privacy implications.

Do users know, if they pay for a good in a shop while consuming the shops WIFI, 
that the shop-owner as well as the ISP can use that data to combine it with the 
user profile (and ~ALL FUTURE purchases you do with the same wallet IN ANY 
LOCATION online or in-person)?

Do users know, that ISPs (cellular; including Google) can completely link the 
used Bitcoin wallet (again: all purchase including future ones) with the to the 
ISP well known user profile including credit-card data and may sell the Bitcoin 
data to any other data mining company?

If you use BIP37, you basically give your transaction history (_ALL 
TRANSACTIONS_ including transactions in future) to everyone.


> 
> From a regular user's point of view, privacy is non-issue. Sure,
> everyone would take it for free, but certainly not if it a) delays
> incoming payments or b) quickly eats up your traffic quota.

This may be true because they are not aware of the ramification and I don’t 
think client side filtering is a drop-in replacement for todays, smartphone 
SPV-model.


/jonas


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote:
> Hi
> 
> > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> >> It's been debated if [filtering of] unconfirmed transactions are
> >> necessary,
> > 
> > Why would it not be needed? Any SPV client (when used as a
> > payment-receiver) requires this from a simple usability point of view.
> 
> I think many users would be willing ...
> a) … to trade higher privacy (using client side filtering) for not having
> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
> all inved transactions

You seem to misunderstand the usecase.
If you send me a transaction, both of use are using our phones, then I need 
to be able to have immediate feedback on the transaction being broadcast on 
the network.
This is not about zero-conf, this is simple seeing what is happening while 
it is happening.

Additionally, when the transaction that is meant for my wallet is broadcast, 
I want my SPV wallet to parse and check the actual transaction.
It is not just to see that *something* was actually send, but also to be 
able to see how much is being paid to me. Maybe If the transaction is marked 
as RBF-able, etc.

Really basic usability: provide information to your users when you can, 
should they want to, and by default on.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

> Just to give you a number: based on the statistics of the Bitcoin Wallet
> app there are at least 2 million wallets depending on BIP37. Not all
> would need instant notification but based on the daily support enquiries
> instant notificaton is the most asked property of Bitcoin.

Yes. Users probably like this feature and client side filtering is not a 
drop-in replacement for BIP37.

We should also consider:
BIP37 works, because node-operators are willing to offer that service for free 
(which maybe change over time).
BIP37 consumes plenty of horsepower (disk/cpu) from nodes. Filtering a couple 
of days of blocks (assume 1000+) eats lots of resources for something, that has 
no direct long-term value for Bitcoin (the filters data is unique and will be 
"thrown away“ [can’t be used by other peers]). Same applies for mempool 
(filtering mempool of a couple of hundred of mb each time the HD gap limit has 
been exceeded or the app gets sent to the foreground again).

Purely relying on the availability of BIP37 seems fragile to me and start to 
explore other ways is very reasonable.

/jonas


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc via bitcoin-dev]

Hi Greg,

Responses below:

On 6/18/2017 5:30 PM, Tao Effect wrote:
> In Drivechain, 51% of miners have total control and ownership over all
> of the sidechain coins.

It would not be accurate to say that miners have "total" control. Miners
do control the destination of withdrawals, but they do not control the
withdrawal-duration nor the withdrawal-frequency.

So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
theft, but they can not change the fact that their malfeasance will be
[a] obvious, and [b] on display for a long period of time.

We might draw a comparison between:

1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
chain to double-spend funds (or coordinate with someone who is
double-spending). This is prevented/discouraged by waiting for many
confirmations.
2. Channel Theft -- A majority hashrate assists a Lightning-Network
thief, by censoring the punitive audit txn (possibly by exploiting some
excuse regarding fullness of blocks, or possibly induced to do so by the
thief provably splitting the proceeds with miners). This is
prevented/discouraged by using lengthy custodial periods, paying high
fees with your attacker's money, and using fungibility/non-communication
to interact with miners as little as possible (so as to frame LN-theft
as undermining the entire LN system, and not merely a single tragedy).
3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
withdrawal from some sidechain. This is prevented/discouraged by only
using 'popular' sidechains (those that [a] increase the usefulness
("market price") of bitcoin, and [b] generate tx fees for miners). It is
also discouraged by the fact that egregious theft would probably end the
sidechain experiment, meaning that all present and future sidechains
would be forever unavailable (and unable to buoy the price or the tx
revenues).

I do not think that any of the three stands out as being categorically
worse than the others, especially when we consider the heterogeneity of
use-cases and preferences. As Luke-Jr has been pointing out on social
media recently, the very group which is more associated with miners (and
explicitly more willing to trust them, ie Bitcoin Unlimited et al),
happens to be the same group that would be expected to make use of a
LargeBlock drivechain. Some can argue that one type of security is more
"cryptographic" than others, but I think this is misguided (how many
'bits' of security does each have?) -- imho, all three security models
are 'game theoretic' (neither computer scientific, nor cryptographic).

More importantly, before a miner has any "control" over the sidechain
coins, users must voluntarily agree to subject themselves to these new
rules. This is similar to how an arbitrary piece of (open source)
software can have "total" control over your computer...if you choose to
install it.

> Thus the effect of Drivechain appears to be the creation of a new kind
> of digital border imposed onto the network ...

I'm not sure it would "create a border", given that sidechains are
currently not accessible at all. If anything drivechain cuts a door into
an existing impassible border.

>  ... where everyone hands over ownership of their Bitcoins to a
> /single/ mining cartel when they wish to interact with /any/ sidechain.

The qualifier "/any/ sidechain" would seem to imply that there is a way
to do sidechains that does not involve handing over some control to 51%
hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
The first thing I do in the drivechain spec (
truthcoin.info/blog/drivechain ) is explain why.

> Drivechain would be a reasonable idea if that weren't the case, but
> since it is, Drivechain now introduces a very real possible future
> where Bitcoins can be confiscated by the Chinese government in exactly
> the same manner that the Chinese government today confiscates
> financial assets in other financial networks within China.

Yes, but money could also be confiscated from _any_ Bitcoin users
(Chinese or otherwise) using any of the three methods I mentioned above.
And confiscation could strike Chinese Bitcoin users if they decided to
sell their Bitcoin for Chinese Yuan, which they then deposited in a
Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
the Chinese govt in some other way.

It is not up to the members of this list to decide, USSR style, what
other people are allowed to do with their own money.

The exceptions to this rule would be (ie, "bitcoin-dev should care about
what users are doing when..."):

1. [Unreasonable use of Reviewer Time]  The user's use-case is either
nonexistent (ie "no one wants that"), or totally unachievable ("we can't
do that") thus rendering the conversation a complete waste of time /
reviewer attention.
2. [Harmful Interference] The user's use-case would impose harm on some
existing use-case(s).

No reasonable person will claim the first, given today's scaling debate
(not to 

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Andreas Schildbach via bitcoin-dev]

On 06/19/2017 05:49 PM, Jonas Schnelli via bitcoin-dev wrote:

>>> It's been debated if [filtering of] unconfirmed transactions are
>>> necessary,
>>
>> Why would it not be needed? Any SPV client (when used as a payment-receiver)
>> requires this from a simple usability point of view.
> 
> 
> I think many users would be willing ...
> a) … to trade higher privacy (using client side filtering) for not having the 
> „incoming transaction“ feature
> b) – if they want 0-conf – to fetch all inved transactions

Another number: I'm answering dozens of support inquiries about
delayed/missing transactions per day. Over the 7 years of Bitcoin
Wallet's existence, I estimate about 5 inquiries.

On the other hand, I remember only 1 (one) inquiry about the privacy
problems of BIP37 (or privacy at all).

From a regular user's point of view, privacy is non-issue. Sure,
everyone would take it for free, but certainly not if it a) delays
incoming payments or b) quickly eats up your traffic quota.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Jonas Schnelli via bitcoin-dev]

Hi

> On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
>> It's been debated if [filtering of] unconfirmed transactions are
>> necessary,
> 
> Why would it not be needed? Any SPV client (when used as a payment-receiver)
> requires this from a simple usability point of view.


I think many users would be willing ...
a) … to trade higher privacy (using client side filtering) for not having the 
„incoming transaction“ feature
b) – if they want 0-conf – to fetch all inved transactions
/jonas


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart via bitcoin-dev]

>
> Since the sidechain has the sidechain BMM headers that they want the LD
> (bribe) data for, I think that they could specifically request LD data
> relevant only to that sidechain by providing a list of hashes to the
> mainchain, and the mainchain can return a list of boolean values telling
> the sidechain if the LD data exists. That way the data never even has to
> go over the network, just a verification that it exists on the mainchain
> and
>

Since you seem to be talking about the initial block download process for
the drivechain. It seems that we might as well request the set of *valid*
blocks from a bitcoin peer first, since at the end of the day they are in
control of the mining process on the sidechain. Here is what I envision:

   1. Request all hashes for sidechain from a bitcoin peer
   2. Request all sidechain block header's for the hashes the bitcoin peer
   gave us
   3. Order the set of sidechain block headers by looking at hashPrevBlock.
   4. Request full sidechain blocks and start validating against the
   consensus rule set of the sidechain


we can drop the sidechain_id from the script.

I agree the 'sidechain_id' is unneeded in the coinbase tx output. We should
just fix these based on index. This should be reflected in my latest commit
if we are talking about the same thing:
https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254


and have the sidechain handle filtering out invalid LD data /
> only requesting the verification of LD data that they know to be valid
> as far as chain order goes.
>

 I agree, the whole point of BMM is to have bitcoin miners indifferent to
what happens in the sidechain (although Paul argues in a wonky way they do
care sort of). If there is an invalid (in the sense the block it represents
does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
that a 'blind' bitcoin miner will choose the one that pays them the most
money.

>I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

I'm fairly certain you are right. It just feels like we should be able to
exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
I'll have to think about this more, maybe some one else can come up with
something clever that exploits that fact.

On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewart  wrote:

> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that they could specifically request LD data
>> relevant only to that sidechain by providing a list of hashes to the
>> mainchain, and the mainchain can return a list of boolean values telling
>> the sidechain if the LD data exists. That way the data never even has to
>> go over the network, just a verification that it exists on the mainchain
>> and
>>
>
> Since you seem to be talking about the initial block download process for
> the drivechain. It seems that we might as well request the set of *valid*
> blocks from a bitcoin peer first, since at the end of the day they are in
> control of the mining process on the sidechain. Here is what I envision:
>
>1. Request all hashes for sidechain from a bitcoin peer
>2. Request all sidechain block header's for the hashes the bitcoin
>peer gave us
>3. Order the set of sidechain block headers by looking at
>hashPrevBlock.
>4. Request full sidechain blocks and start validating against the
>consensus rule set of the sidechain
>
>
> we can drop the sidechain_id from the script.
>
> I agree the 'sidechain_id' is unneeded in the coinbase tx output. We
> should just fix these based on index. This should be reflected in my latest
> commit if we are talking about the same thing: https://github.com/
> Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a9
> 7710feb032/src/script/script.cpp#L254
>
>
> and have the sidechain handle filtering out invalid LD data /
>> only requesting the verification of LD data that they know to be valid
>> as far as chain order goes.
>>
>
>  I agree, the whole point of BMM is to have bitcoin miners indifferent to
> what happens in the sidechain (although Paul argues in a wonky way they do
> care sort of). If there is an invalid (in the sense the block it represents
> does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
> pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
> that a 'blind' bitcoin miner will choose the one that pays them the most
> money.
>
> >I might be wrong but I thought that OP_RETURN outputs do not go into the
> UTXO set. Anyone else want to chime in?
>
> I'm fairly certain you are right. It just feels like we should be able to
> exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
> I'll have to think about this more, maybe some one else can come up with
> 

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Andreas Schildbach via bitcoin-dev]

Just to give you a number: based on the statistics of the Bitcoin Wallet
app there are at least 2 million wallets depending on BIP37. Not all
would need instant notification but based on the daily support enquiries
instant notificaton is the most asked property of Bitcoin.


On 06/19/2017 02:26 PM, bfd--- via bitcoin-dev wrote:
> 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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
>  It's been debated if [filtering of] unconfirmed transactions are
> necessary,

Why would it not be needed? Any SPV client (when used as a payment-receiver) 
requires this from a simple usability point of view.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[bfd--- via bitcoin-dev]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Andreas Schildbach via bitcoin-dev]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev