Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Btc Drak via bitcoin-dev]

On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedups
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for further
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this plan
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, and
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
Thank you for saying this. I also think the plan is solid and delivers
multiple benefits without being contentious. The number of wins are so
numerous, it's frankly a no-brainer.

I guess the next step for segwit is a BIP and deployment on a testnet?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] A new payment address format for segregated witness or not?

[jl2012 via bitcoin-dev]

On the -dev IRC I asked the same question and people seem don't like it. 
I would like to further elaborate this topic and would like to consult 
merchants, exchanges, wallet devs, and users for their preference


Background:

People will be able to use segregated witness in 2 forms. They either 
put the witness program directly as the scriptPubKey, or hide the 
witness program in a P2SH address. They are referred as "native SW" and 
"SW in P2SH" respectively


Examples could be found in the draft BIP: 
https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki


As a tx malleability fix, native SW and SW in P2SH are equally good.

The SW in P2SH is better in terms of:
1. It allows payment from any Bitcoin reference client since version 
0.6.0.
2. Slightly better privacy by obscuration since people won't know 
whether it is a traditional P2SH or a SW tx before it is spent. I don't 
consider this is important since the type of tx will be revealed 
eventually, and is irrelevant when native SW is more popular


The SW in P2SH is worse in terms of:
1. It requires an additional push in scriptSig, which is not prunable in 
transmission, and is counted as part of the core block size

2. It requires an additional HASH160 operation than native SW
3. It provides 160bit security, while native SW provides 256bit
4. Since it is less efficient, the tx fee is likely to be higher than 
native SW (but still lower than non-SW tx)

---

The question: should we have a new payment address format for native SW?

The native SW address in my mind is basically same as existing P2PKH and 
P2SH addresses:


BASE58(address_version|witness_program|checksum) , where checksum is the 
first 4 bytes of dSHA256(address_version|witness_program)


Why not a better checksum algorithm? Reusing the existing algorithm make 
the implementation much easier and safe.


Pros for native SW address:
1. Many people and services are still using BASE58 address
2. Promote the use of native SW which allows lower fee, instead of the 
less efficient SW in P2SH

3. Not all wallets and services support payment protocol (BIP70)
4. Easy for wallets to implement
5. Even if a wallet wants to only implement SW in P2SH, they need a new 
wallet format anyway. So there is not much exta cost to introduce a new 
address format.
6. Since SW is very flexible, this is very likely to be the last address 
format to define.


Cons for native SW address:
1. Addresses are bad and should not be used anymore (some arguments 
could be found in BIP13)

2. Payment protocol is better
3. With SW in P2SH, it is not necessary to have a new address format
4. Depends on the length of the witness program, the address length 
could be a double of the existing address
5. Old wallets won't be able to pay to a new address (but no money could 
be lost this way)


--

So I'd like to suggest 2 proposals:

Proposal 1:

To define a native SW address format, while people can still use payment 
protocol or SW in P2SH if the want


Proposal 2:

No new address format is defined. If people want to pay as lowest fee as 
possible, they must use payment protocol. Otherwise, they may use SW in 
P2SH


Since this topic is more relevant to user experience, in addition to 
core devs, I would also like to consult merchants, exchanges, wallet 
devs, and users for their preferences.

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

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia 
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 2) This reverses the useful minimization attribute of HD wallets -
> >"just
> >backup the seed"
> >
> >It would be nice if the bip37 filter matching algorithm was extended to
> >serve up the proof.
> >
> >And if server-based wallets did the same it would preserve the "just
> >backup
> >the seed" functionality.
>
> Exactly! The information will be out there - "just backup the seed"
> requires someone to have the exact same data needed to generate the
> TXO-unspent proof that my proposal requires to spend an old txout.
>
> tl;dr: jgarzik is incorrect; theres no difference at all from the status
> quo.
>

The data stored in the legacy case makes it possible to sign and send a
transaction without any connection to a network.  The data stored in the
upgraded case, absent grandfathering, requires significant network sync at
a minimum.

The user experience and security parameters are different.

Thus, issue/recommendation #1.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Remember this is proposed as an alternative to hardforks, which is also a
> "nuclear option".  Hardforks carry significant risks such as permanently
> splitting Bitcoin into two chains if global consensus is never reached.  A
> (generalized) softfork avoids this problem.


Current hard fork implementations include / will include miner lock-in,
just like any soft fork.  They will not activate if global consensus is not
reached.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[joe2015--- via bitcoin-dev]

On 2015-12-21 11:39, Jeff Garzik wrote:

On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev
 wrote:



Current hard fork implementations include / will include miner
lock-in, just like any soft fork.  They will not activate if global
consensus is not reached.


That's not true at all. They activate with a miner majority (e.g. 75%, 
95%, etc.), not global consensus.  Here global really means global, i.e. 
miner, economic, all clients, etc.  In the case of a hardfork there is 
nothing stopping the miner minority from continuing the old chain.  With 
a softfork the miner minority is forced to upgrade otherwise their 
blocks will be eventually orphaned.


