Re: [bitcoin-dev] Paper Wallet support in bitcoin-core

[Andrew Johnson via bitcoin-dev]

One consideration of exposing this in QT is that it may encourage users to
generate paper wallets(which are generally used and recommended for cold
storage) from online machines, rendering them moreso lukewarm rather than
cold, since the keys weren't generated in an air-gapped environment.  When
using bitaddress.org locally(we *are *all only using it locally and not
directly from the online webpage, right? ;) ) you've at least made the
effort to seek out the repo, clone it locally, and use it on an offline
machine and not retain any data from that session.

If we include this as a function in the reference implementation, how many
people are going to be making paper wallets with the intention of cold
storage on a machine that's potentially compromised?  As
adoption(hopefully) continues to increase the number of less than tech
savvy people using bitcoin will increase.

I'd suggest that any UI in QT include some sort of a modal dialog that
informs the user that this is not a secure cold storage address unless it
was created on an offline machine and printed on a non-networked printer,
and the prompt must be accepted and dismissed before the wallet will
provide the requested keys.


On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm writing to suggest and discuss the addition of paper wallet
> functionality in bitcoin-core software, starting with a single new RPC
> call: genExternalAddress [type].
>
> -- rationale --
>
> bitcoin-core is the most trusted and most secure bitcoin implementation.
>
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org.  This requires placing trust in an additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
>
> In the case of a website generator, the code must be audited again each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
>
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
>
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated private
> keys are added to the bitcoin-core wallet and cannot be removed... or in
> the case of hd-wallets are deterministically derived.
>
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
>
>
> -
>
> genexternaladdress ( "type" )
>
> Returns a new Bitcoin address and private key for receiving
> payments. This key/address is intended for external usage such as
> paper wallets and will not be used by internal wallet nor written to
> disk.
>
> Arguments:
> 1. "type"(string, optional) one of: p2pkh, p2sh-p2wpkh
> default: p2sh-p2wpkh
>
> Result:
> {
> "privKey"(string) The private key in wif format.
> "address"(string) The address in p2pkh or p2sh-p2wpkh
>   format.
> }
>
>
> Examples:
> > bitcoin-cli genexternaladdress
>
>
> 
>
> This API is simple to implement and use.  It provides enough
> functionality for any moderately skilled developer to create their own
> paper wallet creation script using any scripting language, or even for
> advanced users to perform using bitcoin-cli or debug console.
>
> If consensus here is in favor of including such an API, I will be happy
> to take a crack at implementing it and submitting a pull request.
>
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
>
> Also, I welcome suggestions for a better name, or maybe there could be
> some improvements to the param(s), such as calling p2sh-p2wpkh "segwit"
> instead.
>
>
>  further work 
>
>
> Further steps could be taken in this direction, but are not necessary
> for a useful first-step.  In particular:
>
> 1. an RPC call to generate an external HD wallet seed.
> 2. an RPC call to generate N key/address pairs from a given seed.
> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
> generation (and printing?) for end-users, complete with nice graphics,
> qr codes, etc.
>
>
>
>
>
>
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Andrew Johnson

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Andrew Johnson via bitcoin-dev]

I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.

I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes coming online, they're the
only ones going after very old blocks.   I could see that as a potential
attack vector, overwhelm the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real" new node to get up
to speed in a reasonable amount of time.

Perhaps the answer there would be a way to pay an archival node a small
amount of bitcoin in order to retrieve blocks older than a certain cutoff?
Include an IP address for the node asking for the data as metadata in the
transaction...  Archival nodes could set and publish their own policy, let
the market decide what those older blocks are worth.  Would also help to
incentivize running archival node, which we do need.  Of course, this isn't
very user friendly.

We can take this to bitcoin-discuss, if we're getting too far off topic.


On Wed, Mar 29, 2017 at 11:25 AM David Vorick 
wrote:

>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" 
> wrote:
>
> What's stopping these users from running a pruned node?  Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Andrew Johnson via bitcoin-dev]

What's stopping these users from running a pruned node?  Not every node
needs to store a complete copy of the blockchain.


