Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[Jeremy Rubin via bitcoin-dev]

A standard transaction is 225 bytes, leading to a savings of 8.6%.

However, that is essentially the minimum saving. For other sizes (eg, 10
outputs) which seem to be pretty frequent savings can be greater.

Furthermore, it is important to note that this is a memory saving for the
UTXO pool so the reduction there is more (not super familiar with how the
UTXO pool is stored, but it should be a better savings than 8.6%).


Does anyone have the tools currently to be able to easily run through the
chain and analyze the impact of this change on historical data more
directly?

On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Quoting Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>  On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>  It also requires most clients to be updated to support the new address
>>> system.
>>>
>>
>>
>> That's the killer: introducing Yet Another Type of Bitcoin Address takes a
>> very long time and requires a lot of people to change their code. At
>> least,
>> that was the lesson learned when we introduced P2SH addresses.
>>
>> I think it's just not worth it for a very modest space savings (10 bytes,
>> when scriptSig+scriptPubKey is about 120 bytes), especially with the
>> extreme decrease in security (going from 2^160 to 2^80 to brute-force).
>>
>> --
>> --
>> Gavin Andresen
>>
>
> I think it would only save ~5% with all overhead (value, sequence,
> locktime, version, etc.) counted
>
> A better way is to introduce shorter ECDSA keys, which will save a lot of
> space for public key and signature. It is safe as long as the output value
> is much lower than the cost of attack.
>
> If this happens, I think it will be part of the OP_MAST which will require
> a new address type anyway.
>
>
> ___
> 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 102 - kick the can down the road to 2MB

[jl2012 via bitcoin-dev]

Quoting Peter Todd via bitcoin-dev :


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry, but I think you need to re-read my first message. What you've  
written below has nothing to do with what I actually said re: how  
you're BIP102 and associated pull-req doesn't measure miner consensus.





I think I have already answered this with my previous mail. If there  
is consensus among major exchanges and merchants, the preference of  
miners are not particularly relevant. A checkpoint could be  
implemented in a decentralized way to make sure miners of the original  
chain won't be able to overtake the new chain.


Bitcoin has no intrinsic value. Bitcoin has value because people are  
willing to exchange it with something really valuable (e.g. a pizza;  
or USD which could buy a pizza). If most bitcoin-accepting business  
agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin,  
and the original chain is just a dSHA256 alt-coin which one can't even  
merge mine with BIP102. Switching to BIP102 is the only economically  
viable choice for miners.


Having said that, a miner voting may still be useful. It is just to  
make sure enough miners are ready for the change, instead of measuring  
their consensus. For example, the new rule will be implemented 1) 1  
week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever  
happens first.


For SPV wallets, they have to strengthen their security model after  
the BIP66 fork, anyway. They should be able to identify potential  
consensus fork in the network and stop accepting incoming txs when it  
is in doubt. My "version 0 flag block" proposal could be a good  
generic way to indicate a hardfork to SPV wallets. (see my previous  
email on this topic)


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

Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[jl2012 via bitcoin-dev]

Quoting Gavin Andresen via bitcoin-dev  
:



On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:


It also requires most clients to be updated to support the new address
system.



That's the killer: introducing Yet Another Type of Bitcoin Address takes a
very long time and requires a lot of people to change their code. At least,
that was the lesson learned when we introduced P2SH addresses.

I think it's just not worth it for a very modest space savings (10 bytes,
when scriptSig+scriptPubKey is about 120 bytes), especially with the
extreme decrease in security (going from 2^160 to 2^80 to brute-force).

--
--
Gavin Andresen


I think it would only save ~5% with all overhead (value, sequence,  
locktime, version, etc.) counted


A better way is to introduce shorter ECDSA keys, which will save a lot  
of space for public key and signature. It is safe as long as the  
output value is much lower than the cost of attack.


If this happens, I think it will be part of the OP_MAST which will  
require a new address type anyway.


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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Edmund Edgar via bitcoin-dev]

> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.

This is a really interesting thread. Since we're no longer talking
about a consensus of the core committers, which would be central
control, but instead something broader, could you say a bit more about
what this consensus might look like, and how we'll know if we've got
one?

In plain language "no controversy" sounds like very high bar for a
diverse community like this; Even bringing in P2SH kicked up a fair
bit of fur and feathers. Do you have a definition in mind where it
isn't an _impossibly_ high one?

-- 
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
supp...@realitykeys.com
https://www.realitykeys.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[Jeremy Rubin via bitcoin-dev]

I think the catch here is that under STUA (short term use address) there is
a strict incentive, you can reduce the transaction fee for these txns. This
also fits with the general model that you pay the miners for security. My
belief is that when there is a savings benefit to be had large players will
prefer it at a minimum, and users will desire it.


Your analysis of saving is inaccurate, it comes to be at or greater than 20
bytes because there is typically 2 UTXOs or more. I get that this is still
marginal, but when the margins are tight this is a pretty decent gain.


The security decrease is actually less extreme than it seems. This is for
multiple reasons:
1) you can select LEN_PARAM when you make the tx to be secure at that time
Adding a byte or two gets much more security while still keeping it lean.
2) For a small transaction, the hash power is less rewarding than just
working on the blockchain or doing something else
3) These addresses are only for use for short term, not perm storage. As
such, if you model the threat it isn't great (I'm using this address for
one day, someone grinds it in that time).
4) Because it is a UTXO saving, it reduces memory bloat.t

It would be interesting to get a more exact analysis on the time needed to
run a brute force as it involves computing a valid keypair and hashing for
each attempt.



On Thu, Jul 23, 2015 at 5:06 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> It also requires most clients to be updated to support the new address
>> system.
>
>
> That's the killer: introducing Yet Another Type of Bitcoin Address takes a
> very long time and requires a lot of people to change their code. At least,
> that was the lesson learned when we introduced P2SH addresses.
>
> I think it's just not worth it for a very modest space savings (10 bytes,
> when scriptSig+scriptPubKey is about 120 bytes), especially with the
> extreme decrease in security (going from 2^160 to 2^80 to brute-force).
>
> --
> --
> Gavin Andresen
>
>
> ___
> 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] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 3:01 PM, Mike Hearn  wrote:
> 
> Until we’re able to merge blockchain forks like we’re able to merge git repo 
> forks, the safest option is no fork.
> 
> Block chain forks merge in the same way as git forks all the time, that's how 
> the reorg algorithm works. Transactions that didn't make it into the 
> post-reorg chain go back into the mempool and miners attempt to reinclude 
> them: this is the "merge" process. If they now conflict with other 
> transactions they are dropped and this is "resolving merge conflicts".
> 
> However you have to want to merge with the new chain. If your software is 
> programmed not to do that out of some bizarre belief that throttling your own 
> user base is a good idea, then of course, no merge happens. Once you stop 
> telling your computer to do that, you can then merge (reorg) back onto the 
> main chain again.
> 

Mike, you might be surprized to learn that there are other hard fork proposals 
out there besides increasing block size.




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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Voskuil via bitcoin-dev]

On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote:
> Only being partly serious - I strongly am in favor of a sufficiently
modularized codebase that swapping out consensus rules is fairly
straightforward and easy to test...

We (libbitcoin) have taken the time to publish and maintain bitcoind's
"libbitcoinconsensus" source files as an independent C++ library (with
Java and Python bindings).

https://en.bitcoin.it/wiki/Libbitcoin_Consensus

It can be easily verified against bitcoind sources and in builds of
libbitcoin-blockchain it can be swapped out for libbitcoin's native
consensus checks.

https://en.bitcoin.it/wiki/Libbitcoin_Blockchain#Consensus_Validation

So there is really no reason to consider the original client synonymous
with consensus. I initially argued for this library to be natively
isolated from bitcoind, but that didn't seem to be in the cards so we
did it independently.

