Re: [bitcoin-dev] Combining SPV and Stealth addresses

[Chris Pacia via bitcoin-dev]

Yes I've had it working using two pushes in op_return.

op_return op_pushdata  op_pushdata 

Flag goes in your filter. You anonymity set is all other transactions using
that same flag.

This is fairly decent privacy but the problem is you still need filter
matches on outgoing transactions to build a functioning wallet. So it might
not be an improvement over standard bloom filters but at least you can do
stealth if you want.

On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Recently I think a lot about combining Stealth addresses with SPV but
> I did not come to a satisfying conclusion, so I post this as a
> challenge to the wider community. Maybe you have an idea.
>
> ## Explanation of SPV
> In SPV a thin client puts his public keys in a bloom filter
> and asks a full node to give him Merkle proofs of all transactions
> whose pubkey are in the bloom filter. Since a bloom filter has a lot
> of false positives depending on the parameters, this gives privacy to
> the thin client, since the full node cannot detect if a specific
> transaction belongs to the thin client. This is cool if you want to
> use Bitcoin on your smartphone.
>
> ## Explanation of Stealth Addresses
> Stealth addresses on the other hand enable receiver privacy. The
> sender of a transaction derives a one-time pubkey to which he sends the
> money. The receiver can check if the money was sent to him and recover
> the one-time private key. This is cool, since an observer cannot
> decide if two payments belong to the same recipient. Further the
> recipient needs only to have one pubkey.
> For a more formal explanation see https://github.com/genjix/
> bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
> I will use their notation in the following.
>
> ## The Problem
> My line of thought was to combine stealth addresses with spv, so that
> I can use stealth addresses on my smart phone without losing privacy.
>
> Basically to check if a payment belongs to a pubkey (Q,R), the full
> node needs to check if R' = R + H(dP)*G for each transaction. For this
> it needs the private scanning key d.
> This sucks, since when I give my d to a full node, he can link all my
> transactions. For an online-wallet this may be okay, but not for thin
> client synchronisation.
>
> ## Ideas
> In the following I detail some ideas of me which did not work.
>
> It does not suffice to have a Bloom filter and check if d is
> contained since there is no way to recompute d from the equation. If
> there were a way to recompute d, the scheme would offer no privacy,
> since anyone could compute the private scanning key d and scan for
> payments.
> So, if we modify the scheme we need to be sure that d is kept private.
>
> Multiparty computation may be possible in theory. The full node and
> the thin client could collaboratively check R' = R + H(dP)*G, where d
> is the private input of the thin client and R, R',P is provided by the
> full node. But this is costly and they need to do it for each
> transaction. It may be more costly than simply setting up a full node.
>
> I do not think that some kind of search functionality without leaking
> the search pattern (PIR?) would work, since the full node needs to compute
> on the
> data it has found. And further it needs to retrieve the whole Merkle
> proofs.
>
> Any better ideas?
>
> Best,
> Henning
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> ___
> 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] Full node "tip" function

[Tom Zander via bitcoin-dev]

I agree with you here, Erik. Greg's standard answer doesn’t apply to your 
suggestion.
I think he was a bit too trigger happy because we have seen a lot of similar 
suggestions that have the Sybill issue he mentioned.


On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote:
> > Greg
> > The primary result would be paying people to sybil attack the network.
> 
> I cannot imagine the benefit to replicating an ip address in this case,
> except maybe you think that you would be more likely to be selected as a
> peer?   But there would be no actual advantage since download peers are
> selected based on throughput and actual blocks served.

-- 
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] Full node "tip" function

[Erik Aronesty via bitcoin-dev]

 - Full nodes already perform many valuable services, and simply allowing
people to pay for better service is something operators can do now - even
without it being baked into bitcoind.   Paying for access to a higher-speed
relay network, for example, is something that many operators would do.