On Wed, Mar 29, 2017 at 11:18 AM David Vorick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Perhaps you are fortunate to have a home computer that has more than a
> single 512GB SSD. Lots of consumer hardware has that little storage. Throw
> on top of it standard consumer usage, and you're often left with less than
> 200 GB of free space. Bitcoin consumes more than half of that, which feels
> very expensive, especially if it motivates you to buy another drive.
>
> I have talked to several people who cite this as the primary reason that
> they are reluctant to join the full node club.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Andrew Johnson
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

[Andrew Johnson via bitcoin-dev]

On Mon, Mar 20, 2017 at 10:47 AM John Hardy  wrote:

> By doing this you're significantly changing the economic incentives
behind bitcoin mining. How can you reliably invest in hardware if you have
no idea when or if your profitability is going to be cut by 50-75% based on
a whim?


Of course, that's why this is a last resort, successfully activated only in
response to a contentious hard fork. If it succeeds just once it should
help prevent the same situation occurring in the future.


This seems a lot more disruptive to the network than a simple hard fork to
increase the block size.  Compromise is the answer here, not taking our
ball and going home, in my humble opinion.

> You may also inadvertently create an entirely new attack vector if 50-75%
of the SHA256 hardware is taken offline and purchased by an entity who
intends to do harm to the network.

How so? If you have four proof of work methods, that 50-75% of SHA256
hashpower would equate to 13-18% of total hashpower. If you can harm the
network with this much hashpower bitcoin was DOA.


I'm assuming the difficulty on the SHA256 PoW would drop by 50-75% as
well.  So not nearly as bad as it would be with a single PoW and that much
hardware were available to an adversary, you're correct.

How would you handle starting difficulty on the other 3 PoWs?  Seems like
it would be a race to start with, which strikes me as another potential
attack vector until the amount of hardware and price of production balances
with the price of the coin(which is likely to be volatile during this
turbulent period).  Unless you start the difficulty at a higher value, then
you're just doing centralized economic planning and hoping you got the
numbers right so that you get the right balance of security vs incentive to
do malicious things like double spends.

All the solutions that people keep positing(such as Luke's complete PoW
change) seem like they'd be a whole lot more disruptive to the network than
an EC fork would be.

Isn't the main reason that everyone is up in arms because a contentious
hard fork is dangerous?  I just don't understand how any of these solutions
are safer.

At that point we've lost our claim to fame, that changes to the protocol
are hard and you can trust that your value is safe.  What you're advocating
seems like it would result in a huge drop in hashing security.

--
*From:* Andrew Johnson 
*Sent:* Monday, March 20, 2017 3:38:01 PM
*To:* Bitcoin Protocol Discussion; John Hardy
*Subject:* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR
POWA): Protecting Bitcoin from malicious miners

By doing this you're significantly changing the economic incentives behind
bitcoin mining. How can you reliably invest in hardware if you have no idea
when or if your profitability is going to be cut by 50-75% based on a whim?

You may also inadvertently create an entirely new attack vector if 50-75%
of the SHA256 hardware is taken offline and purchased by an entity who
intends to do harm to the network.

Bitcoin only works if most miners are honest, this has been known since the
beginning.

On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

I’m very worried about the state of miner centralisation in Bitcoin.

I always felt the centralising effects of ASIC manufacturing would resolve
themselves once the first mover advantage had been exhausted and the
industry had the opportunity to mature.

I had always assumed initial centralisation would be harmless since miners
have no incentive to harm the network. This does not consider the risk of a
single entity with sufficient power and either poor, malicious or coerced
decision making. I now believe that such centralisation poses a huge risk
to the security of Bitcoin and preemptive action needs to be taken to
protect the network from malicious actions by any party able to exert
influence over a substantial portion of SHA256 hardware.

Inspired by UASF, I believe we should implement a Malicious miner Reactive
Proof of Work Additions (MR POWA).

This would be a hard fork activated in response to a malicious attempt by a
hashpower majority to introduce a contentious hard fork.

The activation would occur once a fork was detected violating protocol
(likely oversize blocks) with a majority of hashpower. The threshold and
duration for activation would need to be carefully considered.

I don’t think we should eliminate SHA256 as a hashing method and change POW
entirely. That would be throwing the baby out with the bathwater and hurt
the non-malicious miners who have invested in hardware, making it harder to
gain their support.