In any case I agree with your stated need for this isolation (if not the
means) for the reasons you state. The community needs to move beyond a
largely singular and monolithic codebase that is holding that position
in part due to fear about consensus bug forks.

To make choice regarding consensus an actual choice (and thereby actual
consensus) the modularity you suggest is essential. One must be able to
take new developments without having to take consensus changes. The
option to fork the codebase is not reasonable for most people. At this
point there is no defensible reason for coupling consensus checks with
other features.

e




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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:34 PM, Cory Fields  wrote:
> 
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo  wrote:
>> 
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
>>> 
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
 FWIW, I had worked on something similar a while back:
 https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
 
 I like the idea in principle…but we should require a new genesis block,
 different magic bytes, and a different network port at the very least. :)
 
>>> 
>>> Not sure if serious, so I'll assume you are :)
>> 
>> Only being partly serious - I strongly am in favor of a sufficiently 
>> modularized codebase that swapping out consensus rules is fairly 
>> straightforward and easy to test. I’m not in favor of encouraging forking an 
>> existing blockchain without having mechanisms in place to gracefully merge 
>> back without significant network disruptions. We do not have this yet.
>> 
> 
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.

In general, new consensus rules are not trivial to implement. Block size limits 
are exceptional in being so simple to change in the code. So what you’re 
proposing sounds more like a plugin model supporting dynamic linking than a 
configuration file.

>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork”.
>> 
>> That’s exactly what my coinparams_new branch does. Adding a parameter for 
>> maximum block size would be straightforward.
>> 
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>> 
>> Yes, indeed - this would be a special case.
>> 
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no different
>>> than suggesting that someone fork the codebase and implement their own
>>> changes, it just cuts out most of the work required.
>> 
>> I do not encourage anyone to try to fork an existing blockchain without 
>> first securing overwhelming (near unanimous) consensus…or without having yet 
>> built a mechanism that can merge divergent chains gracefully.
> 
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.

The real problem isn’t so much the difficulty of creating forks of the codebase 
- but the fact that unless a fork has overwhelming support, blockchains cannot 
guarantee irreversibility of transactions…which defeats their entire purpose.


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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev 
>  wrote:
> 
> On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
>> It would be irresponsible and dangerous to the network and thus the users of 
>> the software to risk forks, or to take a leading role in pushing dramatic 
>> changes.
> 
> Count me among those who see allowing bitcoin to become space-constrained, 
> without technical reason, as a dramatic change. Especially when the reasons 
> cited in support are
> 
> - Various species of vaporware
> - Amateurish economic thinking surrounding fees
> - "We don't support it because not everyone supports it because we don't 
> support it because ..." infinite descent
> 

I take it you mean allowing bitcoin to *not* become space-constrained - because 
all real-world computers are space-constrained…


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



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Cory Fields via bitcoin-dev]

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo  wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
>>> FWIW, I had worked on something similar a while back:
>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>
>>> I like the idea in principle…but we should require a new genesis block,
>>> different magic bytes, and a different network port at the very least. :)
>>>
>>
>> Not sure if serious, so I'll assume you are :)
>
> Only being partly serious - I strongly am in favor of a sufficiently 
> modularized codebase that swapping out consensus rules is fairly 
> straightforward and easy to test. I’m not in favor of encouraging forking an 
> existing blockchain without having mechanisms in place to gracefully merge 
> back without significant network disruptions. We do not have this yet.
>

Again, why? If someone wants to create a scamcoin, they can. If
someone wants to burn money on a scamcoin, equally, they can. I'm not
sure how this is any different. If someone manages to garner realistic
support for a hard-fork, I don't see the benefit in forcing them to
use forked software.. that only leaves Core in the middle because it's
forced to choose a side (not choosing is unfortunately a side as
well). It doesn't remove the reality of the split.

>> Why? The idea in this case would be to allow the user to decide
>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>> runtime rather than the likely alternative of "./bitcoind" vs
>> "./bitcoin-fork”.
>
> That’s exactly what my coinparams_new branch does. Adding a parameter for 
> maximum block size would be straightforward.
>
>> Chain params may be identical other than the value of some future
>> event (miner vote for example), in which case the configs would run
>> identically until that point.
>
> Yes, indeed - this would be a special case.
>
>> If your concern is about nodes with different configs communicating
>> with eachother, I'd like to reiterate: the idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>
> I do not encourage anyone to try to fork an existing blockchain without first 
> securing overwhelming (near unanimous) consensus…or without having yet built 
> a mechanism that can merge divergent chains gracefully.

Well of course. It would be a terrible idea. People would try it and
fail, and lose money. But for those crying foul at Core for being the
consensus/policy gatekeeper, it seems to me that user-selectable
params is the only logical solution.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Tom Harding via bitcoin-dev]

On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
It would be irresponsible and dangerous to the network and thus the 
users of the software to risk forks, or to take a leading role in 
pushing dramatic changes.


Count me among those who see allowing bitcoin to become 
space-constrained, without technical reason, as a dramatic change. 
Especially when the reasons cited in support are


 - Various species of vaporware
 - Amateurish economic thinking surrounding fees
 - "We don't support it because not everyone supports it because we 
don't support it because ..." infinite descent



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:05 PM, Cory Fields  wrote:
> 
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
>> FWIW, I had worked on something similar a while back:
>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>> 
>> I like the idea in principle…but we should require a new genesis block,
>> different magic bytes, and a different network port at the very least. :)
>> 
> 
> Not sure if serious, so I'll assume you are :)

Only being partly serious - I strongly am in favor of a sufficiently 
modularized codebase that swapping out consensus rules is fairly 
straightforward and easy to test. I’m not in favor of encouraging forking an 
existing blockchain without having mechanisms in place to gracefully merge back 
without significant network disruptions. We do not have this yet.

> Why? The idea in this case would be to allow the user to decide
> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
> runtime rather than the likely alternative of "./bitcoind" vs
> "./bitcoin-fork”.

That’s exactly what my coinparams_new branch does. Adding a parameter for 
maximum block size would be straightforward.

> Chain params may be identical other than the value of some future
> event (miner vote for example), in which case the configs would run
> identically until that point.

Yes, indeed - this would be a special case.

> If your concern is about nodes with different configs communicating
> with eachother, I'd like to reiterate: the idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.

I do not encourage anyone to try to fork an existing blockchain without first 
securing overwhelming (near unanimous) consensus…or without having yet built a 
mechanism that can merge divergent chains gracefully.

> Cory
> 
>> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>>  wrote:
>> 
>> I'm not sure why Bitcoin Core and the rules and policies that it
>> enforces are being conflated in this thread. There's nothing stopping
>> us from adding the ability for the user to decide what their consensus
>> parameters should be at runtime. In fact, that's already in use:
>> ./bitcoind -testnet. As mentioned in another thread, the chain params
>> could even come from a config file that the user could edit without
>> touching the code.
>> 
>> I realize that it'd be opening Pandora's Box, and likely met with very
>> loud and reasonable arguments about the obvious terrible implications,
>> but it's at least an alternative to the current status quo of Core's
>> conflation with the consensus rules. The idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>> 
>> With that in place, consensus changes would be more about lobbying and
>> coalitions, and less about pull requests.
>> 
>> Cory
>> 
>> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>>  wrote:
>> 
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>> 
>> 
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>> 
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>>  wrote:
>> 
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>> 
>> Quoting BC,
>> 
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>> 
>> 
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>> 
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>> 
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>>  wrote:
>> 
>> Hi Pieter,
>> 
>> I think a core area of disagreement is this:
>> 
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>> 
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have t

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil via bitcoin-dev]