My proposal achieves a hardfork-like blocksize limit increase but, like 
a softfork, also forces the miner minority to upgrade.


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

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Douglas Roark via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015/12/20 20:50, Mark Friedenbach via bitcoin-dev wrote:
> I am fully in support of the plan laid out in "Capacity increases 
> for the bitcoin system".
> 
> This plan provides real benefit to the ecosystem in solving a 
> number of longstanding problems in bitcoin. It improves the 
> scalability of bitcoin considerably.
> 
> Furthermore it is time that we stop bikeshedding, start 
> implementing, and move forward, lest we lose more developers to
> the toxic atmosphere this hard-fork debacle has created.

Another +1 here. While I'd still like to see some sort of short-term
bump happen this year - good points have been raised about SegWit
uptake by wallet devs, for one thing - I really do think this is one
of the last pieces of the puzzle that'll make Bitcoin reasonably
stable and robust. If people have legitimate concerns, that's great,
and they should be addressed. I just worry that more navel-gazing and
bikeshedding will play into the hands of those with less than noble
intentions. That and, due to the somewhat complicated nature of
SegWit, it may take time to get skeptical miners and wallet devs on-boar
d.

While we're talking about capacity increases, I'd like to reiterate
that I do think there should be some sort of short-term bump (Jeff's
BIP 102 or his "BIP 202" variant, Dr. Back's 2/4/8 proposal ("BIP
248"), etc.), hopefully chosen by this summer so that everybody can
start to prepare. I believe the KISS theory will work best. I talked
to a couple of miners at Scaling Bitcoin. It was obvious they
generally prefer simple solutions. (For that matter, if I put my
miner's cap on, I prefer simple solutions too!) The research presented
at Scaling Bitcoin regarding block size formulas was quite interesting
and worthy of discussion. The research was also, IMO, nowhere near
ready for consensus. Work and discussions on that front should
certainly continue and push for a more permanent (final?) block size
solution. I just think that, barring some extraordinary solution that
hasn't been widely discussed yet, a permanent solution isn't feasible
right now. A temporary bump isn't ideal. It's just the only thing I've
seen that strikes me as having any real shot at consensus.

- -- 
- ---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joro...@vt.edu
PGP key ID: 26623924
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWd44sAAoJEEOBHRomYjkklUkP/AqnD4+oiNNNYRGDY3m0bQSG
noUoRmWG/h86AW+2LuNYtn72UVefWJscUcmXWeOOem1KX49KdtCRWz3UZcrmfPUF
h/ilOpYpjCN69nFBhpJPp+0Jqr/PjQpoZkUQ2G1BznGIcIo3jwh7H7dQeI6PMtLB
qTbfdYEqPawb2kIhrCKVVQqsf7dLjg0Hlzvnq+xqyggZ1+k89kXSMEHJaybras7q
DFj1lOhzktzAtxquzAMcctkZM3JvFMnKUwOP6zC+ke9YlmvU0Yhu74F+30/EClLc
XGL5GMvUtvJcC0VRxDlh4pIW3m+eWjLWxvPQGe58eLE2u2Ja2MNjcuVtJdRgouLI
VSPBrUKoGOGfNfsqJH9U9jsvRuQMvT6JFS3jjxiapgi+ip1O7+Pkbq6tO55Mz7Gd
WMG71HdrLzZtjOzRmOFL5q3CkTpZp75tsXOYxn7jVcJlYJUh/jrnVMvSbPAT/VAY
yJIPtWRj+jtMKAR9m4Lx+9N4F56OC3g0M749v31luoYZkKMl7ohgkONgpKhrDRBU
uVmWH0pUIvaScsJxrUtgZdqn2AUqRowq6nM0YNDKo4go5/LyAkYYi1mICb0O0JJG
mt+3fabix6biBPHZDAvKxKX5CAPDapno2adTBx7vY36evGdhI9sWA1jw91He8Zmw
8hwnRV7R8bPdkoIfnc8e
=jJzD
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Tom Harding via bitcoin-dev]

On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote:
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
>
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for
> those wallets generated in 2009, buried in a landfill and then dug out
> 10 years ago
>
> 2) This reverses the useful minimization attribute of HD wallets -
> "just backup the seed"