Instead I believe we should introduce multiple new proofs of work that are
already established and proven within existing altcoin implementations. As
an example we could add Scrypt, Ethash and Equihash. Much of the code and
mining infrastructure already exists. 

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

[Andrew Johnson via bitcoin-dev]

I think this is an excellent idea. I consider myself to be extremely
data-driven and logical in my thinking, and have still fallen victim to
thinking "oh great, what's  on
about now?" when seeing something posted or proposed.

And vice versa, it prevents people from being more partial to a bad or not
so great idea simply because it was posited by someone they hold in high
regard.

Simple, yet effective.  I would actually even go a step further and say
that all BIPs should be done this way as a matter of procedure, I can't
think of a downside.


On Sat, Mar 18, 2017 at 10:46 AM Chris Stewart via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As everyone in the Bitcoin space knows, there is a massive scaling debate
> going on. One side wants to increase the block size via segwit, while the
> other side wants to increase via hard fork. I have strong opinions on the
> topic but I won’t discuss them here. The point of the matter is we are
> seeing the politicization of protocol level changes. The critiques of these
> changes are slowly moving towards critiques based on who is submitting the
> BIP -- not what it actually contains. This is the worst thing that can
> happen in a meritocracy.
>
> *Avoiding politicization of technical changes in the future*
>
> I like what Tom Elvis Judor did when he submitted his MimbleWimble white
> paper to the technical community. He submitted it under a pseudonym, over
> TOR, onto a public IRC channel. No ego involved — only an extremely
> promising paper. Tom (and Satoshi) both understood that it is only a matter
> of time before who they are impedes technical progress of their system.
>
> I propose we move to a pseudonymous BIP system where it is required for
> the author submit the BIP under a pseudonym. For instance, the format could
> be something like this:
>
> BIP: 1337
>
> Author: 9458b7f9f76131f18823d73770e069d55beb2...@protonmail.com
>
> BIP content down here
>
> The hash “6f3…9cd0” is just my github username, christewart, concatenated
> with some entropy, in this case these bytes:
> 639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b
>
> and then hashed with RIPEMD160. I checked this morning that protonmail can
> support RIPEMD160 hashes as email addresses. Unfortunately it appears it
> cannot support SHA256 hashes.
>
> There is inconvenience added here. You need to make a new email address,
> you need to make a new github account to submit the BIP. I think it is
> worth the cost -- but am interested in what others think about this. I
> don't think people submitting patches to a BIP should be required to submit
> under a pseudonym -- only the primary author. This means only one person
> has to create the pseudonym. From a quick look at the BIPs list it looks
> like the most BIPs submitted by one person is ~10. This means they would
> have had to create 10 pseudonyms over 8 years -- I think this is
> reasonable.
>
> *What does this give us?*
>
> This gives us a way to avoid politicization of BIPs. This means a BIP can
> be proposed and examined based on it’s technical merits. This levels the
> playing field — making the BIP process even more meritocratic than it
> already is.
>
> If you want to claim credit for your BIP after it is accepted, you can
> reveal the preimage of the author hash to prove that you were the original
> author of the BIP. I would need to reveal my github username and
> “639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b”
>
> *The Future*
> Politicization of bitcoin is only going to grow in the future. We need to
> make sure we maintain principled money instead devolving to a system where
> our money is based on a democratic vote — or the votes of a select few
> elites. We need to vet claims by “authority figures” whether it is Jihan
> Wu, Adam Back, Roger Ver, or Greg Maxwell. I assure you they are human —
> and prone to mistakes — just like the rest of us. This seems like a simple
> way to level the playing field.
>
> Thoughts?
>
> -Chris
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 
Andrew Johnson
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

[Andrew Johnson via bitcoin-dev]

If a small dissenting minority can block all forward progress then bitcoin
is no longer interesting.  What an incredibly simple attack vector...

No need to break any cryptography, find a bug to exploit, build tens of
millions of dollars in mining hardware, spend lots of bitcoin on fees to
flood the network, or be clever or expend any valuable resources in any
way, shape, or form.