This is a good point. I didn't delve into the specifics of
implementation due to the larger issues that I raised. Libbitcoin Server
uses CurveZMQ, an implementation of CurveCP.

http://curvecp.org
http://curvezmq.org
https://en.bitcoin.it/wiki/Libbitcoin_Server

e

On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
> Why RSA?
> 
>>
>> Here is an idea, inspired by TOR, on which I would like to have some
>> feedback: We create an anonymous routing layer between Electrum servers
>> and clients.
>>
>> * Each server S publishes a RSA public key, KS
>> * Each client receives a list of available servers and their pubkeys
>> * For each wallet address, addr_i, a client chooses a server S_i, and a
>> RSA keypair (K_addr_i, k_addr_i)
>> * The client creates a list of encrypted requests. Each request contains
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
>> * The client chooses a main server M, and sends the list of encrypted
>> requests to M
>> * M dispatches the client's requests to the corresponding servers S_i
>> (without the client's IP address.)
>> * Each server decrypts the requests it receives, performs the request,
>> and encrypts the result with K_addr_i
>> * M receives encrypted responses, and forwards them to the client.
>> * The client decrypts the encrypted response with k_addr_i



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Cory Fields via bitcoin-dev]

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo  wrote:
> FWIW, I had worked on something similar a while back:
> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>
> I like the idea in principle…but we should require a new genesis block,
> different magic bytes, and a different network port at the very least. :)
>

Not sure if serious, so I'll assume you are :)

Why? The idea in this case would be to allow the user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork".

Chain params may be identical other than the value of some future
event (miner vote for example), in which case the configs would run
identically until that point.

If your concern is about nodes with different configs communicating
with eachother, I'd like to reiterate: the idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

Cory

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>  wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>  wrote:
>
> If the developers fail to reflect user consensus, the network will let us
> know.
>
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>  wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>
> Upgrading to a version of Bitcoin Core that is incompatible with your
> ideals is in no way a forced choice, as you have stated in your email;
> forks, alternative clients, or staying on an older version are all valid
> choices. If the majority of the network chooses not to endorse a specific
> change, then the majority of the network will continue to operate just fine
> without it, and properly structured consensus rules will pull the minority
> along as well.
>
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>  wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> 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] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

FWIW, I had worked on something similar a while back: 
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf 


I like the idea in principle…but we should require a new genesis block, 
different magic bytes, and a different network port at the very least. :)

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev 
>  wrote:
> 
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
> 
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
> 
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
> 
> Cory
> 
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>  wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>> 
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>> 
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>>  wrote:
>> 
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>> 
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>> 
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>> 
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>> 
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>>  wrote:
>> 
>> Hi Pieter,
>> 
>> I think a core area of disagreement is this:
>> 
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>> 
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>> 
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>> 
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>> 
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>> 
>> ___
>> 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
>> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Cory Fields via bitcoin-dev]

I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what their consensus
parameters should be at runtime. In fact, that's already in use:
./bitcoind -testnet. As mentioned in another thread, the chain params
could even come from a config file that the user could edit without
touching the code.

I realize that it'd be opening Pandora's Box, and likely met with very
loud and reasonable arguments about the obvious terrible implications,
but it's at least an alternative to the current status quo of Core's
conflation with the consensus rules. The idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

With that in place, consensus changes would be more about lobbying and
coalitions, and less about pull requests.

Cory

On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
 wrote:
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>  wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>  wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making Electrum more anonymous

[gb via bitcoin-dev]

Why RSA?

> 
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
> 
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
> 


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

Re: [bitcoin-dev] Making Electrum more anonymous

[Joseph Gleason ⑈ via bitcoin-dev]

I would recommend the following solution as a decent compromise between
complexity and privacy:

1) Encourage electrum server operators to have their servers reachable as
tor hidden services (.onion addresses)
2) Make sure server discovery works well with .onion addresses
3) Make the privacy a user configurable setting:
  - None - Allows any server connection type
  - SSL - Requires SSL at least, no plain text
  - Tor - Requires tor, no direct TCP
  - Multi-Tor - Uses a variety of tor paths to reach a variety of servers
(maybe configurable number of servers)

Default should be 'SSL' probably.








On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I should add that the obvious resolution to this set of problems is to
> use a distinct Tor route for each Bitcoin address, not to reinvent Tor
> and reproduce its community. So ultimately this is easy to implement,
> but the downside is performance.
>
> But it's important to keep in mind that poor-performing perfect privacy
> for address monitoring is trivial to achieve - just sync the full
> blockchain.
>
> Presumably if you don't trust a server to protect your privacy, you also
> don't trust it with your money. So any robust privacy optimization would
> at least be designed to support partial (SPV) chain clients. It would
> also need to support wallet restoration from backup.
>
> The level of privacy will always be a performance trade-off. The ideal
> solution would allow a client to balance privacy against performance.
>
> e
>
> On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> > Hi Thomas,
> >
> > The scheme is essentially onion routing. The set of {M} are entry nodes
> > and the set of {S} are exit nodes. The weaknesses are as you would see
> > in an analogous TOR implementation:
> >
> > (1) The lack of relay nodes {R} make collaboration between any subset of
> > {M} and {S} trivial.
> >
> > (2) OR is a mixnet, so the size of the network matters a lot.
> >
> > (3) The directory is a perpetual weakness.
> >
> > (4) Content is visible to the exit node (or the final service). This
> > means each address must be passed via a distinct route to prevent
> > correlation.
> >
> > e
> >
> > On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
> >> Hello,
> >>
> >> Although Electrum clients connect to several servers in order to fetch
> >> block headers, they typically request address balances and address
> >> histories from a single server. This means that the chosen server knows
> >> that a given set of addresses belong to the same wallet. That is true
> >> even if Electrum is used over TOR.
> >>
> >> There have been various proposals to improve on that, but none of them
> >> really convinced me so far. One recurrent proposal has been to create
> >> subsets of wallet addresses, and to send them to separate servers. In my
> >> opinion, this does not really improve anonymity, because it requires
> >> trusting more servers.
> >>
> >> Here is an idea, inspired by TOR, on which I would like to have some
> >> feedback: We create an anonymous routing layer between Electrum servers
> >> and clients.
> >>
> >> * Each server S publishes a RSA public key, KS
> >> * Each client receives a list of available servers and their pubkeys
> >> * For each wallet address, addr_i, a client chooses a server S_i, and a
> >> RSA keypair (K_addr_i, k_addr_i)
> >> * The client creates a list of encrypted requests. Each request contains
> >> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> >> * The client chooses a main server M, and sends the list of encrypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding servers S_i
> >> (without the client's IP address.)
> >> * Each server decrypts the requests it receives, performs the request,
> >> and encrypts the result with K_addr_i
> >> * M receives encrypted responses, and forwards them to the client.
> >> * The client decrypts the encrypted response with k_addr_i
> >>
> >> What do you think? What are the costs and benefits of such an approach?
> >>
> >> (Note: this will not work if all servers, or a large fraction of them,
> >> are controlled by the same entity that controls M)
> >>
> >>
> >> Thomas
> >> ___
> >
>
> ___
> 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] Bitcoin Core and hard forks

[Raystonn via bitcoin-dev]