Also, a change (#6550) has been merged to bitcoin core that removes
merkle branches from the wallet, and if pruning gets turned on (possible
in 0.12 with #6057), it would become quite a bit more difficult to spend
older coins under a change like this.

As a solution I would favor not removing wallet merkle branches.

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

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[joe2015--- via bitcoin-dev]

On 2015-12-21 02:17, Bryan Bishop wrote:

On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev
 wrote:


An Arbitrary Block-size Increase Via a Generalized Softfork


This seems conceptually similar to "extension blocks":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html
[1]
https://bitcointalk.org/index.php?topic=283746.0 [2]
http://gnusha.org/bitcoin-wizards/2015-12-20.log [3]

"Extended blocks" are also mentioned over here too:
https://bitcointalk.org/index.php?topic=1296628.msg13307275#msg13307275
[4]


The main difference is that my proposal does not introduce different 
"tiers" of blocks, and does not require uses to move coins to manually 
move coins between these tiers.


Instead, my proposal uses a single flat block format that is essentially 
the same as the current block format; only bigger.


The main point is that such a change does not require a hardfork with 
global consensus, as is commonly assumed, but rather can be deployed 
like a softfork using the method described in my original post.


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

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Mark Friedenbach via bitcoin-dev]

I am fully in support of the plan laid out in "Capacity increases for the
bitcoin system".

This plan provides real benefit to the ecosystem in solving a number of
longstanding problems in bitcoin. It improves the scalability of bitcoin
considerably.

Furthermore it is time that we stop bikeshedding, start implementing, and
move forward, lest we lose more developers to the toxic atmosphere this
hard-fork debacle has created.

On Mon, Dec 21, 2015 at 12:33 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedups
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for further
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this plan
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, and
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
> --
> 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] We need to fix the block withholding attack

[Emin Gün Sirer via bitcoin-dev]

There's quite a bit of confusion in this thread.

Peter is referring to block withholding attacks. Ittay Eyal (as sole
author -- I was not involved in this paper [1]) was the first
to analyze these attacks and to discover a fascinating, paradoxical
result. An attacker pool (A) can take a certain portion of its hashpower,
use it to mine on behalf of victim pool (B), furnish partial proofs of work
to B, but discard any full blocks it discovers. If A picks the amount of
attacking hashpower judiciously, it can make more money using this
attack, than it would if it were to use 100% of its hashpower for its own
mining. This last sentence should sound non-sensical to most of you,
at least, it did to me. Ittay did the math, and his paper can tell you
exactly how much of your hashpower you need to peel off and use
to attack another open pool, and you will come out ahead.

Chris Priest is confusing these attacks with selfish mining, and further,
his characterization of selfish mining is incorrect. Selfish Mining is
guaranteed to yield profits for any pool over 33% (as a result, Nick
Szabo has dubbed this the "34% attack") and it may pay off even
below that point if the attacker is well-positioned in the network;
or it may not, depending on the makeup of the rest of the pools
as well as the network characteristics (the more centralized
and bigger the other pools are, the less likely it is to pay off). There
was a lot of noise in the community when the SM paper came out,
so there are tons of incorrect response narrative out there. By now,
everyone who seems to be Bitcoin competent sees SM as a
concern, and Ethereum has already adopted our fix. I'd have hoped
that a poster to this list would be better informed than to repeat the
claim that "majority will protect Bitcoin" to refute a paper whose title
is "majority is not enough."

Back to Ittay's paradoxical discovery:

We have seen pool-block withholding attacks before; I believe Eligius
caught one case. I don't believe that any miners will deploy strong KYC
measures, and even if they did, I don't believe that these measures
will be effective, at least, as long as the attacker is somewhat savvy.
The problem with these attacks are that statistics favor the attackers.
Is someone really discarding the blocks they find, or are they just
unlucky? This is really hard to tell for small miners. Even with KYC,
one could break up one's servers, register them under different
people's names, and tunnel them through VPNs.

Keep in mind that when an open pool gets big, like GHash did and
two other pools did before them, the only thing at our disposal used
to be to yell at people about centralization until they left the big
pools and reformed into smaller groups. Not only was such yelling
kind of desperate looking, it wasn't incredibly effective, either.
We had no protocol mechanisms that put pressure on big pools to
stop signing up people. Ittay's discovery changed that: pools that
get to be very big by indiscriminately signing up miners are likely to
be infiltrated and their profitability will drop. And Peter's post is
evidence that this is, indeed, happening as predicted. This is a
good outcome, it puts pressure on the big pools to not grow.

Peter, you allude to a specific suggestion from Luke-Jr. Can you
please describe what it is?

Hope this is useful,
- egs

[1] https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.


Yes, this is almost what -has- to happen in the long term.

Ideally we should start having wallets generate those proofs now, and then
introduce the max-age as a second step as a planned hard fork a couple
years down the line.

However,
1) There is also the open question of "grandfathered" UTXOs - for those
wallets generated in 2009, buried in a landfill and then dug out 10 years
ago

2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Chris Pacia via bitcoin-dev]

On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"

It would be nice if the bip37 filter matching algorithm was extended to
serve up the proof.

And if server-based wallets did the same it would preserve the "just backup
the seed" functionality.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[joe2015--- via bitcoin-dev]

On 2015-12-20 23:50, Tier Nolan via bitcoin-dev wrote:

This is essentially the "nuclear option".


Remember this is proposed as an alternative to hardforks, which is also 
a "nuclear option".  Hardforks carry significant risks such as 
permanently splitting Bitcoin into two chains if global consensus is 
never reached.  A (generalized) softfork avoids this problem.



This could be achieved by adding the hash of an extended block into
the coinbase but not requiring the coinbase to be the only
transaction.


I think this can also be viewed as a generalized softfork if one so 
chooses, e.g.


NewBlock := OldBlock ++ ExtendedBlock
f(NewBlock) = OldBlock