Just convince(or pay, if you do want to expend some resources) a few
people(or make up a few online personas) to staunchly refuse to accept
anything at all and the entire system is stuck in 2013(when we first
started widely discussing a blocksize increase seriously).

Is that really the bitcoin that you want to be a part of?

When the 1MB cap was implemented it was stated specifically that we could
increase it when we needed it.  The white paper even talks about scaling to
huge capacity.  Not sure where you got the idea that we all agreed to stay
at 1MB forever, I certainly didn't.  It was never stated or implied that we
could change the coin cap later(please cite if I'm mistaken).


On Feb 8, 2017 12:16 PM, "alp alp"  wrote:

Doing nothing is the rules we all agreed to.  If those rules are to be
changed,nearly everyone will need to consent.  The same rule applies to the
cap, we all agreed to 21m, and if someone wants to change that, nearly
everyone would need to agree.


On Feb 8, 2017 10:28 AM, "Andrew Johnson" 
wrote:

It is when you're talking about making a choice and 6.3x more people prefer
something else. Doing nothing is a choice as well.

Put another way, if 10% supported increasing the 21M coin cap and 63% were
against, would you seriously consider doing it?

On Feb 8, 2017 9:57 AM, "alp alp"  wrote:

> 10% is not a tiny minority.
>
> On Feb 8, 2017 9:51 AM, "Andrew Johnson" 
> wrote:
>
>> You're never going to reach 100% agreement, and stifling the network
>> literally forever to please a tiny minority is daft.
>>
>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 10% say literally never.  That seems like a significant
>> disenfranchisement and lack of consensus.
>>
>> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr  wrote:
>>>
 On Monday, February 06, 2017 6:19:43 PM you wrote:
 > >My BIP draft didn't make progress because the community opposes any
 block
 > >size increase hardfork ever.
 >
 > Luke, how do you know the community opposes that? Specifically, how
 did you
 > come to this conclusion?

 http://www.strawpoll.me/12228388/r
>>>
>>>
>>> That poll shows 63% of votes want a larger than 1 MB block by this
>>> summer. How do you go from that to "the community opposes any block
>>> increase ever"? It shows the exact opposite of that.
>>>
>>>
 > >Your version doesn't address the current block size
 > >issues (ie, the blocks being too large).
 >
 > Why do you think blocks are "too large"? Please cite some evidence.
 I've
 > asked this before and you ignored it, but an answer would be helpful
 to the
 > discussion.

 Full node count is far below the safe minimum of 85% of economic
 activity.

>>>
>>> Is this causing a problem now? If so, what?
>>>
>>>
 Typically reasons given for people not using full nodes themselves come
 down
 to the high resource requirements caused by the block size.
>>>
>>>
>>> The reason people stop running nodes is because there's no incentive to
>>> counteract the resource costs. Attempting to solve this by making blocks
>>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>>> full node operation would fix that problem.)
>>>
>>> - t.k.
>>>
>>>
>>> ___
>>> 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] A Modified Version of Luke-jr's Block Size BIP

[Andrew Johnson via bitcoin-dev]

It is when you're talking about making a choice and 6.3x more people prefer
something else. Doing nothing is a choice as well.

Put another way, if 10% supported increasing the 21M coin cap and 63% were
against, would you seriously consider doing it?

On Feb 8, 2017 9:57 AM, "alp alp"  wrote:

> 10% is not a tiny minority.
>
> On Feb 8, 2017 9:51 AM, "Andrew Johnson" 
> wrote:
>
>> You're never going to reach 100% agreement, and stifling the network
>> literally forever to please a tiny minority is daft.
>>
>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 10% say literally never.  That seems like a significant
>> disenfranchisement and lack of consensus.
>>
>> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr  wrote:
>>>
 On Monday, February 06, 2017 6:19:43 PM you wrote:
 > >My BIP draft didn't make progress because the community opposes any
 block
 > >size increase hardfork ever.
 >
 > Luke, how do you know the community opposes that? Specifically, how
 did you
 > come to this conclusion?

 http://www.strawpoll.me/12228388/r