> If the developers fail to reflect user consensus, the network will let us know.
This is true with the caveat that there must be more than one option present for the network to show it's preference.  If developers discourage anything that forks from the rules enforced by Bitcoin Core, they harm the network's ability to inform us of a failure to reflect user consensus.
On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev  wrote:I wouldn't go quite that far.  The reality is somewhere in the middle, as Bryan Cheng noted in this thread:Quoting BC,> Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well.The developers propose a new version, by publishing a new release.  The individual network nodes choose to accept or reject that.So I respectfully disagree with "core devs don't control the network" and "core devs control the network" both.There are checks-and-balances that make the system work.  Consensus is most strongly measured by user actions after software release.  If the developers fail to reflect user consensus, the network will let us know.On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev  wrote:Hi Pieter,I think a core area of disagreement is this:Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. In fact Bitcoin Core is running the Bitcoin economy, and its developers do have the authority to set its rules. This is enforced by the reality of ~100% market share and limited github commit access.You may not like this situation, but it is what it is. By refusing to make a release with different rules, people who disagree are faced with only two options:1. Swallow it even if they hate it2. Fork the project and fork the block chain with it (XT)There are no alternatives. People who object to (2) are inherently suggesting (1) is the only acceptable path, which not surprisingly, makes a lot of people very angry.
___
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] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

I wouldn't go quite that far.  The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:

Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.

The developers *propose* a new version, by publishing a new release.  The
individual network nodes choose to accept or reject that.

So I respectfully disagree with "core devs don't control the network" and
"core devs control the network" both.

There are checks-and-balances that make the system work.  Consensus is most
strongly measured by user actions after software release.  If the
developers fail to reflect user consensus, the network will let us know.











On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> ___
> 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 102 - kick the can down the road to 2MB

[Peter Todd via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry, but I think you need to re-read my first message. What you've written 
below has nothing to do with what I actually said re: how you're BIP102 and 
associated pull-req doesn't measure miner consensus.


On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik  wrote:
>On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I don't agree with you at all.
>>
>> This is a case where if Jeff doesn't understand that issue, he's
>> proposing changes that he's not competent enough to understand, and
>it'd
>> save us a lot of review effort if he left that discussion. Equally,
>Jeff
>> is in a position in the dev community where he should be that
>competent;
>> if he actually isn't it does a lot of good for the broader community
>to
>> change that opinion.
>>
>> I personally *don't* think he's doing that, rather I believe he knows
>> full well it's a bad patch and is proposing it because he wants to
>push
>> discussion towards a solution. Often trolling the a audience with bad
>> patches is an effective way to motivate people to respond by writing
>> better ones; Jeff has told me he often does exactly that.
>>
>>
> kay.  Let's try to keep it technical, please.
>
>2MB is a limit that has been discussed as a viable next-step, meeting
>with
>the most consensus.
>
>2MB gets beyond the 1MB hard fork issue, while still remaining within a
>safety cap that should ensure the system does not go "off the rails" as
>some has predicted.
>
>Security, privacy and centralization are not going to disappear at 2MB.
>
>Further, a limited step gains valuable field data for judging whether
>further steps are warranted - thus informing the "better block size
>solution" development process.
>
>Finally, as stated in the initial PR, it is intended as a viable
>fallback
>should we reach a point of criticality where the user community feels a
>block size increase is warranted, yet cannot reach consensus on a
>fancy,
>all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.
>
>I am open to suggestions for improving BIP 102.  The goal is a minimum
>complexity fallback that others have previously agreed was a useful
>kick-the-can compromise - a static 2MB cap.
-BEGIN PGP SIGNATURE-

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2
AAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM
zCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL
Ecfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG
ccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk
g2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl
2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA=
=+jTv
-END PGP SIGNATURE-

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

Re: [bitcoin-dev] Making Electrum more anonymous

[Eric Voskuil via bitcoin-dev]

I should add that the obvious resolution to this set of problems is to
use a distinct Tor route for each Bitcoin address, not to reinvent Tor
and reproduce its community. So ultimately this is easy to implement,
but the downside is performance.

But it's important to keep in mind that poor-performing perfect privacy
for address monitoring is trivial to achieve - just sync the full
blockchain.

Presumably if you don't trust a server to protect your privacy, you also
don't trust it with your money. So any robust privacy optimization would
at least be designed to support partial (SPV) chain clients. It would
also need to support wallet restoration from backup.

The level of privacy will always be a performance trade-off. The ideal
solution would allow a client to balance privacy against performance.

e

On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> Hi Thomas,
> 
> The scheme is essentially onion routing. The set of {M} are entry nodes
> and the set of {S} are exit nodes. The weaknesses are as you would see
> in an analogous TOR implementation:
> 
> (1) The lack of relay nodes {R} make collaboration between any subset of
> {M} and {S} trivial.
> 
> (2) OR is a mixnet, so the size of the network matters a lot.
> 
> (3) The directory is a perpetual weakness.
> 
> (4) Content is visible to the exit node (or the final service). This
> means each address must be passed via a distinct route to prevent
> correlation.
> 
> e
> 
> On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
>> Hello,
>>
>> Although Electrum clients connect to several servers in order to fetch
>> block headers, they typically request address balances and address
>> histories from a single server. This means that the chosen server knows
>> that a given set of addresses belong to the same wallet. That is true
>> even if Electrum is used over TOR.
>>
>> There have been various proposals to improve on that, but none of them
>> really convinced me so far. One recurrent proposal has been to create
>> subsets of wallet addresses, and to send them to separate servers. In my
>> opinion, this does not really improve anonymity, because it requires
>> trusting more servers.
>>
>> Here is an idea, inspired by TOR, on which I would like to have some
>> feedback: We create an anonymous routing layer between Electrum servers
>> and clients.
>>
>> * Each server S publishes a RSA public key, KS
>> * Each client receives a list of available servers and their pubkeys
>> * For each wallet address, addr_i, a client chooses a server S_i, and a
>> RSA keypair (K_addr_i, k_addr_i)
>> * The client creates a list of encrypted requests. Each request contains
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
>> * The client chooses a main server M, and sends the list of encrypted
>> requests to M
>> * M dispatches the client's requests to the corresponding servers S_i
>> (without the client's IP address.)
>> * Each server decrypts the requests it receives, performs the request,
>> and encrypts the result with K_addr_i
>> * M receives encrypted responses, and forwards them to the client.
>> * The client decrypts the encrypted response with k_addr_i
>>
>> What do you think? What are the costs and benefits of such an approach?
>>
>> (Note: this will not work if all servers, or a large fraction of them,
>> are controlled by the same entity that controls M)
>>
>>
>> Thomas
>> ___
> 



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 3:01 PM, Mike Hearn  wrote:
> 
> Until we’re able to merge blockchain forks like we’re able to merge git repo 
> forks, the safest option is no fork.
> 
> Block chain forks merge in the same way as git forks all the time, that's how 
> the reorg algorithm works. Transactions that didn't make it into the 
> post-reorg chain go back into the mempool and miners attempt to reinclude 
> them: this is the "merge" process. If they now conflict with other 
> transactions they are dropped and this is "resolving merge conflicts".
> 

Blockchain reorgs are part of the consensus rules. We’re talking not about 
forks caused by network partitions…but forks caused by the use of distinct 
consensus rules.

> However you have to want to merge with the new chain. If your software is 
> programmed not to do that out of some bizarre belief that throttling your own 
> user base is a good idea, then of course, no merge happens. Once you stop 
> telling your computer to do that, you can then merge (reorg) back onto the 
> main chain again.
> 

You cannot merge two chains that have incompatible transactions in them without 
throwing away one of the two conflicting transactions (along with all 
dependencies). In the reorg process, this occurs naturally…and we allow for it 
by using confirmation count as a metric of irreversibility. Until one chain 
wins (by overwhelming consensus) or all chains include a particular transaction 
in question, we cannot treat that transaction as irreversible. Propose a model 
in which we can still reliably measure irreversibility in the presence of 
multiple chains and you might have a point.


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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Mike Hearn via bitcoin-dev]

>
> Until we’re able to merge blockchain forks like we’re able to merge git
> repo forks, the safest option is no fork.
>

Block chain forks merge in the same way as git forks all the time, that's
how the reorg algorithm works. Transactions that didn't make it into the
post-reorg chain go back into the mempool and miners attempt to reinclude
them: this is the "merge" process. If they now conflict with other
transactions they are dropped and this is "resolving merge conflicts".

However you have to want to merge with the new chain. If your software is
programmed not to do that out of some bizarre belief that throttling your
own user base is a good idea, then of course, no merge happens. Once you
stop telling your computer to do that, you can then merge (reorg) back onto
the main chain again.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev 
>  wrote:
> 
> Hi Pieter,
> 
> I think a core area of disagreement is this:
> Bitcoin Core is not running the Bitcoin economy, and its developers have no 
> authority to set its rules.
> 
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do 
> have the authority to set its rules. This is enforced by the reality of ~100% 
> market share and limited github commit access.
> 
> You may not like this situation, but it is what it is. By refusing to make a 
> release with different rules, people who disagree are faced with only two 
> options:
> 
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
> 
> There are no alternatives. People who object to (2) are inherently suggesting 
> (1) is the only acceptable path, which not surprisingly, makes a lot of 
> people very angry.

It would be truly awesome to be able to give people more choice on consensus 
rules. Unfortunately, cryptoledgers do not fork gracefully (yet). Until we’re 
able to merge blockchain forks like we’re able to merge git repo forks, the 
safest option is no fork.

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



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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Mike Hearn via bitcoin-dev]