I do not think this is a bad idea but is more complex than my proposal, 
e.g. users having to move coins between different tiers of blocks.  
Under my proposal the Bitcoin works more or less the same except with a 
larger limit.


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

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Bryan Bishop via bitcoin-dev]

On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> An Arbitrary Block-size Increase Via a Generalized Softfork
>

This seems conceptually similar to "extension blocks":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html
https://bitcointalk.org/index.php?topic=283746.0
http://gnusha.org/bitcoin-wizards/2015-12-20.log

"Extended blocks" are also mentioned over here too:
https://bitcointalk.org/index.php?topic=1296628.msg13307275#msg13307275

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Rusty Russell via bitcoin-dev]

Jonathan Toomim via bitcoin-dev 
writes:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
>  wrote:
>
>> 1) The risk of an old full node wallet accepting a transaction that is
>> invalid to the new rules.
>> 
>> The receiver wallet chooses what address/script to accept coins on.
>> They'll upgrade to the new softfork rules before creating an address
>> that depends on the softfork's features.
>> 
>> So, not a problem.
>
>
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
> runs the old rules. Bob creates a p2pkh address for Mallory to
> use. Mallory takes 1 BTC, and creates an invalid SegWit transaction
> that Bob cannot properly validate and that pays into one of Mallory's
> wallets. Mallory then immediately spends the unconfirmed transaction
> into Bob's address. Bob sees what appears to be a valid transaction
> chain which is not actually valid.

Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG" scriptSig.  The SegWit-usable
outputs will (have to) look different, won't they?

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

Re: [bitcoin-dev] On the security of softforks

[jl2012 via bitcoin-dev]

Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:

Jonathan Toomim via bitcoin-dev 
writes:
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev 
 wrote:


1) The risk of an old full node wallet accepting a transaction that 
is

invalid to the new rules.

The receiver wallet chooses what address/script to accept coins on.
They'll upgrade to the new softfork rules before creating an address
that depends on the softfork's features.

So, not a problem.



Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
runs the old rules. Bob creates a p2pkh address for Mallory to
use. Mallory takes 1 BTC, and creates an invalid SegWit transaction
that Bob cannot properly validate and that pays into one of Mallory's
wallets. Mallory then immediately spends the unconfirmed transaction
into Bob's address. Bob sees what appears to be a valid transaction
chain which is not actually valid.


Pretty sure Bob's wallet will be looking for "OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG" scriptSig.  The SegWit-usable
outputs will (have to) look different, won't they?

Cheers,
Rusty.


I think he means Mallory is paying with an invalid Segwit input, not 
output (there is no "invalid output" anyway). However, this is not a 
issue if Bob waits for a few confirmations.

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Tier Nolan via bitcoin-dev]

On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>  An attacker pool (A) can take a certain portion of its hashpower,
> use it to mine on behalf of victim pool (B), furnish partial proofs of work
> to B, but discard any full blocks it discovers.
>

I wonder if part of the problem here is that there is no pool identity
linked to mining pools.

If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.

If the various mining protocols were updated, they could allow checking
that the work has the domain name of the pool included.  Pools would have
to include their domain name in the block header.

A pool which provides this service is publicly saying that they will not
use the block withholding attack.  Any two pools which are doing it cannot
attack each other (since they have different domain names).  This creates
an incentive for pools to start supporting the feature.

Owners of hashing power also have an incentive to operate with pools which
offer this identity.  It means that they can ensure that they get a payout
from any blocks found.

Hosted mining is weaker, but even then, it is possible for mining hosts to
provide proof that they performed mining.  This proof would include the
identity of the mining pool.  Even if the pool was run by the host, it
would still need to have the name embedded.

Mining hosts might be able to figure out which of their customers actually
check the identity info, and then they could redirect the mining power of
those who generally don't check.  If customers randomly ask for all of the
hashing power, right back to when they joined, then this becomes expensive.

Mining power directly owned by the pool is also immune to this effect.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[s7r via bitcoin-dev]

What will be the actual effect over wallets?

Say I have the private key for a dormant UTXO older than the
consensus-critical maximum UTXO age. The UTXO is not part of the cache.
So I setup a full node and import my old private key (wallet.dat). Will
I even see the correct balance (where will it get if from, since it's
dropped from the cache), or it will show me a 0 balance?

If I can see the correct balance, where can I get the proof I need and
what ensures I'll always be able to get that proof?

On 12/20/2015 1:34 PM, Jeff Garzik via bitcoin-dev wrote:
> On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev
>  > wrote:
> 
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.
> 
> 
> Yes, this is almost what -has- to happen in the long term.
> 
> Ideally we should start having wallets generate those proofs now, and
> then introduce the max-age as a second step as a planned hard fork a
> couple years down the line.
> 
> However,
> 1) There is also the open question of "grandfathered" UTXOs - for those
> wallets generated in 2009, buried in a landfill and then dug out 10
> years ago
> 
> 2) This reverses the useful minimization attribute of HD wallets - "just
> backup the seed"
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[joe2015--- via bitcoin-dev]