- Baking in the ability to add service fees could make more people *want*
to run more high quality, highly available full nodes... which is really
one of the most important things developers can be doing.


On Thu, May 4, 2017 at 9:37 AM, Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Strange idea, incentiving people to run full nodes should certainly not
> depend on miners, should certainly not involve another wasteful pow and
> should certainly not encourage any collusion between participants like
> miners are doing (ie full nodes pools for example or miners creating full
> nodes pools)
>
> Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit :
>
> The ones that *could* pay non-mining full nodes are miners/pools, by
> outsourcing transaction selection using a different PoW.  By doing so they
> could buy proof-of-uncensored-selection and proof-of-goodwill for a small
> fee.
>
> We would allow full nodes to generate and broadcast a template block which:
>
> * Does not contain a valid header yet
> * Contains the transaction selection
> * Contains a coinbase output with a predetermined part of the block reward
> (say 0.5%) to themselves
> * Contains a nonce for PoW of a predetermined currently ASIC resistant
> hash function behind a OP_RETURN.
>
> The template with the highest PoW since the last block would be leading. A
> miner/pool can then choose to use this instead of their own, adding the
> rest of the reward and the SHA nonce themselves. That way they would set up
> a competition among full nodes.
>
> This would of course be voluntary but provable, so maybe in a pool's
> interest to do this via naming and shaming.
>
> Tomas
> bitcrust
>
> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
>
> I feel like this would be pointless as the vast majority of users would
> likely download the blockchain from a node that was not enforcing a tip
> requirement as it would seem like unnecessary cost as in protocols such as
> BitTorrent there is no such tips in sharing files and the blockchain
> distribution is in eccense the same thing. However perhaps I am
> underestimating the generosity of node operators but I feel that adding a
> cost to the blockchain (assuming that all users add a tip requirement)
> would lead to centralisation.
>
> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> IDEA:
> - Full nodes advertise a bitcoin address.   Users that need to download
> the block chain from that node can be encouraged to send a tip to the peers
> that served them (by % served).   Recommended tip of 10mbit should be fine.
>
> - A full nodes can *require* a tip to download the blockchain.  If they
> do, users that don't specify a tip cannot use them.
>
> CONS:
>
> For some people, this may represent a barrier to hosting their own full
> node.   After all, if you have to pay $15 just to get a copy of the
> blockchain, that just adds to the already expensive prospect of hosting a
> full node.
> PROS:
>
> As long as you manage to stay online, you should get your money back and
> more.   This is the an incentive for quality, long term hosting.
> In the long term, this should cause stable nodes to stick around longer.
> It also discourages "installation spam" attacks on the network.
> Fees for other node operations can be considered if this is successful.
>
>
>
>
> ___
> bitcoin-dev mailing 
> listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>
> ___
> 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] Full node "tip" function

[Aymeric Vitte via bitcoin-dev]

Yes, as a whole, but I am sorry, your "tip" proposal is very very very
bad as it is, think a little bit more about your latest answer and you
will understand why

I am a bit perplexed sometimes about what is proposed on this list

Adding services paid by the miners is not a bad idea, like some
proposals that were posted here proposing some system to validate/format
the blocks for the miners

But, first, the highest priority is to scale the full nodes and this
cannot depend on miners, then once this is done we can imagine other
services on top of it paid by the miners or others (+lightning & co)

I have already explained many times my thoughts on the subject, I don't
pretend that they represent the perfect solution but at least it's
different from what we can read , so I think that the core dev team
should setup a task force/group to solve this quickly now, the
accumulation of strange proposals/workarounds here does not help

Because it's a real question for everybody in the current context
whether we can trust bitcoin or not, unfortunately the answer currently
tends toward the later, or please explain me why this statement could be
wrong