Hi Pieter,

I think a core area of disagreement is this:

> Bitcoin Core is not running the Bitcoin economy, and its developers have
> no authority to set its rules.
>
In fact Bitcoin Core is running the Bitcoin economy, and its developers do
have the authority to set its rules. This is enforced by the reality of
~100% market share and limited github commit access.

You may not like this situation, but it is what it is. By refusing to make
a release with different rules, people who disagree are faced with only two
options:

1. Swallow it even if they hate it
2. Fork the project and fork the block chain with it (XT)

There are no alternatives. People who object to (2) are inherently
suggesting (1) is the only acceptable path, which not surprisingly, makes a
lot of people very angry.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making Electrum more anonymous

[Mike Hearn via bitcoin-dev]

>
> One solution would be for the client to combine all the addresses they are
> interested in into a single bloom filter and send that to the server.
>



Hey Joseph,

All those ideas are ones we had years ago and they are implemented in the
current Bitcoin protocol.

The trick, as you may know, is this bit:

The client would also need to be fairly clever
>

It turns out making a sufficiently clever client to fool even advanced
observers is a lot of programming work, assuming you wish for the Ultimate
Solution which lets you allocate a desired quantity of bandwidth and then
use it to maximize privacy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[Gavin Andresen via bitcoin-dev]

On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It also requires most clients to be updated to support the new address
> system.


That's the killer: introducing Yet Another Type of Bitcoin Address takes a
very long time and requires a lot of people to change their code. At least,
that was the lesson learned when we introduced P2SH addresses.

I think it's just not worth it for a very modest space savings (10 bytes,
when scriptSig+scriptPubKey is about 120 bytes), especially with the
extreme decrease in security (going from 2^160 to 2^80 to brute-force).

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

Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[Tier Nolan via bitcoin-dev]

Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork.

OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY
OP_DROP OP_CHECKSIG

A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match.
If not, then the script immediately fails.  If either array is less than L
bytes or if there are fewer than 3 values on the stack, then it also fails.

The OP_DROP is needed as the new opcode must count as a NOP for legacy
nodes.

A change like this would only cause a once-off improvement in efficiency,
so it is less likely to be worth the effort.

It also requires most clients to be updated to support the new address
system.

A different BIP could be added for that.

An alternative way to add new opcodes is to use a different script engine
like with P2SH.


On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While we're all debating the block size, please review this proposal to
> modestly increase the number of transactions per block.
>
> https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
>
> Best,
>
> Jeremy
>
>
>
> ___
> 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

[bitcoin-dev] BIP: Short Term Use Addresses for Scalability

[Jeremy Rubin via bitcoin-dev]

While we're all debating the block size, please review this proposal to
modestly increase the number of transactions per block.

https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63

Best,

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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev 
>  wrote:
> 
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev 
>  > wrote:
> Some people have called the prospect of limited block space and the 
> development of a fee market a change in policy compared to the past. I 
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin 
> economy, and its developers have no authority to set its rules. Change in 
> economics is always happening, and should be expected. Worse, intervening in 
> consensus changes would make the ecosystem more dependent on the group taking 
> that decision, not less.
> 
> 
> 
> This completely ignores reality, what users have experienced for the past ~6 
> years.
> 
> "Change in economics is always happening" does not begin to approach the 
> scale of the change.
> 
> For the entirety of bitcoin's history, absent long blocks and traffic bursts, 
> fee pressure has been largely absent.

This is only because of the fact that only a negligible portion of miner income 
comes from fees - the vast majority still continues to be subsidized by block 
rewards. The original design of the protocol was such that this subsidy would 
be decreased over time to let fees become the predominant source of income for 
miners. Until we have fee pressures, there’s no incentive for the industry to 
find solutions to real problems that need solving. I think you underestimate 
the ingenuity of people when pressed for real solutions. The main barrier to 
Bitcoin adoption is NOT this issue…and I believe the priorities are misplaced 
here. We’ve had over six years to start working on solutions but we keep 
“kicking the can down the road” - until when?!?! I believe unless there’s a 
strong need to find a solution no solutions will really be found.

> 
> Moving to a new economic policy where fee pressure is consistently present is 
> radically different from what users, markets, and software have experienced 
> and lived.
> 
> Analysis such as [1][2] and more shows that users will hit a "painful" "wall" 
> and market disruption will occur - eventually settling to a new equilibrium 
> after a period of chaos - when blocks are consistently full.
> 
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin 
> 
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent 
> 
> 
> First, users & market are forced through this period of chaos by "let a fee 
> market develop" as the whole market changes to a radically different economic 
> policy, once the network has never seen before.
> 
> Next, when blocks are consistently full, the past consensus was that block 
> size limit will be increased eventually.  What happens at that point?
> 
> Answer - Users & market are forced through a second period of chaos and 
> disruption as the fee market is rebooted again by changing the block size 
> limit.
> 
> The average user hears a lot of noise on both sides of the block size debate, 
> and really has no idea that the new "let a fee market develop" Bitcoin Core 
> policy is going to raise fees on them.
> 
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon them
> 

The current userbase and market is still tiny - we have to think bigger than 
this. We already go through loads of pain to use the current system…and quite 
frankly, there are a number of other significant issues that I think are far 
bigger obstacles to widespread adoption than “I have to pay a fee”. For 
example, the current cost of verification is too high to continue to ensure the 
security of the network (as the July 4th fork clearly illustrated)…and places 
huge centralization pressures on validation…and simply will not support 
hundreds of millions of users or billions of users. Increasing block size 
actually worsens the scaling properties, it does not improve them. We need 
better scaling solutions - almost certainly this will require avoiding the need 
for global consensus for the vast majority of transactions (nested consensus or 
off-chain direct party-to-party contract negotiation, the lightning network, 
etc. The focus on reducing fee pressure by increasing block size is a 
distraction from far more fundamental issues, IMHO.

> 
> So to point out what I consider obvious: if Bitcoin requires central control 
> over its rules by a group of developers, it is completely uninteresting to 
> me. Consensus changes should be done using consensus, and the default in case 
> of controversy is no change.
> 
> 
> False.
> 
> All that has to do be done to change bitcoin to a new economic policy - not 
> seen in the entire 6 year history of bitcoin - is to

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

Addendum:

Please do not interpret - as many have - my points as advocating against
letting a fee market ever develop(!).

Fees are useful against DoS, increasing cost of attack etc.  Further,
continuing the artificially-low fee policy ad infinitum is unsustainable
and constitutes a moral hazard.

Examine from the user's point of view.  If you want to develop a fee
market, think it through in the context of user expectation/experience -
which translates to how software is written and users behave, the context
of market disruption, and the context of further block size increases.

Transition to a new economic policy should be planned.  It should give
users and markets time to adjust.

It is grossly irresponsible to simply drop users into a new economic policy
with no warning and no preparation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Bryan Cheng via bitcoin-dev]