This is a draft.

--joe

Introduction


It is generally assumed that increasing the blocksize limit requires a
hardfork.  Instead we show that a increasing the limit can be achieved 
using a
"generalized" softfork.  Like standard softforks, generalized softforks 
need a

mere miner majority (>50% hashpower) rather than global consensus.

Standard Softforks
==

After a softfork two potential chains exist:

* The new chain B3,B4,B5,... valid under the new rules and old rules.
* The old chain B3',B4',B5',... valid under the old rules only.

E.g.

  +-- B3 --- B4 --- B5
  |
... -- B1 -- B2 --+
  |
  +-- B3' -- B4' -- B5' -- B6'

Assuming that >50% of the hashpower follow the new rules, the old chain 
is

doomed to be orphaned:

  +-- B3 --- B4 --- B5 --- B6 --- B7 --- B8 --- ...
  |
... -- B1 -- B2 --+
  |
  +-- B3' -- B4' -- B5' -- B6' (orphaned)

Hardforks may result in two chains that can co-exist indefinitely:

  +-- B3 --- B4 --- B5 --- B6 --- B7 --- B8 --- ...
  |
... -- B1 -- B2 --+
  |
  +-- B3' -- B4' -- B5' -- B6' -- B7' -- B8' -- ...

Generalized Softforks
=

A *generalized* softfork introduces a transform function f(B)=B' that 
maps a
block B valid under the new rules to a block B' valid under the old 
rules.


After a generalized softfork three chains may exist:

* The new chain B3,B4,B5,... valid under the new rules only.
* The mapped chain f(B3),f(B4),f(B5),... valid under the old rules.
* The old chain B3',B4',B5',... valid under the old rules only.

E.g.

  +-- B3  B4  B5
  |
... -- B1 -- B2 --+-- f(B3) - f(B4) - f(B5)
  |
  +-- B3' --- B4' --- B5' --- B6'

This is "generalized" softfork since defining f(B)=B (identity function)
reduces to the standard softfork case above.

As with standard softforks, if the majority of the hashpower follow the 
new

rules then the old chain B3',B4',B5',... is doomed to be orphaned:

  +-- B3  B4  B5  B6  B7  ...
  |
... -- B1 -- B2 --+-- f(B3) - f(B4) - f(B5) - f(B6) - f(B7) - ...
  |
  +-- B3' --- B4' --- B5' --- B6' (orphaned)

Example:


Segregated Witness can be thought of as an example of a generalized 
softfork.
Here the new block format consists of the combined old block and witness 
data.
The function f() simply strips the witness data to reveal a valid block 
under

the old rules:

NewBlock := OldBlock ++ Witness
f(NewBlock) = OldBlock

An Arbitrary Block-size Increase Via a Generalized Softfork
===

Segregated Witness only allows for a modest effective blocksize increase
(although there can be other motivations for SW, but that is off-topic).

Instead we engineer a generalized softfork that allows an arbitrarily 
increase
of the blocksize limit.  The proposal consists of two parts: (a) new 
rules for

valid blocks, and (b) a transformation function f().

The new block rules are very similar to the old block rules but with 
some

small changes.  In summary the changes are:

* The MAX_BLOCK_SIZE limit is raised to some new limit
  (e.g. 8Mb, BIP101, 2-4-8, BIP202, etc., or some other limit)
* The MerkleRoot field in the header has been re-interpreted.
* The CoinBaseTx must obey some additional new rules.

As with old blocks, a block under the new rules consists of a block 
header

followed by a vector of transactions [CoinBaseTx, Tx1, .., Txn], i.e.

NewBlock := BlockHeader ++ NumTx ++ CoinBaseTx ++ Tx1 ++ .. ++ Txn

The block header format is the same as under the old rules defined as 
follows:



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Ver  |PrevHash
   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   MerkleRoot  | 
Time  |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Bits  | Nonce |
+-+-+-+-+-+-+-+-+

Under the old rules MerkleRoot is the Merkle root of the hashes of all
transactions included in the block, i.e.

MerkleRoot = merkleRoot([hash(CoinBaseTx), hash(Tx1), .., 
hash(Txn)])


Under the new rules we instead define:

MerkleRoot = merkleRoot([hash(CoinBaseTx)])

That is, under the new rules, MerkleRoot is the Merkle root of a 
singleton

vector containing the CoinBaseTx hash only.