>>>
>>>
>>> That poll shows 63% of votes want a larger than 1 MB block by this
>>> summer. How do you go from that to "the community opposes any block
>>> increase ever"? It shows the exact opposite of that.
>>>
>>>
 > >Your version doesn't address the current block size
 > >issues (ie, the blocks being too large).
 >
 > Why do you think blocks are "too large"? Please cite some evidence.
 I've
 > asked this before and you ignored it, but an answer would be helpful
 to the
 > discussion.

 Full node count is far below the safe minimum of 85% of economic
 activity.

>>>
>>> Is this causing a problem now? If so, what?
>>>
>>>
 Typically reasons given for people not using full nodes themselves come
 down
 to the high resource requirements caused by the block size.
>>>
>>>
>>> The reason people stop running nodes is because there's no incentive to
>>> counteract the resource costs. Attempting to solve this by making blocks
>>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>>> full node operation would fix that problem.)
>>>
>>> - t.k.
>>>
>>>
>>> ___
>>> 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] Three hardfork-related BIPs

[Andrew Johnson via bitcoin-dev]

On Jan 26, 2017 10:15 PM, "Luke Dashjr"  wrote:

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1.  You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?

The limit only drops all the way to 300k if it activates before 2017 April.
Considering that this requires the consensus of a hardfork, followed by a
release in software, and then actual activation by miners using BIP9, I
think
it's extremely unlikely to activate by then.

But more importantly: such a drop would probably be good for the network in
the long-term. As explained in the Rationale section, 300k is necessary to
maintain our *current* IBD (first-time node sync) costs even with
technological improvements (which appear to be slowing lately).


Other researchers have come to the conservative conclusion that we could
handle 4MB blocks today.  Imagine bitcoin had been invented in 1987 and had
a block size correspondent to the internet connections and hard drive sizes
of the day.  Your proposal would have probably brought us from 1Kb(then
reduced to 300 bytes) and up to a whopping 20Kb or so today.  Yet even you
think we can handle 15x that today.

You drastically underestimate the speed of technological progression, and
seem to fancy yourself the central planner of bitcoin.  Isn't that one of
the things we're trying to get away from, centrally planned economics?


> We're already at capacity today, surely you're not serious with this
> proposal?

We are only at capacity because the space is available below actual costs,
and/or because efficient alternatives are not yet widely supported. A
reduction of block size will likely squeeze out spam, and perhaps some
unsustainable microtransaction use, but the volume which actually *benefits
from* the blockchain's security should continue along fine. Furthermore,
once
Lightning is widely implemented as well-tested, at least microtransactions
are
likely to gain a huge improvement in efficiency, reducing legitimate usage
of
block sizes well below 300k naturally - that is frankly when I first expect
this proposal to be seriously considered for activation (which is
independent
from the consensus to include support for it in nodes).


Legitimate usage is a transaction that pays the appropriate fee to be
included.  The term legitimate transaction should be stricken from one's
vocabulary when describing a censorship resistant system such as bitcoin.


> When you promised code for a hard forking block size increase in the HK
> agreement I don't believe that a decrease first was made apparent.  While
> not technically in violation of the letter of the agreement, I think this
> is a pretty obviously not in the spirit of it.

I did not mention the HK "roundtable", because this is indeed not in the
spirit of what we set out to do, and do not wish this to be interpreted as
some kind of slap in the face of the honest participants of that discussion.


Too late for that, I suspect.


This proposal is, however, the best I am currently able to honestly
recommend
that meets the hard criteria outlined at Hong Kong a year ago. (Continued
work
on the MMHF/SHF concept may eventually deliver a better solution, but it is
not yet ready.)

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

Re: [bitcoin-dev] Three hardfork-related BIPs

[Andrew Johnson via bitcoin-dev]

Comment on #1.  You're dropping the blocksize limit to 300KB and only
reaching the limit that we have in place today 7 years later?  We're
already at capacity today, surely you're not serious with this proposal?
When you promised code for a hard forking block size increase in the HK
agreement I don't believe that a decrease first was made apparent.  While
not technically in violation of the letter of the agreement, I think this
is a pretty obviously not in the spirit of it.

On Jan 26, 2017 7:07 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

I've put together three hardfork-related BIPs. This is parallel to the
ongoing
research into the MMHF/SHF WIP BIP, which might still be best long-term.