Pieter, I agree with the overall gist of your statement (that Bitcoin is a
consensus-driven protocol that's incompatible with certain forms of central
governance) but I respectfully disagree with some of the conclusions you're
drawing.

> Consensus changes should be done using consensus, _and the default in
case of controversy is no change_.

(emphasis mine)

I think that there's a disconnect between the idea that Bitcoin Core making
a consensus-driven change in turn means that the network is being forced
down a certain path. This takes away a great deal of the individual agency
that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core
that is incompatible with your ideals is in no way a forced choice, as you
have stated in your email; forks, alternative clients, or staying on an
older version are all valid choices. If the majority of the network chooses
not to endorse a specific change, then the majority of the network will
continue to operate just fine without it, and properly structured consensus
rules will pull the minority along as well. (For example, re: block sizes,
if the majority of hashing power remains on a version or fork that does not
mine >1MB blocks, a chain of <1MB blocks will continue to be the longest,
and up to date clients will still respect that. That is consensus at work,
pure and simple.)

Obviously Core is in a unique position as a reference client and ignoring
that would be irresponsible. If broad consensus among the developers cannot
be reached, then Core should not make a given change. However, freezing
Core's ability to make changes in light of _any_ controversy is allowing a
few voices to dictate direction and is counter to any kind of
consensus-driven decision making.

Placing Core and its developers on some sort of pedestal where we believe
that they dictate policy and therefore shouldn't be allowed to take any
risks will create the very situation that you're advocating against- that a
small group of developers have control over Bitcoin's policies. Instead, we
should strive to treat Core as _just another Bitcoin Client_, we should
educate users to make informed choices about the version of software they
are running and the choices implicit in that, and we should allow consensus
at the protocol level to make the decisions on the overall direction of the
network.

> My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later

I will keep this brief because this is straying off topic of the idea of
this thread- but I don't believe that increasing Bitcoin's capacity as a
network is inherently incompatible with the development of a fee market,
and considering a fee market to be formed of only a single set of variables
(transaction rate versus block size) is not sound economic analysis.

On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> default in case of controversy is no change.
>>
>
> I think the result of this would probably be that no controversial changes
> ever get implemented via this process so others will hard fork the code and
> eventually make this process irrelevant.  Since you need close to 100%
> agreement the irrelevance would have to come as a step function which will
> manifest itself in a rather disruptive manner.
>
> The question is really is this hark-forking disruption worse than coming
> up with some kind of process to handle controversial changes.
>
> Russ
>
>
>
> ___
> 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] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

On Wed, Jul 22, 2015 at 11:03 AM, Alex Morcos  wrote:

> Over the last 6 years there may not have been fee pressure, but certainly
> there was the expectation that it was going to happen.  Look at all the
> work that has been put into fee estimation, why do that work if the
> expectation was there would be no fee pressure?
>

There is a vast difference between what software developers have been
chattering about in the background versus what the users actually
experience in the field.

To the user, talk of a fee market is equivalent to talk about block size -
various opinions are tossed about, but it doesn't really impact them.  Fees
have been low for 6 years.

We see this with the actual data - no fee pressure on average for the
entirety of bitcoin's history.  We see this with the recent stress tests,
which exposed dumb wallet behavior WRT fees.   Users -and software- had the
expectation

Remember, this is not a judgement on whether or not fee market/pressure
should exist.  It is simply a factual observation that users/market have
not experienced this new economic policy.

That opens the question - *why now?*   Why make bitcoin growth more
expensive at this time in its young life?  Many smart people would prefer
that bitcoin continue to grow, rather than making the system more expensive
to use right now.

Choosing "let a fee market develop" -- *today* -- is picking economic
sides, picking winners & losers in the market.

This new policy should be debated and consensus achieved, not simply rolled
out by fiat without user notification.

Otherwise it is engaging in precisely the economic wizardry that this
thread opened with decrying.

Just like block size, there are multiple sides to the fee market debate.
However, Bitcoin Core has (unfortunately) outsized decision making power in
that simply avoiding progress on block size limit will achieve the "let a
fee market develop" economic policy change.  Ironic but true - sitting
around and doing nothing dumps users into a new economic policy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Alex Morcos via bitcoin-dev]

Jeff I respectively disagree with many of your points, but let me just
point out 2.

Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen.  Look at all the
work that has been put into fee estimation, why do that work if the
expectation was there would be no fee pressure?

I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them.  Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter.  We only have the privilege of even having this debate as a result
of his work.



On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Some people have called the prospect of limited block space and the
>> development of a fee market a change in policy compared to the past. I
>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
>> economy, and its developers have no authority to set its rules. Change in
>> economics is always happening, and should be expected. Worse, intervening
>> in consensus changes would make the ecosystem more dependent on the group
>> taking that decision, not less.
>>
>>
> This completely ignores *reality*, what users have experienced for the
> past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the
> scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic
> bursts, fee pressure has been largely absent.
>
> Moving to a new economic policy where fee pressure is consistently present
> is radically different from what users, markets, and software have
> experienced and *lived.*
>
> Analysis such as [1][2] and more shows that users will hit a "painful"
> "wall" and market disruption will occur - eventually settling to a new
> equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> First, users & market are forced through this period of chaos by "let a
> fee market develop" as the whole market changes to a radically different
> economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block
> size limit will be increased eventually.  What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and
> disruption as the fee market is rebooted *again* by changing the block
> size limit.
>
> The average user hears a lot of noise on both sides of the block size
> debate, and really has no idea that the new "let a fee market develop"
> Bitcoin Core policy is going to *raise fees* on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon
> them
>
>
>
>> So to point out what I consider obvious: if Bitcoin requires central
>> control over its rules by a group of developers, it is completely
>> uninteresting to me. Consensus changes should be done using consensus, and
>> the default in case of controversy is no change.
>>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy -
> not seen in the entire 6 year history of bitcoin - is to stonewall work on
> block size.
>
> Closing size increase PRs and failing to participate in planning for a
> block size increase accomplishes your stated goal of changing bitcoin to a
> new economic policy.
>
> "no [code] change"... changes bitcoin to a brand new economic policy,
> picking economic winners & losers.  Some businesses will be priced out of
> bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
> move as increasing the hard limit by hard fork.
>
>
>
>> My personal opinion is that we - as a community - should indeed let a fee
>> market develop, and rather sooner than later, and that "kicking the can
>> down the road" is an incredibly dangerous precedent: if we are willing to
>> go through the risk of a hard fork because of a fear of change of
>> economics, then I believe that community is not ready to deal with change
>> at all. And some change is inevitable, at any block size. Again, this does
>> not mean the block size needs to be fixed forever, but its intent should be
>> growing with the evolution of technology, not a panic reaction because a
>> fear of change.
>>
>> But I am not in any position to force this view. I only hope that people
>> don't think a fea

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jeff Garzik via bitcoin-dev]

On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a lot of review effort if he left that discussion. Equally, Jeff
> is in a position in the dev community where he should be that competent;
> if he actually isn't it does a lot of good for the broader community to
> change that opinion.
>
> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trolling the a audience with bad
> patches is an effective way to motivate people to respond by writing
> better ones; Jeff has told me he often does exactly that.
>
>
 kay.  Let's try to keep it technical, please.

2MB is a limit that has been discussed as a viable next-step, meeting with
the most consensus.