Le 04/05/2017 à 15:47, Erik Aronesty a écrit :
>  - Full nodes already perform many valuable services, and simply
> allowing people to pay for better service is something operators can
> do now - even without it being baked into bitcoind.   Paying for
> access to a higher-speed relay network, for example, is something that
> many operators would do.
>
> - Baking in the ability to add service fees could make more people
> *want* to run more high quality, highly available full nodes... which
> is really one of the most important things developers can be doing.
>
>
> On Thu, May 4, 2017 at 9:37 AM, Aymeric Vitte via bitcoin-dev
>  > wrote:
>
> Strange idea, incentiving people to run full nodes should
> certainly not depend on miners, should certainly not involve
> another wasteful pow and should certainly not encourage any
> collusion between participants like miners are doing (ie full
> nodes pools for example or miners creating full nodes pools)
>
>
> Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit :
>> The ones that *could* pay non-mining full nodes are miners/pools,
>> by outsourcing transaction selection using a different PoW.  By
>> doing so they could buy proof-of-uncensored-selection and
>> proof-of-goodwill for a small fee.
>>
>> We would allow full nodes to generate and broadcast a template
>> block which:
>>
>> * Does not contain a valid header yet
>> * Contains the transaction selection
>> * Contains a coinbase output with a predetermined part of the
>> block reward (say 0.5%) to themselves
>> * Contains a nonce for PoW of a predetermined currently ASIC
>> resistant hash function behind a OP_RETURN.
>>
>> The template with the highest PoW since the last block would be
>> leading. A miner/pool can then choose to use this instead of
>> their own, adding the rest of the reward and the SHA nonce
>> themselves. That way they would set up a competition among full
>> nodes.
>>
>> This would of course be voluntary but provable, so maybe in a
>> pool's interest to do this via naming and shaming.
>>
>> Tomas
>> bitcrust
>>
>> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
>>> I feel like this would be pointless as the vast majority of
>>> users would likely download the blockchain from a node that was
>>> not enforcing a tip requirement as it would seem like
>>> unnecessary cost as in protocols such as BitTorrent there is no
>>> such tips in sharing files and the blockchain distribution is in
>>> eccense the same thing. However perhaps I am underestimating the
>>> generosity of node operators but I feel that adding a cost to
>>> the blockchain (assuming that all users add a tip requirement)
>>> would lead to centralisation.
>>>
>>> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
>>> >> > wrote:
>>>
>>> IDEA:
>>> - Full nodes advertise a bitcoin address.   Users that need
>>> to download the block chain from that node can be encouraged
>>> to send a tip to the peers that served them (by % served).  
>>> Recommended tip of 10mbit should be fine.
>>>
>>> - A full nodes can *require* a tip to download the
>>> blockchain.  If they do, users that don't specify a tip
>>> cannot use them.
>>>
>>> CONS:
>>>
>>> For some people, this may represent a barrier to hosting
>>> their own full node.   After all, if you have to pay $15
>>> just to get a copy of the blockchain, that just adds to the
>>> already expensive prospect of hosting a full node.  
>>> PROS:
>>>
>>> As long as you mana

Re: [bitcoin-dev] Full node "tip" function

[Aymeric Vitte via bitcoin-dev]