1) The first is a block size limit protocol change. It also addresses three
criticisms of segwit: 1) segwit increases the block size limit which is
already considered by many to be too large; 2) segwit treats pre-segwit
transactions “unfairly” by giving the witness discount only to segwit
transactions; and 3) that spam blocks can be larger than blocks mining
legitimate transactions. This proposal may (depending on activation date)
initially reduce the block size limit to a more sustainable size in the
short-
term, and gradually increase it up over the long-term to 31 MB; it will also
extend the witness discount to non-segwit transactions. Should the initial
block size limit reduction prove to be too controversial, miners can simply
wait to activate it until closer to the point where it becomes acceptable
and/or increases the limit. However, since the BIP includes a hardfork, the
eventual block size increase needs community consensus before it can be
deployed. Proponents of block size increases should note that this BIP does
not interfere with another more aggressive block size increase hardfork in
the
meantime. I believe I can immediately recommend this for adoption; however,
peer and community review are welcome to suggest changes.
Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
Code: https://github.com/bitcoin/bitcoin/compare/master...luke-
jr:bip-blksize
(consensus code changes only)

2) The second is a *preparatory* change, that should allow trivially
transforming certain classes of hardforks into softforks in the future. It
essentially says that full nodes should relax their rule enforcement, after
sufficient time that would virtually guarantee they have ceased to be
enforcing the full set of rules anyway. This allows these relaxed rules to
be
modified or removed in a softfork, provided the proposal to do so is
accepted
and implemented with enough advance notice. Attempting to implement this has
proven more complicated than I originally expected, and it may make more
sense
for full nodes to simply stop functioning (with a user override) after the
cut-off date). In light of this, I do not yet recommend its adoption, but am
posting it for review and comments only.
Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki

3) Third is an anti-replay softfork which can be used to prevent replay
attacks whether induced by a hardfork-related chain split, or even in
ordinary
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for
the
Bitcoin scripting system that allows construction of transactions which are
valid only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-
noreplay.mediawiki

Luke
___
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] Managing block size the same way we do difficulty (aka Block75)

[Andrew Johnson via bitcoin-dev]

"You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks."

This is easily detectable as long as the network isn't heavily
partitioned(which is an assumption we make today in order for transaction
propagation to work reliably as well as for xThin and CompactBlocks to work
effectively to reduce block transmission time).  Other miners would have an
incentive to intentionally orphan blocks that contained a large number of
transactions that their nodes were unaware of.

I don't think this sort of attack would last long.  Even later when
subsidies are drastically reduced, you would still lose out on significant
genuine fee revenue if your orphan rate increased even 10%(one out of ten
of your poison blocks intentionally orphaned by another miner).

On Dec 11, 2016 11:12 AM, "s7r via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

 t. khan wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the
> Block75 system. Even if it were attempted and assuming the goal was to
> create bigger blocks, the maximum possible increase would be 25% over
> the previous block size. And, that size would only last for two weeks
> before readjusting down. It would cost them more in transaction fees to
> stuff the network than they could ever make up. To game the system,
> they'd have to game it forever with no possibility of profit.
>

This is an incentive, if few miners agree to create a large conglomerate
that will ultimately control the network.

You miss something obvious that makes this attack actually free of cost.
Nothing will "cost them more in transaction fees". A miner can create
thousands of transactions paying to himself, and not broadcast them to
the network, but hold them and include them in the blocks he mines. The
fees are collected by him because transactions are included in a block
that he mined and the left amount is in another wallet of the same
person. Repeat this continuously to fill blocks.


> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly
> more orphaned blocks.
>

Topology and bandwidth speed / hash rate of the network cannot be
controlled - if we make assumptions about these it might have terrible
consequences.

Even if we take in consideration that bandwidth will only grow and disk
space will only cost less (which is not something we can safely assume,
by the way) the hard limit max. block size cannot grow to unlimited
value (even if the growth happens over time). There is also a validation
cost in time for each block, for the health of the network any node
should be able to download _and_ validate a block, before next block
gets mined.