2MB gets beyond the 1MB hard fork issue, while still remaining within a
safety cap that should ensure the system does not go "off the rails" as
some has predicted.

Security, privacy and centralization are not going to disappear at 2MB.

Further, a limited step gains valuable field data for judging whether
further steps are warranted - thus informing the "better block size
solution" development process.

Finally, as stated in the initial PR, it is intended as a viable fallback
should we reach a point of criticality where the user community feels a
block size increase is warranted, yet cannot reach consensus on a fancy,
all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.

I am open to suggestions for improving BIP 102.  The goal is a minimum
complexity fallback that others have previously agreed was a useful
kick-the-can compromise - a static 2MB cap.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Sriram Karra via bitcoin-dev]

On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra  wrote:

>
> On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>> I personally *don't* think he's doing that, rather I believe he knows
>> full well it's a bad patch and is proposing it because he wants to push
>> discussion towards a solution. Often trolling the a audience with bad
>> patches is an effective way to motivate people to respond by writing
>> better ones; Jeff has told me he often does exactly that.
>>
>> I think in this case we shouldn't do anything, so short-circuiting that
>> process by pointing out what he's doing publicly makes sense.
>>
>
> Assuming that's what Jeff is doing, how does preventing better solutions
> from emerging 'make sense'?
>

Peter, sorry,  scratch that.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[jl2012 via bitcoin-dev]

Quoting Peter Todd via bitcoin-dev :



Having said that, in general triggering events without verifying a
supermajority of miner support can be very dangerous. Without miner
support the chain is insecure, and can be attacked. For instance a
blocksize limit increase that a majority of miners choose not to
implement raises huge risks of reorg for any miners who attempt to
create large blocks, and huge risks of payment reversal for any
merchants accepting transactions in such blocks. Note how with BIP102,
extending the original Bitcoin chain is inherently an attack on the
Garzik chain.

For that reason I think BIP102 is extremely poorly designed. I can only
conclude that Jeff Garzik is either deliberately trolling us and/or
manipulating discussion with a badly designed proposal that he doesn't
actually expect to be adopted verbatim, or is incompetent.

--
'peter'[:-1]@petertodd.org
031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1


To avoid any risk of reorg, the hardfork may require that the first  
block with GetMedianTimePast() after a pre-determined time (the "flag  
block") MUST be version 0. The exception is applied ONLY to the flag  
block.


Alternatively, the hardfork may require that the flag block MUST be  
larger than 1MB. Comparing with exploiting the block version, this  
does not require additional exceptions in consensus rules. However,  
miner may need to artificially inflate the size of the flag block and  
that could be trouble in coding. I don't have any preference.


Old nodes will not accept the new chain because it violates BIP66 /  
block size limit. New nodes will not accept the old chain because its  
flag block is not version 0 / not larger than 1MB.


This is actually checkpointing in a decentralized way. In that case,  
we can say goodbye to the old chain forever, as long as all major  
merchants and exchanges agree to upgrade. Miner support is less  
relevant. It is a no-brainer for miners to support the new chain,  
unless they don't want to sell or spend their bitcoin, or just give up  
mining after heavily investing in ASIC.


jl2012

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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
> economy, and its developers have no authority to set its rules. Change in
> economics is always happening, and should be expected. Worse, intervening
> in consensus changes would make the ecosystem more dependent on the group
> taking that decision, not less.
>
>
This completely ignores *reality*, what users have experienced for the past
~6 years.

"Change in economics is always happening" does not begin to approach the
scale of the change.

For the entirety of bitcoin's history, absent long blocks and traffic
bursts, fee pressure has been largely absent.

Moving to a new economic policy where fee pressure is consistently present
is radically different from what users, markets, and software have
experienced and *lived.*

Analysis such as [1][2] and more shows that users will hit a "painful"
"wall" and market disruption will occur - eventually settling to a new
equilibrium after a period of chaos - when blocks are consistently full.

[1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

First, users & market are forced through this period of chaos by "let a fee
market develop" as the whole market changes to a radically different
economic policy, once the network has never seen before.

Next, when blocks are consistently full, the past consensus was that block
size limit will be increased eventually.  What happens at that point?

Answer - Users & market are forced through a second period of chaos and
disruption as the fee market is rebooted *again* by changing the block size
limit.

The average user hears a lot of noise on both sides of the block size
debate, and really has no idea that the new "let a fee market develop"
Bitcoin Core policy is going to *raise fees* on them.

It is clear that
- "let the fee market develop, Right Now" has not been thought through
- Users are not prepared for a brand new economic policy
- Users are unaware that a brand new economic policy will be foisted upon
them



> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.
>

False.

All that has to do be done to change bitcoin to a new economic policy - not
seen in the entire 6 year history of bitcoin - is to stonewall work on
block size.

Closing size increase PRs and failing to participate in planning for a
block size increase accomplishes your stated goal of changing bitcoin to a
new economic policy.

"no [code] change"... changes bitcoin to a brand new economic policy,
picking economic winners & losers.  Some businesses will be priced out of
bitcoin, etc.

Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
move as increasing the hard limit by hard fork.



> My personal opinion is that we - as a community - should indeed let a fee
> market develop, and rather sooner than later, and that "kicking the can
> down the road" is an incredibly dangerous precedent: if we are willing to
> go through the risk of a hard fork because of a fear of change of
> economics, then I believe that community is not ready to deal with change
> at all. And some change is inevitable, at any block size. Again, this does
> not mean the block size needs to be fixed forever, but its intent should be
> growing with the evolution of technology, not a panic reaction because a
> fear of change.
>
> But I am not in any position to force this view. I only hope that people
> don't think a fear of economic change is reason to give up consensus.
>

Actually you are.

When size increase progress gets frozen out of Bitcoin Core, that just
*increases* the chances that progress must be made through a contentious
hard fork.

Further, it increases the market disruption users will experience, as
described above.

Think about the users.  Please.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Milly Bitcoin via bitcoin-dev]

default in case of controversy is no change.


I think the result of this would probably be that no controversial 
changes ever get implemented via this process so others will hard fork 
the code and eventually make this process irrelevant.  Since you need 
close to 100% agreement the irrelevance would have to come as a step 
function which will manifest itself in a rather disruptive manner.


The question is really is this hark-forking disruption worse than coming 
up with some kind of process to handle controversial changes.


Russ


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

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Ross Nicoll via bitcoin-dev]

So, if consensus shouldn't really be between the developers (which is 
fine), should we empower users to control consensus? I've been working 
on a fork framework anyway, which can support reasonably arbitrary 
consensus changes (currently against block height, but moving towards 
block time). Theoretically it could be modified to load consensus 
parameters (which block size would have to be added to) from disk at 
startup, rather than having them hard-coded.


Is that considered desirable? Will raise as a PR if so. If not, where do 
we draw a line between developer and user consensus?


Ross

On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote:


Hello all,

I'd like to talk a bit about my view on the relation between the 
Bitcoin Core project, and the consensus rules of Bitcoin.


I believe it is the responsibility of the maintainers/developers of 
Bitcoin Core to create software which helps guarantee the security and 
operation of the Bitcoin network.


In addition to normal software maintenance, bug fixes and performance 
improvements, this includes DoS protection mechanism deemed necessary 
to keep the network operational. Sometimes, such (per-node 
configurable) policies have had economic impact, for example the dust 
rule.


This also includes participating in discussions about consensus 
changes, but not the responsibility to decide on them - only to 
implement them when agreed upon. It would be irresponsible and 
dangerous to the network and thus the users of the software to risk 
forks, or to take a leading role in pushing dramatic changes. Bitcoin 
Core developers obviously have the ability to make any changes to the 
codebase or its releases, but it is still up to the community to 
choose to run that code.