Strange idea, incentiving people to run full nodes should certainly not
depend on miners, should certainly not involve another wasteful pow and
should certainly not encourage any collusion between participants like
miners are doing (ie full nodes pools for example or miners creating
full nodes pools)


Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit :
> The ones that *could* pay non-mining full nodes are miners/pools, by
> outsourcing transaction selection using a different PoW.  By doing so
> they could buy proof-of-uncensored-selection and proof-of-goodwill for
> a small fee.
>
> We would allow full nodes to generate and broadcast a template block
> which:
>
> * Does not contain a valid header yet
> * Contains the transaction selection
> * Contains a coinbase output with a predetermined part of the block
> reward (say 0.5%) to themselves
> * Contains a nonce for PoW of a predetermined currently ASIC resistant
> hash function behind a OP_RETURN.
>
> The template with the highest PoW since the last block would be
> leading. A miner/pool can then choose to use this instead of their
> own, adding the rest of the reward and the SHA nonce themselves. That
> way they would set up a competition among full nodes.
>
> This would of course be voluntary but provable, so maybe in a pool's
> interest to do this via naming and shaming.
>
> Tomas
> bitcrust
>
> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
>> I feel like this would be pointless as the vast majority of users
>> would likely download the blockchain from a node that was not
>> enforcing a tip requirement as it would seem like unnecessary cost as
>> in protocols such as BitTorrent there is no such tips in sharing
>> files and the blockchain distribution is in eccense the same thing.
>> However perhaps I am underestimating the generosity of node operators
>> but I feel that adding a cost to the blockchain (assuming that all
>> users add a tip requirement) would lead to centralisation.
>>
>> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
>> > > wrote:
>>
>> IDEA:
>> - Full nodes advertise a bitcoin address.   Users that need to
>> download the block chain from that node can be encouraged to send
>> a tip to the peers that served them (by % served).   Recommended
>> tip of 10mbit should be fine.
>>
>> - A full nodes can *require* a tip to download the blockchain. 
>> If they do, users that don't specify a tip cannot use them.
>>
>> CONS:
>>
>> For some people, this may represent a barrier to hosting their
>> own full node.   After all, if you have to pay $15 just to get a
>> copy of the blockchain, that just adds to the already expensive
>> prospect of hosting a full node.  
>> PROS:
>>
>> As long as you manage to stay online, you should get your money
>> back and more.   This is the an incentive for quality, long term
>> hosting.
>> In the long term, this should cause stable nodes to stick around
>> longer.   It also discourages "installation spam" attacks on the
>> network.
>> Fees for other node operations can be considered if this is
>> successful.
>>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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

Re: [bitcoin-dev] Full node "tip" function

[Erik Aronesty via bitcoin-dev]

> Greg
> The primary result would be paying people to sybil attack the network.

I cannot imagine the benefit to replicating an ip address in this case,
except maybe you think that you would be more likely to be selected as a
peer?   But there would be no actual advantage since download peers are
selected based on throughput and actual blocks served.

Also, since this makes the network far more resistant to DDOS attacks, it
has added benefits.

> Luke:
> paying for services is in general a great idea, but one that Bitcoin
> can much better serve once Lightning is in production.

I agree, if lightning networks were baked in, then the tips could be as
granular as "per block downloaded", or even (outlandish seeming now, but
maybe not in a future where there is a "public rpc api") "per rpc call".
Miners and business users would certainly pay for high quality services.
Spinning up new nodes without a tip and relying on the "free network" would
probably take more time, for example.

I suspect that if income were even a small possibility the number of full
nodes would vastly increase.

Sybil attacks seem irrelevant as long as reasonable QOS metrics are stored
per peer.


On Wed, May 3, 2017 at 5:53 PM, Gregory Maxwell  wrote:

> On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
>  wrote:
> > CONS:
>
> The primary result would be paying people to sybil attack the network.
> It's far cheaper to run one node behind thousands of IPs than it is to
> run many nodes.
>
> Suggestions like this have come up many times before.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Combining SPV and Stealth addresses

[Henning Kopp via bitcoin-dev]

Hi all,

Recently I think a lot about combining Stealth addresses with SPV but
I did not come to a satisfying conclusion, so I post this as a
challenge to the wider community. Maybe you have an idea.

## Explanation of SPV
In SPV a thin client puts his public keys in a bloom filter
and asks a full node to give him Merkle proofs of all transactions
whose pubkey are in the bloom filter. Since a bloom filter has a lot
of false positives depending on the parameters, this gives privacy to
the thin client, since the full node cannot detect if a specific
transaction belongs to the thin client. This is cool if you want to
use Bitcoin on your smartphone.