You said in another post that a permanent solution is preferred, rather
than kicking the can down the road. I fully agree, as well as many
others reading this list, but the permanent solution doesn't necessarily
have to be increasing the max block size dynamically.

If you think about it the other way around, dynamically growing the max
block size is also kicking the can down the road ... just without having
to touch it and get dust on the boot ;)


___
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 clearing house addresses

[Andrew Johnson via bitcoin-dev]

"This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip."

This would have prevented the Bitfinex hack if BitGo did this, but it
wouldn't have helped if the Bitfinex offline key had been compromised
instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
by Bitfinex's hot key and BitGo's key, they required 2 of 2.

If I'm understanding correctly, what Matthew is proposing is a new type of
UTXO that is only valid to be spent as an nLockTime transaction and can be
reversed by some sort of RBF-type transaction within that time period, I
believe.

But I don't think this will work. What do you do if the keys are
compromised?  What's to stop the attacker from locking the coins up
indefinitely by repeatedly broadcasting a refund transaction each time you
try to spend to an uncompromised address?

You'd need a third distinct key required for the refund TXN that's separate
from the keys used to sign the initial nLockTime TXN.  And the refund TXN
would need to be able to go to a new address entirely.

On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
> wrote:
> > In light of the recent hack: what does everyone think of the idea of
> > creating a new address type that has a reversal key and settlement layer
> > that can be used to revoke transactions?
>
> This isn't something that makes sense at the address, since it represents
> the
> recipient and not the sender. Transactions are not sent from addresses
> ever.
>
> > You could specify so that transactions "sent" from these addresses must
> > receive N confirmations before they can't be revoked, after which the
> > transaction is "settled" and the coins become redeemable from their
> > destination output. A settlement phase would also mean that a
> transaction's
> > progress was publicly visible so transparent fraud prevention and
> auditing
> > would become possible by anyone.
>
> This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> Luke
> ___
> 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] Dynamic limit to the block size - BIP draft discussion

[Andrew Johnson via bitcoin-dev]

I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political.  BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap.  It also seems silly to worry
about a selfish mining attack if you're going to institute a miner vote
that an entity with that much hashrate can noticeably influence anyway.

101 is better but is still attempting to make a guess as to technological
progression quite far into the future.  And then when we do finally hit 8GB
we will need yet another hard fork if we need to go bigger(or we may need
to do it earlier if the increase schedule isn't aggressive enough).  And
who knows how large the ecosystem may be at that time, a hard fork may be
an undertaking of truly epic proportions due to the sheer number of devices
and embedded firmware that operates on the block chain.

I've done no math on this(posting from mobile) but something similar to
this would be reasonable, I think.  Unbounded growth, as Adam points out,
is also undesirable.

Every 4032 blocks (~4 weeks), the maximum block size will be decreased by
10% *IF* a minimum of 2500 blocks has a size <= 40% of the maximum block
size at that time.

This requires a larger threshold to be crossed to move downwards, that way
we hopefully aren't oscillating back and forth constantly.  I'll try to do
some blockchain research sometime this week and either back my plucked from
the air numbers or change them.

Andrew Johnson
On Sep 8, 2015 10:11 AM, "Washington Sanchez via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> 1) It's not really clear to me how that would work, but assuming it does
> then it will go into a basket of attacks that are possible but unlikely due
> to the economic disincentives to do so.
>
> 2) That said, is the Achilles heal of this proposal the lack of a
> mechanism to lower the block size?
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>
> On Wed, Sep 9, 2015 at 12:18 AM, Adam Back  wrote:
>
>> > A selfish mining attack would have to be performed for at least 2000
>> blocks over a period of 4 weeks in order to achieve a meager 10% increase
>> in the block size.
>>
>> You seem to be analysing a different attack - I mean that if someone
>> has enough hashrate to do a selfish mining attack, then setting up a
>> system that has no means to reduce block-size risks that at a point
>> where there is excess block-size they can use that free transaction
>> space to amplify selfish mining instead of collecting transaction
>> fees.
>>
>> Adam
>>
>
>
>
> --
> ---
> *Dr Washington Y. Sanchez *
> Co-founder, OB1 
> Core developer of OpenBazaar 
> @drwasho 
>
>
> ___
> 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