In order to preserve the security properties of Bitcoin we additionally
require that the CoinBaseTx somehow encodes the Merkle root of the 
remaining
transactions [Tx1, 

Re: [bitcoin-dev] We need to fix the block withholding attack

[Tier Nolan via bitcoin-dev]

On Sun, Dec 20, 2015 at 12:42 PM, Natanael  wrote:

> If total difficulty is X and the ratio for full blocks to candidate blocks
> shared with the pool is Y, then the candidate block PoW now has to meet X/Y
> while hashing the candidate block PoW + the pool's commitment hash must
> meet Y, which together makes for X/Y*Y and thus the same total difficulty.


This gives the same total difficulty but miners are throwing away otherwise
valid blocks.

This means that it is technically a soft fork.  All new blocks are valid
according to the old rule.

In practice, it is kind of a hard fork.  If Y is 10, then all upgraded
miners are throwing away 90% of the blocks that are valid under the old
rules.

>From the perspective of non-upgraded clients, the upgraded miners operate
at a 10X disadvantage.

This means that someone with 15% of the network power has a majority of the
effective hashing power, since 15% is greater than 8.5% (85% * 0.1).

The slow roll-out helps mitigate this though.  It gives non-upgraded
clients time to react.  If there is only a 5% difference initially, then
the attacker doesn't get much benefit.

The main differences are that there's a public key identifier the miners
> are told about in advance and expect to see in block templates, and that
> that now the pool has to publish this commitment value together with the
> block that also contains the commitment hash, and that this is verified
> together with the PoW.


I don't think public keys are strictly required.  Registering them with
DNSSEC is way over the top.  They can just publish the key on their website
and then use that for their identity.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] We need to fix the block withholding attack

[Peter Todd via bitcoin-dev]

On Sun, Dec 20, 2015 at 12:12:49AM -0500, Emin Gün Sirer via bitcoin-dev wrote:
> There's quite a bit of confusion in this thread.
> 
> Peter is referring to block withholding attacks. Ittay Eyal (as sole
> author -- I was not involved in this paper [1]) was the first

Ah, thanks for the correction.

> to analyze these attacks and to discover a fascinating, paradoxical
> result. An attacker pool (A) can take a certain portion of its hashpower,
> use it to mine on behalf of victim pool (B), furnish partial proofs of work
> to B, but discard any full blocks it discovers. If A picks the amount of
> attacking hashpower judiciously, it can make more money using this
> attack, than it would if it were to use 100% of its hashpower for its own
> mining. This last sentence should sound non-sensical to most of you,
> at least, it did to me. Ittay did the math, and his paper can tell you
> exactly how much of your hashpower you need to peel off and use
> to attack another open pool, and you will come out ahead.

Now to be clear, I'm not saying any of the above isn't true - it's a
fascinating result. But the hashing/mining ecosystem is significantly
more complex than just pools.

> Back to Ittay's paradoxical discovery:
> 
> We have seen pool-block withholding attacks before; I believe Eligius
> caught one case. I don't believe that any miners will deploy strong KYC
> measures, and even if they did, I don't believe that these measures
> will be effective, at least, as long as the attacker is somewhat savvy.
> The problem with these attacks are that statistics favor the attackers.
> Is someone really discarding the blocks they find, or are they just
> unlucky? This is really hard to tell for small miners. Even with KYC,
> one could break up one's servers, register them under different
> people's names, and tunnel them through VPNs.

There are a number of techniques that can be used to detect block
withholding attacks that you are not aware of. These techniques usually
have the characteristic that if known they can be avoided, so obviously
those who know about them are highly reluctant to reveal what exactly
they are. I personally know about some of them and have been asked to
keep that information secret, which I will.

In the context of KYC, this techniques would likely hold up in court,
which means that if this stuff becomes a more serious problem it's
perfectly viable for large, well-resourced, pools to prevent block
withholding attacks, in part by removing anonymity of hashing power.
This would not be a positive development for the ecosystem.

Secondly, DRM tech can also easily be used to prevent block withholding
attacks by attesting to the honest of the hashing power. This is being
discussed in the industry, and again, this isn't a positive development
for the ecosystem.

> Keep in mind that when an open pool gets big, like GHash did and
> two other pools did before them, the only thing at our disposal used
> to be to yell at people about centralization until they left the big
> pools and reformed into smaller groups. Not only was such yelling
> kind of desperate looking, it wasn't incredibly effective, either.
> We had no protocol mechanisms that put pressure on big pools to
> stop signing up people. Ittay's discovery changed that: pools that
> get to be very big by indiscriminately signing up miners are likely to
> be infiltrated and their profitability will drop. And Peter's post is
> evidence that this is, indeed, happening as predicted. This is a
> good outcome, it puts pressure on the big pools to not grow.

GHash.io was not a pure pool - they owned and operated a significant
amount of physical hashing power, and it's not at all clear that their %
of the network actually went down following that 51% debacle.

Currently a significant % of the hashing power - possibly a majority -
is in the form of large hashing installations whose owners individually,
and definitely in trusting groups, have enough hashing power to solo
mine. Eyal's results indicate those miners have incentives to attack
pools, and additionally they have the incentive of killing off pools to
make it difficult for new competition to get established, yet they
themselves are not vulnerable to that attack.

Moving to a state where new hashing power can't be brought online except
in large quantities is not a positive development for the ecosystem.

This is also way I described the suggestion that Eyal's results are a
good thing as academic - while the idea hypothetically works in a pure
open pool vs. open pool scenario, the real world is significantly more
complex than that simple model.

> Peter, you allude to a specific suggestion from Luke-Jr. Can you
> please describe what it is?