Some people have called the prospect of limited block space and the 
development of a fee market a change in policy compared to the past. I 
respectfully disagree with that. Bitcoin Core is not running the 
Bitcoin economy, and its developers have no authority to set its 
rules. Change in economics is always happening, and should be 
expected. Worse, intervening in consensus changes would make the 
ecosystem more dependent on the group taking that decision, not less.


So to point out what I consider obvious: if Bitcoin requires central 
control over its rules by a group of developers, it is completely 
uninteresting to me. Consensus changes should be done using consensus, 
and the default in case of controversy is no change.


===

My personal opinion is that we - as a community - should indeed let a 
fee market develop, and rather sooner than later, and that "kicking 
the can down the road" is an incredibly dangerous precedent: if we are 
willing to go through the risk of a hard fork because of a fear of 
change of economics, then I believe that community is not ready to 
deal with change at all. And some change is inevitable, at any block 
size. Again, this does not mean the block size needs to be fixed 
forever, but its intent should be growing with the evolution of 
technology, not a panic reaction because a fear of change.


But I am not in any position to force this view. I only hope that 
people don't think a fear of economic change is reason to give up 
consensus.


--
Pieter



___
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 102 - kick the can down the road to 2MB

[Sriram Karra via bitcoin-dev]

On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:


> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trolling the a audience with bad
> patches is an effective way to motivate people to respond by writing
> better ones; Jeff has told me he often does exactly that.
>
> I think in this case we shouldn't do anything, so short-circuiting that
> process by pointing out what he's doing publicly makes sense.
>

Assuming that's what Jeff is doing, how does preventing better solutions
from emerging 'make sense'?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core and hard forks

[Pieter Wuille via bitcoin-dev]

Hello all,

I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.

I believe it is the responsibility of the maintainers/developers of Bitcoin
Core to create software which helps guarantee the security and operation of
the Bitcoin network.

In addition to normal software maintenance, bug fixes and performance
improvements, this includes DoS protection mechanism deemed necessary to
keep the network operational. Sometimes, such (per-node configurable)
policies have had economic impact, for example the dust rule.

This also includes participating in discussions about consensus changes,
but not the responsibility to decide on them - only to implement them when
agreed upon. It would be irresponsible and dangerous to the network and
thus the users of the software to risk forks, or to take a leading role in
pushing dramatic changes. Bitcoin Core developers obviously have the
ability to make any changes to the codebase or its releases, but it is
still up to the community to choose to run that code.

Some people have called the prospect of limited block space and the
development of a fee market a change in policy compared to the past. I
respectfully disagree with that. Bitcoin Core is not running the Bitcoin
economy, and its developers have no authority to set its rules. Change in
economics is always happening, and should be expected. Worse, intervening
in consensus changes would make the ecosystem more dependent on the group
taking that decision, not less.

So to point out what I consider obvious: if Bitcoin requires central
control over its rules by a group of developers, it is completely
uninteresting to me. Consensus changes should be done using consensus, and
the default in case of controversy is no change.

===

My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later, and that "kicking the can
down the road" is an incredibly dangerous precedent: if we are willing to
go through the risk of a hard fork because of a fear of change of
economics, then I believe that community is not ready to deal with change
at all. And some change is inevitable, at any block size. Again, this does
not mean the block size needs to be fixed forever, but its intent should be
growing with the evolution of technology, not a panic reaction because a
fear of change.

But I am not in any position to force this view. I only hope that people
don't think a fear of economic change is reason to give up consensus.

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

Re: [bitcoin-dev] Making Electrum more anonymous

[Joseph Gleason ⑈ via bitcoin-dev]

I've thought about this as well, (in addition to making a java
implementation of the electrum server).

One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.

It would be pretty expensive for the server to check every address against
the bloom filter, but maybe for recent blocks (client can send how behind
they are) and for new transactions it wouldn't be bad at all.

The client could end up receiving a bunch of transactions they weren't
interested in but it would likely be manageable.

The client would also need to be fairly clever, including a set of static
ruse addresses and dynamic ruse addresses that they include in the filter.
That way a server would have a hard time using the bloom filter as a
fingerprint and figuring out which addresses are the real ones.

An alternative would be the server sending a bloom filter of addresses in
each block and then the client requesting entire blocks.  This would use
more bandwidth, but it seems like it would be pretty simple to implement
and give good anonymity.

Basically the idea is to spend more bandwidth and CPU to keep the server in
the dark on what the client really wants.

On Wed, Jul 22, 2015 at 8:51 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
>
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
>
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
>
> What do you think? What are the costs and benefits of such an approach?
>
> (Note: this will not work if all servers, or a large fraction of them,
> are controlled by the same entity that controls M)
>
>
> Thomas
> ___
> 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] Making Electrum more anonymous

[Eric Voskuil via bitcoin-dev]

Hi Thomas,

The scheme is essentially onion routing. The set of {M} are entry nodes
and the set of {S} are exit nodes. The weaknesses are as you would see
in an analogous TOR implementation:

(1) The lack of relay nodes {R} make collaboration between any subset of
{M} and {S} trivial.

(2) OR is a mixnet, so the size of the network matters a lot.

(3) The directory is a perpetual weakness.

(4) Content is visible to the exit node (or the final service). This
means each address must be passed via a distinct route to prevent
correlation.

e

On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
> Hello,
> 
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
> 
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
> 
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
> 
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
> 
> What do you think? What are the costs and benefits of such an approach?
> 
> (Note: this will not work if all servers, or a large fraction of them,
> are controlled by the same entity that controls M)
> 
> 
> Thomas
> ___



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

Re: [bitcoin-dev] Making Electrum more anonymous

[Natanael via bitcoin-dev]

- Sent from my tablet
Den 22 jul 2015 17:51 skrev "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
>
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.

Why not look at something like Dissent? http://dedis.cs.yale.edu/dissent/

This protocol reduces the impact of Sybil attacks.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tom Harding via bitcoin-dev]

On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote:
Re: BIP #'s, we explicitly have a policy of allocating them for stupid 
ideas, to avoid having to be gatekeepers. Ironically that makes it 
harder to get a BIP # if you know what you're doing, because Gregory 
Maxwell will argue against you in private and delay actually 
allocating one if he knows you should know better. :)


Kalle asked for a BIP# for his PoP standardization proposal one month 
ago.   Should he have known better?


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

[bitcoin-dev] Making Electrum more anonymous

[Thomas Voegtlin via bitcoin-dev]

Hello,

Although Electrum clients connect to several servers in order to fetch
block headers, they typically request address balances and address
histories from a single server. This means that the chosen server knows
that a given set of addresses belong to the same wallet. That is true
even if Electrum is used over TOR.

There have been various proposals to improve on that, but none of them
really convinced me so far. One recurrent proposal has been to create
subsets of wallet addresses, and to send them to separate servers. In my
opinion, this does not really improve anonymity, because it requires
trusting more servers.

Here is an idea, inspired by TOR, on which I would like to have some
feedback: We create an anonymous routing layer between Electrum servers
and clients.

* Each server S publishes a RSA public key, KS
* Each client receives a list of available servers and their pubkeys
* For each wallet address, addr_i, a client chooses a server S_i, and a
RSA keypair (K_addr_i, k_addr_i)
* The client creates a list of encrypted requests. Each request contains
addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
* The client chooses a main server M, and sends the list of encrypted
requests to M
* M dispatches the client's requests to the corresponding servers S_i
(without the client's IP address.)
* Each server decrypts the requests it receives, performs the request,
and encrypts the result with K_addr_i
* M receives encrypted responses, and forwards them to the client.
* The client decrypts the encrypted response with k_addr_i

What do you think? What are the costs and benefits of such an approach?

(Note: this will not work if all servers, or a large fraction of them,
are controlled by the same entity that controls M)


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