## Explanation of Stealth Addresses
Stealth addresses on the other hand enable receiver privacy. The
sender of a transaction derives a one-time pubkey to which he sends the
money. The receiver can check if the money was sent to him and recover
the one-time private key. This is cool, since an observer cannot
decide if two payments belong to the same recipient. Further the
recipient needs only to have one pubkey.
For a more formal explanation see 
https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
I will use their notation in the following.

## The Problem
My line of thought was to combine stealth addresses with spv, so that
I can use stealth addresses on my smart phone without losing privacy.

Basically to check if a payment belongs to a pubkey (Q,R), the full
node needs to check if R' = R + H(dP)*G for each transaction. For this
it needs the private scanning key d.
This sucks, since when I give my d to a full node, he can link all my
transactions. For an online-wallet this may be okay, but not for thin
client synchronisation.

## Ideas
In the following I detail some ideas of me which did not work.

It does not suffice to have a Bloom filter and check if d is
contained since there is no way to recompute d from the equation. If
there were a way to recompute d, the scheme would offer no privacy,
since anyone could compute the private scanning key d and scan for
payments.
So, if we modify the scheme we need to be sure that d is kept private.

Multiparty computation may be possible in theory. The full node and
the thin client could collaboratively check R' = R + H(dP)*G, where d
is the private input of the thin client and R, R',P is provided by the
full node. But this is costly and they need to do it for each
transaction. It may be more costly than simply setting up a full node.

I do not think that some kind of search functionality without leaking
the search pattern (PIR?) would work, since the full node needs to compute on 
the
data it has found. And further it needs to retrieve the whole Merkle
proofs.

Any better ideas?

Best,
Henning

-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Full node "tip" function

[Tomas via bitcoin-dev]

The ones that *could* pay non-mining full nodes are miners/pools, by
outsourcing transaction selection using a different PoW.  By doing so
they could buy proof-of-uncensored-selection and proof-of-goodwill for a
small fee.
We would allow full nodes to generate and broadcast a template
block which:
* Does not contain a valid header yet
* Contains the transaction selection
* Contains a  coinbase output with a predetermined part of the block
  reward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined 
currently ASIC resistant
  hash function behind a OP_RETURN.
The template with the highest PoW since the last block would be leading.
A miner/pool can then choose to use this instead of their own, adding
the rest of the reward and the SHA nonce themselves. That way they would
set up a competition among full nodes.
This would of course be voluntary but provable, so maybe in a pool's
interest to do this via naming and shaming.
Tomas
bitcrust

On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote:
> I feel like this would be pointless as the vast majority of users
> would likely download the blockchain from a node that was not
> enforcing a tip requirement as it would seem like unnecessary cost as
> in protocols such as BitTorrent there is no such tips in sharing files
> and the blockchain distribution is in eccense the same thing. However
> perhaps I am underestimating the generosity of node operators but I
> feel that adding a cost to the blockchain (assuming that all users add
> a tip requirement) would lead to centralisation.> 
> On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,  d...@lists.linuxfoundation.org> wrote:>> IDEA:
>> - Full nodes advertise a bitcoin address.   Users that need to
>>   download the block chain from that node can be encouraged to send a
>>   tip to the peers that served them (by % served).   Recommended tip
>>   of 10mbit should be fine.>> 
>> - A full nodes can *require* a tip to download the blockchain.  If
>>   they do, users that don't specify a tip cannot use them.>> 
>> CONS:
>> 
>> For some people, this may represent a barrier to hosting their own
>> full node.   After all, if you have to pay $15 just to get a copy of
>> the blockchain, that just adds to the already expensive prospect of
>> hosting a full node.>> PROS: 
>> 
>> As long as you manage to stay online, you should get your money back
>> and more.   This is the an incentive for quality, long term hosting.>> In 
>> the long term, this should cause stable nodes to stick around
>> longer.   It also discourages "installation spam" attacks on the
>> network.>> Fees for other node operations can be considered if this is
>> successful.>> 

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