Basically you have the pool pick a secret k for each share, and commit
to H(k) in the share. Additionally the share commits to a target divider
D. The PoW validity rule is then changed from H(block header) < T, to be
H(block header) < T * D && H(H(block header) + k) 

Re: [bitcoin-dev] We need to fix the block withholding attack

[Natanael via bitcoin-dev]

Wouldn't block withhold be fixed by not letting miners in pools know which
block candidates are valid before the pool knows? (Note: I haven't read any
other proposals for how to fix it, this may already be known)

As an example, by having the pool use the unique per-miner nonces sent to
each miner for effective division of labor as a kind of seed / commitment
value, where one in X block candidates will be valid, where X is the
current ratio between partial PoW blocks sent as mining proofs and the full
difficulty?

The computational work of the pool remains low (checking this isn't harder
than the partial PoW validation already performed), they pool simply looks
at which commitment value from the pool that the miner used, looks up the
correct committed value and hashes that together with the partial PoW. If
it hits the target, the block is valid.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] We need to fix the block withholding attack

[Natanael via bitcoin-dev]

Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>  An attacker pool (A) can take a certain portion of its hashpower,
>> use it to mine on behalf of victim pool (B), furnish partial proofs of
work
>> to B, but discard any full blocks it discovers.
>
> I wonder if part of the problem here is that there is no pool identity
linked to mining pools.
>
> If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.

Our approaches can be combined.

Each pool (or solo miner) has a public key included in their blocks that
identifies them to their miners (solo miners can use their own unique
random keys every time). This public key may be registered with DNSSEC+DANE
and the pool could point to their domain in the block template as an
identifier.

For each block the pool generates a nonce, and for each of every miner's
workers it double-hashes that nonce with their own public key and that
miner's worker ID and the previous block hash (to ensure no accidental
overlapping work is done).

The double-hash is a commitment hash, the first hash is the committed value
to be used by the pool as described below. Publishing the nonce reveals how
the hashes were derived to their miners.

Each miner puts this commitment hash in their blocks, and also the public
key of the pool separately as mentioned above.

Here's where it differs from standard mining: both the candidate block PoW
hash and the pool's commitment value above determines block validity
together.

If total difficulty is X and the ratio for full blocks to candidate blocks
shared with the pool is Y, then the candidate block PoW now has to meet X/Y
while hashing the candidate block PoW + the pool's commitment hash must
meet Y, which together makes for X/Y*Y and thus the same total difficulty.

So now miners don't know if their blocks are valid before the pool does, so
withholding isn't effective, and the public key identifiers simultaneously
stops a pool from telling honest but naive miners to attack other pools
using whatever other schemes one might come up with.

The main differences are that there's a public key identifier the miners
are told about in advance and expect to see in block templates, and that
that now the pool has to publish this commitment value together with the
block that also contains the commitment hash, and that this is verified
together with the PoW.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[joe2015--- via bitcoin-dev]

Link to better formatted version for web-users:
https://bitcointalk.org/index.php?topic=1296628.0

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

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Peter Todd via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia  wrote:
>On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 2) This reverses the useful minimization attribute of HD wallets -
>"just
>backup the seed"
>
>It would be nice if the bip37 filter matching algorithm was extended to
>serve up the proof.
>
>And if server-based wallets did the same it would preserve the "just
>backup
>the seed" functionality.

Exactly! The information will be out there - "just backup the seed" requires 
someone to have the exact same data needed to generate the TXO-unspent proof 
that my proposal requires to spend an old txout.

tl;dr: jgarzik is incorrect; theres no difference at all from the status quo.
-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWdtjA
AAoJEMCF8hzn9Lncz4MH/iwwa7xlbrJJiYqe7Hccr3Vm5D/qbv60eYi2btPDHFo9
mRnijzqFtt60e1AoFr9NwnCrAhhGmYkWsxLcA2oF+38H12DS9qsb9oT+pckJX34V
v06+Uap89v9VTHcxVrOEQUCx+9xQO7WkpFw/OTZJA4nmFZ8lvbgDGWE9q7mjQKof
QU1FiOM7mI6QCU8xTjRvVX5pTwvYNB7PAie/UoCfWU7/QdvsgTHRe4pq0XwJqHKy
xCr0DbfMZ2TvLFXitS5ZgTbDHURljjHlE7Qdmk9AcFNpI0PCR9YrZ5Mgb10sMygr
kX3V3uzjx2YBjKEpX9fqk6Kf/aufUqQ1PRBHF3m6bSE=
=mtj/
-END PGP SIGNATURE-

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer via bitcoin-dev]

On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd  wrote:

> There are a number of techniques that can be used to detect block
> withholding attacks that you are not aware of. These techniques usually
> have the characteristic that if known they can be avoided, so obviously
> those who know about them are highly reluctant to reveal what exactly
> they are. I personally know about some of them and have been asked to
> keep that information secret, which I will.
>

Indeed, there are lots of weak measures that one could employ against
an uninformed attacker. As I mentioned before, these are unlikely to be
effective against a savvy attacker, and this is a good thing.


> In the context of KYC, this techniques would likely hold up in court,
> which means that if this stuff becomes a more serious problem it's
> perfectly viable for large, well-resourced, pools to prevent block
> withholding attacks, in part by removing anonymity of hashing power.
> This would not be a positive development for the ecosystem.
>

KYC has a particular financial-regulation connotation in Bitcoin circles,
of which I'm sure you're aware, and which you're using as a spectre.
You don't mean government-regulated-KYC a la FINCEN and Bitcoin
exchanges like Coinbase, you are just referring to a pool operator
demanding to know that its customer is not coming from its competitors'
data centers.

And your prediction doesn't seem well-motivated or properly justified.
There are tons of conditionals in your prediction, starting with the premise
that every single open pool would implement some notion of identity
checking. I don't believe that will happen. Instead, we will have the bigger
pools become more suspicious of signing up new hash power, which is a
good thing. And we will have small groups of people who have some reason
for trusting each other (e.g. they know each other from IRC, conferences,
etc) band together into small pools. These are fantastic outcomes for
decentralization.

Secondly, DRM tech can also easily be used to prevent block withholding
> attacks by attesting to the honest of the hashing power. This is being
> discussed in the industry, and again, this isn't a positive development
> for the ecosystem.
>

DRM is a terrible application. Once again, I see that you're trying to use
those
three letters as a spectre as well, knowing that most people hate DRM, but
keep in mind that DRM is just an application -- it's like pointing to Adobe
Flash
to taint all browser plugins.

The tech behind DRM is called "attestation," and it provides a technical
capability not possible by any other means. In essence, attestation can
ensure that
a remote node is indeed running the code that it purports to be running.
Since
most problems in computer security and distributed systems stem from not
knowing what protocol the attacker is going to follow, attestation is the
only
technology we have that lets us step around this limitation.

It can ensure, for instance,
  - that a node purporting to be Bitcoin Core (vLatest) is indeed running an
unadulterated, latest version of Bitcoin Core
  - that a node claiming that it does not harvest IP addresses from SPV
clients indeed does not harvest IP addresses.
  - that a cloud hashing outfit that rented out X terahashes to a user did
indeed rent out X terahashes to that particular user,
  - that a miner operating on behalf of some pool P will not misbehave and
discard perfectly good blocks
and so forth. All of these would be great for the ecosystem. Just getting
rid
of the cloudhashing scams would put an end to a lot of heartache.

> Keep in mind that when an open pool gets big, like GHash did and
> > two other pools did before them, the only thing at our disposal used
> > to be to yell at people about centralization until they left the big
> > pools and reformed into smaller groups. Not only was such yelling
> > kind of desperate looking, it wasn't incredibly effective, either.
> > We had no protocol mechanisms that put pressure on big pools to
> > stop signing up people. Ittay's discovery changed that: pools that
> > get to be very big by indiscriminately signing up miners are likely to
> > be infiltrated and their profitability will drop. And Peter's post is
> > evidence that this is, indeed, happening as predicted. This is a
> > good outcome, it puts pressure on the big pools to not grow.
>
> GHash.io was not a pure pool - they owned and operated a significant
> amount of physical hashing power, and it's not at all clear that their %
> of the network actually went down following that 51% debacle.
>

Right, it's not clear at all that yelling at people has much effect. As much
fun as I had going to that meeting with GHash in London to ask them to
back down off of the 51% boundary, I am pretty sure that yelling at large
open pools will not scale. We needed better mechanisms for keeping pools
in check.

And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
time when we should 

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Tier Nolan via bitcoin-dev]

This is essentially the "nuclear option".  You are destroying the current
chain (converting it to a chain of coinbases) and using the same POW to
start the new chain.  You are also giving everyone credit in the new chain
equal to their credit in the old chain.

It would be better if the current chain wasn't destroyed.

This could be achieved by adding the hash of an extended block into the
coinbase but not requiring the coinbase to be the only transaction.

The new block is the legacy block plus the associated extended block.

Users would be allowed to move money to the extended block by spending it
to a specific output template.

 OP_1 OP_TO_EXTENDED OP_TRUE

OP_1 is the extended block index and initially, only one level is available.

This would work like P2SH.  Users could spend the money on the extended
block chain exactly as they could on the main chain.

Money can be brought back the same way.

   ...   OP_0 OP_UNLOCK OP_TRUE

The txids are for transactions that have been locked in root chain.  The
transaction is only valid if they are all fully funded.  The fee for the
transaction would be fee - (cost to fund unlocked txids).  A negative fee
tx would be invalid.

This has the advantage that it keeps the main chain operating.  People can
still send money with their un-upgraded clients.  There is also an
incentive to move funds to the extended block(s).  The new extended blocks
are more complex, but potentially have lower fees.  Nobody is forced to
change.  If the large blocks aren't needed, nobody will both to use them.

The rule could be

Now:
0) 1 MB

After change over
0) 1 MB
1) 2 MB

After 2 years
0) 1 MB
1) 2 MB
2) 4MB

After 4 years
0) 1 MB
1) 2 MB
2) 4MB
3) 8MB
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev