Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Jameson Lopp via bitcoin-dev]

On Fri, Apr 30, 2021 at 7:59 AM Amir Taaki via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A committee to guide the committee? You guys truly have lost the plot.
>
> All the good minds and cryptographers have left Bitcoin. What remains is
> an empty echo chamber.
>
> Truth is these problems start with lack of vision and long-term roadmap,
> not with the processes themselves.
>
> And the Bitcoin Core monopoly created this situation; one coin, one
> client, one vision. And the inevitable infighting for ultimate power.
>
> Really if we want to go down this route, there should be a long period
> of self reflection about where the problems began rather than patching
> some process and moving on.
>
> I propose Bitcoin Core is dissolved as the official Bitcoin project.


Nonsense, as it is not the official Bitcoin project. There is no such thing.

The community is free to elect their preferred version of Bitcoin.


Individuals have voted with their feet and are free to continue to do so.
It's anarchy, I tell you!


> And most importantly, Bitcoin developers commit to a fully specced
> standard that
> all implementations move towards using.
>

Who decides the spec? Perhaps... a committee of some sort?


>
> On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote:
> > Kalle should not be made an editor by an ad-hoc process. I reiterate
> > Greg's NACK.
> >
> > I propose that we form a stewardship committee of frequent contributors,
> > including you, Greg, and 21 others. The stewards appoint a small set of
> > editors with permanent oversight by the stewards. A defined process
> > prevents this controversy from arising in the future and makes
> > proceedings clear.
> >
> > My proposal has been moderated off of this list, but may be viewed here:
> > https://github.com/bitcoin/bips/pull/1113
> > 
> >
> > I care not for the role of initial transitory editor. I would be pleased
> > should any responsible community member shoulder this onus in my stead.
> >
> > Peace be upon you,
> >
> > JC
> >
> > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev
> >  > > wrote:
> >
> > On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via
> > bitcoin-dev wrote:
> > > I am opposed to the addition of Kalle Alm at this time.  Those who
> > > believe [this] will resolve the situation [...] re: PR1104 are
> > > mistaken.
> >
> > PR1104 has been merged.  Do you continue to oppose the addition?
> >
> > Thanks,
> >
> > -Dave
> > ___
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Transaction size & weight calculation tooling

[Jameson Lopp via bitcoin-dev]

Hi all,

Anyone who has built a Bitcoin wallet / service has to deal with a variety
of challenges when it comes to transaction construction. One of these
challenges is around determining an appropriate fee; aside from block space
market volatility and the inherent problems of forecasting the future, you
need to know how much block space for which your transaction needs to "bid."

Every time I've run into the problem of calculating the size of a
transaction with specific attributes I've ended up having to sift through
answers scatter across stack overflow posts, so I finally got around to
building a user friendly tool at
https://jlopp.github.io/bitcoin-transaction-size-calculator/

As I was looking for more data on constants to use in the calculation I was
informed that the folks at Bitcoin Optech have also been working on a
calculator: https://bitcoinops.org/en/tools/calc-size

It seems clear that this is a common problem for which we could use better
tooling. I'm also about 99% certain that there's at least 1 or 2 bugs in my
current calculator code.

Please bookmark and share these tools; if you're capable and so inclined,
code reviews would be greatly appreciated!

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

Re: [bitcoin-dev] BIP39 seeds

[Jameson Lopp via bitcoin-dev]

I believe it would depend upon the entropy used for the seed, as that would
affect how many bits the checksum represents.
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic

So for a 24 word / 256 bit mnemonic the checksum is 8 bits, thus there are
8 valid checksums and if you picked a random checksum from the wordlist of
2048 words you'd have a 1 in 256 chance of picking a valid one.

On Sun, Dec 23, 2018 at 1:44 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Has anybody already looked at this: given N randomly chosen words
> belonging to a BIP39 2048 words dictionary, what is the probability to
> get a "valid" BIP39 seed (ie with the right checksum)?
>
> The result looks (very) surprising to me and might have some use cases,
> just would like to know if this topic has already been discussed before
> going further
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Testnet block generation

[Jameson Lopp via bitcoin-dev]

This is normal behavior due to a special rule on testnet. For a detailed
explanation you can read
https://web.archive.org/web/20160910173004/https://blog.blocktrail.com/2015/04/in-the-darkest-depths-of-testnet3-16k-blocks-were-found-in-1-day/

- Jameson

On Thu, Jun 28, 2018 at 9:22 AM Mattia Rossi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Maybe is a common 'issue' but why the testnet3 of bitcoin network
> generate a block so fast?
> at lead 6 block per minute.
>
> Is this a normal behavior?
>
> Thanks in advance.
> ___
> 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] Possible change to the MIT license

[Jameson Lopp via bitcoin-dev]

Anyone who feels so inclined is free to "pick up the mantle" and defend
Bitcoin against perceived social attacks. I don't think that Bitcoin
protocol developers have any particular responsibility to do so, and as
such this particular discussion is likely going to quickly veer off-topic
for this mailing list.

On Tue, Feb 13, 2018 at 10:37 AM, Brian Lockhart 
wrote:

> > I don't think that Bitcoin should be reliant upon courts or governments
> to defend itself against attacks of any form.
>
> Agree 100%. Plus yeah, lotsa luck getting any success via those channels...
>
> But assuming the answer to the perceived problem is to “fight fire with
> fire” (using social / marketing based efforts) who “should” pick up the
> mantle here? Without inciting riots by asking the question, wouldn’t that
> ostensibly be something the Bitcoin Foundation would lead on here?  and runs for cover>
>
> In any case, it’s frustrating to watch the ongoing FUD and scammery going
> unanswered in any “official” capacity.
>
>
> On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev (
> bitcoin-dev@lists.linuxfoundation.org) wrote:
>
> If I'm understanding the problem being stated correctly:
>
> "Bitcoin is under a branding attack by fork coins."
>
> The proposed solution is to disincentivize fork coins from using the word
> Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me
> that the words of the license are basically useless unless there is an
> entity that intends to make use of court systems to threaten noncompliant
> projects into submission.
>
> In my opinion, the perceived attack on Bitcoin here is social /
> marketing-based, thus it makes sense that any defense against said attack
> should also be social / marketing-based. I don't think that Bitcoin should
> be reliant upon courts or governments to defend itself against attacks of
> any form.
>
> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org>:
>>
>> ***
>> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES
>> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS
>> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
>> (CORE) BLOCKCHAIN
>> ***
>>
>>
>> That's better solved with trademarks. (whoever would be the trademark
>> holder - Satoshi?)
>>
>> This would also prohibit any reimplementation that's not formally
>> verified to be perfectly compatible from using the name.
>>
>> It also adds legal uncertainty.
>>
>> Another major problem is that it neither affects anybody forking older
>> versions of Bitcoin, not people using existing independent blockchain
>> implementations and renaming them Bitcoin-Whatsoever.
>>
>> And what happens when an old version is technically incompatible with a
>> future version by the Core team due to not understanding various new
>> softforks? Which version wins the right to the name?
>>
>> Also, being unable to even mention Bitcoin is overkill.
>>
>> The software license also don't affect the blockchain data.
>>
>>
>> ___
>> 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] Possible change to the MIT license

[Jameson Lopp via bitcoin-dev]

If I'm understanding the problem being stated correctly:

"Bitcoin is under a branding attack by fork coins."

The proposed solution is to disincentivize fork coins from using the word
Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me
that the words of the license are basically useless unless there is an
entity that intends to make use of court systems to threaten noncompliant
projects into submission.

In my opinion, the perceived attack on Bitcoin here is social /
marketing-based, thus it makes sense that any defense against said attack
should also be social / marketing-based. I don't think that Bitcoin should
be reliant upon courts or governments to defend itself against attacks of
any form.

On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES
> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS
> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
> (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the trademark
> holder - Satoshi?)
>
> This would also prohibit any reimplementation that's not formally verified
> to be perfectly compatible from using the name.
>
> It also adds legal uncertainty.
>
> Another major problem is that it neither affects anybody forking older
> versions of Bitcoin, not people using existing independent blockchain
> implementations and renaming them Bitcoin-Whatsoever.
>
> And what happens when an old version is technically incompatible with a
> future version by the Core team due to not understanding various new
> softforks? Which version wins the right to the name?
>
> Also, being unable to even mention Bitcoin is overkill.
>
> The software license also don't affect the blockchain data.
>
>
> ___
> 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] Total fees have almost crossed the block reward

[Jameson Lopp via bitcoin-dev]

I'd hope that the incentives are in place to encourage high volume senders
to be more efficient in their use of block space by batching transactions
and implementing SegWit, though this may not be the case for providers that
pass transaction fees along to their users.

We've been trying to be more proactive about outreach regarding efficient
use of block space to our own customers at BitGo - when we break down the
cost savings of implementing a new technique, it generally helps to hasten
their adoption. I suspect that in many cases this is an issue of education
- we should be more proactive in calling out inefficient uses of block
space.

Good resources to bookmark and share:

https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

https://blog.zebpay.com/how-zebpay-reduced-bitcoin-transaction-fees-a9e24c788598

- Jameson

On Thu, Dec 21, 2017 at 4:30 PM, Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I asked adam back at hcpp how the block chain would be secured in the long
> term, once the reward goes away.  The base idea has always been that fees
> would replace the block reward.
>
> At that time fees were approximately 10% of the block reward, but have now
> reached 45%, with 50% potentially being crossed soon
>
> https://fork.lol/reward/feepct
>
> While this bodes well for the long term security of the coin, I think
> there is some legitimate concern that the fee per tx is prohibitive for
> some use cases, at this point in the adoption curve.
>
> Observations of segwit adoption show around 10% at this point
>
> http://segwit.party/charts/
>
> Watching the mempool shows that the congestion is at a peak, though it's
> quite possible this will come down over the long weekend.  I wonder if this
> is of concern to some.
>
> https://dedi.jochen-hoenicke.de/queue/more/#24h
>
> I thought these data points may be of interest and are mainly FYI.  Though
> if further discussion is deemed appropriate, it would be interesting to
> hear thoughts.
>
> ___
> 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] UTXO growth scaling solution proposal

[Jameson Lopp via bitcoin-dev]

Sounds like demurrage to me, which has been implemented in other
cryptocurrencies such as Freicoin - http://freico.in/

While it's an interesting to apply this line of thinking from a scaling
perspective, I suspect most would find it untenable from a monetary policy
perspective.

You have touched on a scaling issue, the cost of node operation, that I
think is really the root cause of a lot of the debate. Thus even if your
proposal was implemented, we'd still have to solve the problem of finding a
consensus for CONOP.

I think you may have misapplied your logic to the total size of the
blockchain, however. Are you suggesting that pruning of the old UTXOs would
also enable pruning of old blocks from all nodes? Those things aren't
really related, plus someone would still have to keep old blocks around in
order to facilitate new nodes syncing from genesis.

- Jameson

On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I have a scaling solution idea that I would be interested in getting some
> feedback on. I’m new to the mailing list and have not been in the Bitcoin
> space as long as some have been, so I don’t know if anyone has thought of
> this idea.
>
> Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO
> growth. Current scaling solutions like Segregated Witness, Lighting
> Network, and larger blocks does not address this issue. As more and more
> blocks are added to the block chain the size of the UTXO set that miners
> have to maintain continues to grow. This is the case even if the block size
> were to remain at 1 megabyte. There is no way out of solving this
> fundamental scaling problem other then to limit the maximum size of the
> UTXO set.
>
> The following soft fork solution is proposed. Any UTXO that is not spent
> within a set number of blocks is considered invalid. What this means for
> miners and nodes in the Bitcoin network is that they only have to ever
> store that set number of blocks. In others words the block chain will never
> be larger then the set number of blocks and the size of the block chain is
> capped.
>
> But what this means for users is that bitcoins that have not been spent
> for a long time are “lost” forever. This proposed solution is likely a
> difficult thing for Bitcoin users to accept. What Bitcoin users will
> experience is that all of a sudden their bitcoins are spendable one moment
> and the next moment they are not. The experience that they get is that all
> of a sudden their old bitcoins are gone forever.
>
> The solution can be improved by adding this new mechanism to Bitcoin, that
> I will call luster. UTXO’s that are less then X blocks old has not lost any
> luster and have a luster value of 1. As UTXO’s get older, the luster value
> will continuously decrease until the UTXO’s become Z blocks old (where Z >
> X), and has lost all it’s luster and have a luster value of 0. UTXO’s that
> are in between X and Z blocks old have a luster value between 0 and 1. The
> luster value is then used to compute the amount of bitcoins that must be
> burned in order for a transaction with that UTXO to be included in a block.
> So for example, a UTXO with a luster value of 0.5 must burn at least 50
> percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn
> at least 75 percent of its bitcoin value, and a UTXO with a luster value of
> 0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that
> have a luster value of 0 means it has no monetary value, and it would be
> safe for bitcoins nodes to drop those UTXOs from the set they maintain.
>
> The idea is that coins that are continuously being used in Bitcoin economy
> will never lose it’s luster. But coins that are old and not circulating
> will start to lose its luster up until all luster is lost and they become
> valueless. Or they reenter the economy and regains all its luster.
>
> But at what point should coins start losing their luster? A goal would be
> that we want to minimize the scenarios of when coins start losing their
> luster. One reasonable answer is that coins should only starting losing its
> luster after the lifespan of the average human. The idea being that a
> person will eventually have to spend all his coins before he dies,
> otherwise it will get lost anyways (assuming that only the dying person has
> the ability to spend those coins). Otherwise there are few cases where a
> person would never spend their bitcoins in there human life time. One
> example is in the case of inheritance where a dying person does not want to
> spend his remaining coins and have another person take them over. But with
> this propose scaling solution, coins can be stilled inherited, but it would
> have to be an on-chain inheritance. The longest lifespan of a human
> currently is about 120 years old. So a blockchain that stores the last 150
> years of history seems like one reasonable option.
>
> Then the ques

Re: [bitcoin-dev] how to disable segwit in my build?

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> >> I believe that a good reason not to wish your node to be segwit
> > compliant is to avoid having to deal with the extra bandwidth that
> > segwit could require.   Running a 0.14.2 node means being ok with >1MB
> > blocks, in case segwit is activated and widely used. Users not
> > interested in segwit transactions may prefer to keep the cost of their
> > node lower.
> >
> > If the majority of the network decides to deploy SegWit, it would be in
> > your best interest to validate the SegWit transactions, because you
> > might will be downgraded to near-SPV node validation.
> > It would be okay to still run a "non-SegWit" node if there's no SegWit
> > transactions in the chain of transactions for your bitcoins, otherwise
> > you cannot fully verify the the ownership of your bitcoins.
> > I'm not sure the practicality of this in the long run, but it makes a
> > case for having an up-to-date non-SegWit node, although I think it's a
> > bit of a stretch.
>
> Right.  Well, if I never upgrade to segwit, then there seems little
> (zero?) risk of having any segwit tx in my tx chain.
>
>
If you mean you wish to avoid receiving UTXOs that have value that was at
one point previously encumbered by a SegWit output then no, you can't avoid
that. No more than you can currently avoid receiving BTC that were at one
point in time encumbered by a P2SH output.


> Thus this would be a way I could continue with a lower bandwidth cap and
> also keep my coins "untainted", so to speak.
>
> I'm not sure about it for the long run either.  more just something of
> an experiment.
> ___
> 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] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Jameson Lopp via bitcoin-dev]

On Wed, Jun 14, 2017 at 12:04 PM, Zheming Lin  wrote:

> Hi Jameson:
>
> 在 2017年6月15日，02:55，Jameson Lopp  写道：
>
>
>
> On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin  wrote:
>
>> Hi Jameson:
>>
>> 在 2017年6月15日，01:20，Jameson Lopp  写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>>
>>>
>>> > 在 2017年6月14日，02:11，Gregory Maxwell  写道：
>>> >
>>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>>> >  wrote:
>>>
>>> > The enforcement of the system's rules by users broadly, and not just
>>> > miners, is specifically described in the white paper (section 8,
>>> > paragraph 2, it especially clear in the last sentence).  This is
>>> > critical for the security of Bitcoin especially with the current
>>> > degree of centralization in pools.  Without it, Bitcoin's security
>>> > would look a lot more like the Ripple system.
>>> >
>>>
>>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知
>>> 道必须做出一个选择。（而不是被动的跟随默认的策略）
>>> Yes, users always have choice that they can abandon the nodes. This BIP
>>> does’t go against them. I mean only the one(especially wallets) that’s
>>> passive, they need to know there’s a choice and pick one.
>>>
>>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>>> This BIP can be applied to almost any upgrade, including Segwit,
>>> Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>>
>>> 到底我们的用户是否真的拥有选择？
>>> Did the users have any real choice?
>>>
>>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>>> I don’t see the reason they trust the majority miners(as they do today)
>>> but refuse the vote for upcoming protocol upgrade.
>>>
>>
>> To be clear, Bitcoin is not a democracy - if you find yourself using the
>> term "voting" then you may be misunderstanding how consensus forms. Once a
>> feature has been vetted and the code is deployed, miners may signal that
>> they are ready to enforce new rules. If for some reason miners are too
>> "passive or lazy" or wish to "veto" the activation of the new rules, users
>> may choose to circumvent said veto by refusing to accept blocks that do not
>> show readiness for enforcing the new rules.
>>
>>
>> How does the users show their opinion? They can fork away and leave. But
>> what remains will be united. Are you afraid of the united users or the fork?
>>
>> I agree with you that the “vote” is not accurate. Could you kindly
>> suggest an other word for that?
>>
>> I think users should have choice to follow the miners or not. Do you
>> agree with this or not?
>>
>> Regarding consensus changes, users can voice their opinion on any number
> of communication platforms. Though if you're looking for a way for users to
> signal their intentions at the protocol level, every proposal for doing
> that to date has been arguably flawed. Measuring meatspace consensus is
> pretty tricky if not completely impossible, especially given the fact that
> the vast majority of Bitcoin users do not voice any opinions on the matter
> of consensus rules.
>
>
> “Sybil attack”. The genuine node will leave the chain if it doesn’t like
> the change. That’s what restrain the majority miners acting foolishly.
>
> If the users like the idea, they follow. If they don’t the fork away(and
> not afraid of replay attack). I think it’s a way to move forward together.
>
> Would you support the idea that we put the choice to the users to decide?
>
> The concept of "sybil attacks" doesn't really apply to enforcing
network-wide consensus changes. Even if someone spooled up 100 times more
nodes than currently exist and they all "signal" for some consensus rule
change, that doesn't compel the rest of the "genuine" nodes to change the
rules they enforce.

The users always have a choice with regard to what consensus rules to
enforce and what software to run. Everyone is welcome to propose changes
and write software that they make available to users.

> Most attempts at measuring user consensus would probably be best described
> as signaling rather than voting given that the act of doing so has no
> actual power to affect consensus. Every user who runs a fully validating
> node is free to enforce the rules with which the agree regardless of what
> rules other entities are enforcing.
>
>>
>>
>>>
>>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>>> This choice for wallet users right now, is wether to follow the 51%
>>> majority miners. If they don’t, they can have their fork that get rid of
>>> miners.
>>>
>>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>>> If they do trust the majority miners, they stay and follow the vote for
>>> upcoming protocol upgrade.
>>>
>>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>>> So the questions is: Do the bitcoin developers, users, holders, service
>>> provides, even miners, (still) have faith in the majority of miners as
>>> designed in the white paper?
>>>
>>>
>> There is a fundamental misconception regarding this point - the white
>> paper ref

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Jameson Lopp via bitcoin-dev]

On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin  wrote:

> Hi Jameson:
>
> 在 2017年6月15日，01:20，Jameson Lopp  写道：
>
>
>
> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev  lists.linuxfoundation.org> wrote:
>
>>
>>
>> > 在 2017年6月14日，02:11，Gregory Maxwell  写道：
>> >
>> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
>> >  wrote:
>>
>> > The enforcement of the system's rules by users broadly, and not just
>> > miners, is specifically described in the white paper (section 8,
>> > paragraph 2, it especially clear in the last sentence).  This is
>> > critical for the security of Bitcoin especially with the current
>> > degree of centralization in pools.  Without it, Bitcoin's security
>> > would look a lot more like the Ripple system.
>> >
>>
>> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，他们需要知
>> 道必须做出一个选择。（而不是被动的跟随默认的策略）
>> Yes, users always have choice that they can abandon the nodes. This BIP
>> does’t go against them. I mean only the one(especially wallets) that’s
>> passive, they need to know there’s a choice and pick one.
>>
>> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
>> This BIP can be applied to almost any upgrade, including Segwit,
>> Segwit2x, 2m, ec, 8m… but the upgrade is not the key point.
>>
>> 到底我们的用户是否真的拥有选择？
>> Did the users have any real choice?
>>
>> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
>> I don’t see the reason they trust the majority miners(as they do today)
>> but refuse the vote for upcoming protocol upgrade.
>>
>
> To be clear, Bitcoin is not a democracy - if you find yourself using the
> term "voting" then you may be misunderstanding how consensus forms. Once a
> feature has been vetted and the code is deployed, miners may signal that
> they are ready to enforce new rules. If for some reason miners are too
> "passive or lazy" or wish to "veto" the activation of the new rules, users
> may choose to circumvent said veto by refusing to accept blocks that do not
> show readiness for enforcing the new rules.
>
>
> How does the users show their opinion? They can fork away and leave. But
> what remains will be united. Are you afraid of the united users or the fork?
>
> I agree with you that the “vote” is not accurate. Could you kindly suggest
> an other word for that?
>
> I think users should have choice to follow the miners or not. Do you agree
> with this or not?
>
> Regarding consensus changes, users can voice their opinion on any number
of communication platforms. Though if you're looking for a way for users to
signal their intentions at the protocol level, every proposal for doing
that to date has been arguably flawed. Measuring meatspace consensus is
pretty tricky if not completely impossible, especially given the fact that
the vast majority of Bitcoin users do not voice any opinions on the matter
of consensus rules.

Most attempts at measuring user consensus would probably be best described
as signaling rather than voting given that the act of doing so has no
actual power to affect consensus. Every user who runs a fully validating
node is free to enforce the rules with which the agree regardless of what
rules other entities are enforcing.

>
>
>>
>> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
>> This choice for wallet users right now, is wether to follow the 51%
>> majority miners. If they don’t, they can have their fork that get rid of
>> miners.
>>
>> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
>> If they do trust the majority miners, they stay and follow the vote for
>> upcoming protocol upgrade.
>>
>> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
>> So the questions is: Do the bitcoin developers, users, holders, service
>> provides, even miners, (still) have faith in the majority of miners as
>> designed in the white paper?
>>
>>
> There is a fundamental misconception regarding this point - the white
> paper refers to majority hashpower needing to be honest with regard to
> determining the correct chain within the context of many possible /valid/
> chain forks. It is not referring to using hashpower to determine the
> correct chain amongst an infinitely variable number of currently invalid
> chain forks. Bitcoin ecosystem participants should not have faith in miners
> (or any other entity) when it comes to choosing the consensus rules they
> wish to enforce.
>
>
> Arrrgh. I think in the BIP, the miners just invalids tx version 1
> temporarily. That’s a “soft fork” right? If they dislike the idea, they can
> leave as always.
>
> From my understanding, if the only change miners make is to stop
confirming transactions that have a version less than X then it should be a
soft fork, yes.

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

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[Jameson Lopp via bitcoin-dev]

On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell  写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> >  wrote:
> >> The BIP is described using Chinese and English. If any part is missing
> or need more specific, please reply. Forgive for my poor English.
> >
> > Your English is much better than my Chinese.  Thank you for taking the
> > time to write this.
> >
> > I am still reading and trying to completely understand your proposal
> > but I wanted to make one observation:
> >
> >> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。
> >> In view of the fact that the original Bitcoin consensus did not
> consider the non-mining wallet nodes(as mentioned above), the result is
> that upgrading the consensus of these wallet nodes is passive and lazy.
> >
> > This is not true. Non-mining wallet nodes were considered, and their
> > upgrade practices are not usually slower than miners.
> >
>
> 我针对的是懒惰和被动的节点，而非活跃做出选择的节点。用户愿意的话总是可以做出自己的选择。并没有办法来强迫并不认同的人形成共识。
> I mean lazy and passive ones I addressed. Not the one actively chose
> whichever solution they like. Users always have their solution. There’s no
> way to force a union if they are not together.
>
> > Even in the very first version of the software it did not mine unless
> > the user went into the settings and explicitly turned it on or used a
> > command-line option.  By default, every installation of Bitcoin was a
> > non-mining wallet node.
> >
>
> 在中本聪白皮书中第五章的定义下，每个节点都需要挖矿。如果咱俩对此存在分歧，我并无法说服你。
> From the definition of Satishi Nakamoto, Section 5, each node mines. If
> that’s the disagreement between us, there’s no more I can convince you.
>
> > The enforcement of the system's rules by users broadly, and not just
> > miners, is specifically described in the white paper (section 8,
> > paragraph 2, it especially clear in the last sentence).  This is
> > critical for the security of Bitcoin especially with the current
> > degree of centralization in pools.  Without it, Bitcoin's security
> > would look a lot more like the Ripple system.
> >
>
> 是的，用户永远都有选择，并可以抛弃那些节点。这个 BIP 并没有反对这些用户这么做。只有那些被动的钱包用户，
> 他们需要知道必须做出一个选择。（而不是被动的跟随默认的策略）
> Yes, users always have choice that they can abandon the nodes. This BIP
> does’t go against them. I mean only the one(especially wallets) that’s
> passive, they need to know there’s a choice and pick one.
>
> 这个 BIP 可以被应用于几乎任何的升级上，包括隔离见证，两兆的隔离见证，两兆扩容，涌现共识，八兆扩容等。但这些升级并不是重点。
> This BIP can be applied to almost any upgrade, including Segwit, Segwit2x,
> 2m, ec, 8m… but the upgrade is not the key point.
>
> 到底我们的用户是否真的拥有选择？
> Did the users have any real choice?
>
> 我并不能理解他们相信大部分矿工（就像当前一样），但拒绝这些多数矿工对协议改变的投票结果。
> I don’t see the reason they trust the majority miners(as they do today)
> but refuse the vote for upcoming protocol upgrade.
>

To be clear, Bitcoin is not a democracy - if you find yourself using the
term "voting" then you may be misunderstanding how consensus forms. Once a
feature has been vetted and the code is deployed, miners may signal that
they are ready to enforce new rules. If for some reason miners are too
"passive or lazy" or wish to "veto" the activation of the new rules, users
may choose to circumvent said veto by refusing to accept blocks that do not
show readiness for enforcing the new rules.


>
> 对钱包用户的选择，是他们是否相信多数矿工。如果他们不相信，可以通过分叉来消除掉矿工。
> This choice for wallet users right now, is wether to follow the 51%
> majority miners. If they don’t, they can have their fork that get rid of
> miners.
>
> 如果他们仍旧相信矿工，那么可以留下来并跟随矿工将来的协议改变。
> If they do trust the majority miners, they stay and follow the vote for
> upcoming protocol upgrade.
>
> 所以问题在于：比特币的开发者、用户、拥有者、服务提供者、甚至矿工，是否（仍然）如白皮书中描述的对大多数矿工拥有信任。
> So the questions is: Do the bitcoin developers, users, holders, service
> provides, even miners, (still) have faith in the majority of miners as
> designed in the white paper?
>
>
There is a fundamental misconception regarding this point - the white paper
refers to majority hashpower needing to be honest with regard to
determining the correct chain within the context of many possible /valid/
chain forks. It is not referring to using hashpower to determine the
correct chain amongst an infinitely variable number of currently invalid
chain forks. Bitcoin ecosystem participants should not have faith in miners
(or any other entity) when it comes to choosing the consensus rules they
wish to enforce.


> > Frequently it is the miners that are "passive and lazy" in upgrading.
> > In some cases when new versions have had major improvements specific
> > to mining (such as for 0.8) miners upgraded much faster than other
> > nodes. But often, it is the other way around and miners adopt new
> > versions much slower than other nodes. If you look at block
> > construction today you will see that many miners are running highly
> > outdated node

Re: [bitcoin-dev] Encouraging good miners

[Jameson Lopp via bitcoin-dev]

Bitcoin chooses the "best chain" based upon the one that has the most
cumulative proof of work behind it. Are you proposing that the cumulative
proof of work be ignored if two blocks are within a certain threshold of
each others' work and if so, the number of transactions in the block / the
size of the block should be used as a "tie breaker?"

I think this idea needs more fleshing out of exactly how it would work,
with careful consideration that adding complexity to the best chain logic
could introduce exploitable flaws.

On Mon, Mar 27, 2017 at 12:12 PM, Btc Ideas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The first
> good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
>
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.
>
> I read some miners could attack a chain by mining small or empty blocks.
> This makes that a little more difficult, but they can still attack the
> chain many ways.
>
>
> Sent with ProtonMail  Secure Email.
>
>
> ___
> 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] Moving towards user activated soft fork activation

[Jameson Lopp via bitcoin-dev]

You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair point
about signaling not being reliable, though it seems more vague in terms of
safety given that you can't actually know what percentage of hashrate that
is /not/ signaling for the soft fork has taken the necessary precautions to
avoid mining an invalid block and potentially causing a hard fork. It's
probably safe to say that if a flag-day soft fork is activated, there will
be at least a few parties who will attempt to trigger a chain fork by
crafting transactions that are valid via non-fork rules but invalid via the
soft fork rules.

2) If the flag day soft fork is activated with only a minority of hashrate
support + safely opted-out hashrate, isn't it possible for the rest of
miners to coordinate orphaning any soft fork compatible blocks to kill the
soft fork chain? This would be a major difference from a miner-activated
soft fork, correct? Unless perhaps many miners colluded to signal soft fork
support while not actually supporting it...

3) In terms of complexity for mining pool operators, how well does this
model scale if there are N soft forks and the pool doesn't want to opt-in
to any of them? Couldn't this result in those pool operators having to run
not just one border node, but a multitude of "chained" border nodes if the
soft forks are spread across different software implementations?

It seems to me that this type of user-driven approach would preferably be
coupled with assurances from major Bitcoin wallets / exchanges / payment
processors that they will not honor coins from a chain fork that results
from invalid spends of outputs encumbered by soft fork rules. Though on the
other hand, I don't see such an assurance being possible given that
exchanges have an incentive to take the first mover advantage in listing a
new coin.

- Jameson

On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some thoughts about the activation mechanism for soft forks. In the past
> we used IsSuperMajority and currently use BIP9 as soft fork activation
> methods, where a supermajority of hashrate triggers nodes to begin
> enforcing new rules. Hashrate based activation is convenient because it is
> the simplest and most straightforward process. While convenient there are a
> number limitations with this method.
>
> Firstly, it requires trusting the hash power will validate after
> activation. The BIP66 soft fork was a case where 95% of the hashrate was
> signaling readiness but in reality about half was not actually validating
> the upgraded rules and mined upon an invalid block by mistake[1].
>
> Secondly, miner signalling has a natural veto which allows a small
> percentage of hashrate to veto node activation of the upgrade for everyone.
> To date, soft forks have taken advantage of the relatively centralised
> mining landscape where there are relatively few mining pools building valid
> blocks; as we move towards more hashrate decentralization, it's likely that
> we will suffer more and more from "upgrade inertia" which will veto most
> upgrades.
>
> Upgrade inertia in inevitable for widely deployed software and can be seen
> for example, with Microsoft Windows. At the time of writing 5.72% of all
> Microsoft Windows installations are still running Windows XP, despite
> mainstream support ending in 2009 and being superseded by 4 software
> generations, Vista, 7, 8 and 10.
>
> Thirdly, the signaling methodology is widely misinterpreted to mean the
> hash power is voting on a proposal and it seems difficult to correct this
> misunderstanding in the wider community. The hash powers' role is to select
> valid transactions, and to extend the blockchain with valid blocks. Fully
> validating economic nodes ensure that blocks are valid. Nodes therefore
> define validity according to the software they run, but miners decide what
> already valid transactions gets included in the block chain.
>
> As such, soft forks rules are actually always enforced by the nodes, not
> the miners. Miners of course can opt-out by simply not including
> transactions that use the new soft fork feature, but they cannot produce
> blocks that are invalid to the soft fork. The P2SH soft fork is a good
> example of this, where non-upgraded miners would see P2SH as spendable
> without a signature and consider them valid. If such an transaction were to
> be included in a block, the block would be invalid and the miner would lose
> the block reward and fees.
>
> So-called "censorship" soft forks do not require nodes to opt in, because
> >51% of the hash power already have the ability to orphan blocks that
> contain transactions they have blacklisted. Since this is not a change in
> validity, nodes will accept the censored block chain automatically.
>
> The fourth problem with supermajority hash power signaling is it draws
> unnecessary attention to min

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

[Jameson Lopp via bitcoin-dev]

Since "buried deployments" are specifically in reference to historical
consensus changes, I think the question is more one of human consensus than
machine consensus. Is there any disagreement amongst Bitcoin users that
BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66
activated at block 363725? Somehow I doubt it.

It seems to me that this change is merely cementing into place a few
attributes of the blockchain's history that are not in dispute.

- Jameson

On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Actually this does nothing to provide justification for this consensus
> rule change. It is just an attempt to deflect criticism from the fact that
> it is such a change.
>
> e
>
> > On Nov 15, 2016, at 9:45 AM, Btc Drak  wrote:
> >
> > I think this is already covered in the BIP text:-
> >
> > "As of November 2016, the most recent of these changes (BIP 65,
> > enforced since December 2015) has nearly 50,000 blocks built on top of
> > it. The occurrence of such a reorg that would cause the activating
> > block to be disconnected would raise fundamental concerns about the
> > security assumptions of Bitcoin, a far bigger issue than any
> > non-backwards compatible change.
> >
> > So while this proposal could theoretically result in a consensus
> > split, it is extremely unlikely, and in particular any such
> > circumstances would be sufficiently damaging to the Bitcoin network to
> > dwarf any concerns about the effects of this proposed change."
> >
> >
> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
> >  wrote:
> >> NACK
> >>
> >> Horrible precedent (hardcoding rule changes based on the assumption that
> >> large forks indicate a catastrophic failure), extremely poor process
> >> (already shipped, now the discussion), and not even a material
> performance
> >> optimization (the checks are avoidable once activated until a
> sufficiently
> >> deep reorg deactivates them).
> >>
> >> e
> >>
> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
> >>  wrote:
> >>
> >> Hi,
> >>
> >> Recently Bitcoin Core merged a simplification to the consensus rules
> >> surrounding deployment of BIPs 34, 66, and 65
> >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change
> is a
> >> minor one, I thought it was worth documenting the rationale in a BIP for
> >> posterity.
> >>
> >> Here's the abstract:
> >>
> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> >> signaling in block version numbers. Now that the chain has long since
> passed
> >> the blocks at which those consensus rules have triggered, we can (as a
> >> simplification and optimization) replace the trigger mechanism by
> caching
> >> the block heights at which those consensus rules became enforced.
> >>
> >> The full draft can be found here:
> >>
> >> https://github.com/sdaftuar/bips/blob/buried-deployments/
> bip-buried-deployments.mediawiki
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

[Jameson Lopp via bitcoin-dev]

Great post, Peter.

4) By fixing the problem (or possibly just "fixing" the problem) are
we encouraging/legitimising blockchain use-cases other than BTC value
transfer? Should we?

I don't think it would encourage non-value-transfer usage more
because, as you noted, many such use cases are valuable enough that
people are willing to pay much higher transaction fees in order to
have their data timestamped. I think it's more an issue of the block
space / transaction fee market since the cost of making a transaction
is directly borne by users, as opposed to the cost of the UTXO set
which may not be borne by them if they don't run a full node.

I'm of the opinion that if the world decides that Bitcoin is more
valuable as a trustworthy generalized timestamping mechanism than as a
value transfer system, protocol developers shouldn't try to steer the
ship against the wind. As more people and use cases enter the
ecosystem, the most valuable ones ought to survive - I hope that this
market will be fostered by the developers.

- Jameson


On Tue, May 17, 2016 at 9:23 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> # Motivation
>
> UTXO growth is a serious concern for Bitcoin's long-term decentralization.
> To
> run a competitive mining operation potentially the entire UTXO set must be
> in
> RAM to achieve competitive latency; your larger, more centralized,
> competitors
> will have the UTXO set in RAM. Mining is a zero-sum game, so the extra
> latency
> of not doing so if they do directly impacts your profit margin. Secondly,
> having possession of the UTXO set is one of the minimum requirements to
> run a
> full node; the larger the set the harder it is to run a full node.
>
> Currently the maximum size of the UTXO set is unbounded as there is no
> consensus rule that limits growth, other than the block-size limit itself;
> as
> of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,
> which expands to significantly more in memory. UTXO growth is driven by a
> number of factors, including the fact that there is little incentive to
> merge
> inputs, lost coins, dust outputs that can't be economically spent, and
> non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles
> and
> timestamping.
>
> We don't have good tools to combat UTXO growth. Segregated Witness
> proposes to
> give witness space a 75% discount, in part of make reducing the UTXO set
> size
> by spending txouts cheaper. While this may change wallets to more often
> spend
> dust, it's hard to imagine an incentive sufficiently strong to discourage
> most,
> let alone all, UTXO growing behavior.
>
> For example, timestamping applications often create unspendable outputs
> due to
> ease of implementation, and because doing so is an easy way to make sure
> that
> the data required to reconstruct the timestamp proof won't get lost - all
> Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
> use-cases like using the UTXO set for key rotation piggyback on the
> uniquely
> strong security and decentralization guarantee that Bitcoin provides; it's
> very
> difficult - perhaps impossible - to provide these applications with
> alternatives that are equally secure. These non-btc-value-transfer
> use-cases
> can often afford to pay far higher fees per UTXO created than competing
> btc-value-transfer use-cases; many users could afford to spend $50 to
> register
> a new PGP key, yet would rather not spend $50 in fees to create a standard
> two
> output transaction. Effective techniques to resist miner censorship exist,
> so
> without resorting to whitelists blocking non-btc-value-transfer use-cases
> as
> "spam" is not a long-term, incentive compatible, solution.
>
> A hard upper limit on UTXO set size could create a more level playing
> field in
> the form of fixed minimum requirements to run a performant Bitcoin node,
> and
> make the issue of UTXO "spam" less important. However, making any coins
> unspendable, regardless of age or value, is a politically untenable
> economic
> change.
>
>
> # TXO Commitments
>
> A merkle tree committing to the state of all transaction outputs, both
> spent
> and unspent, we can provide a method of compactly proving the current
> state of
> an output. This lets us "archive" less frequently accessed parts of the
> UTXO
> set, allowing full nodes to discard the associated data, still providing a
> mechanism to spend those archived outputs by proving to those nodes that
> the
> outputs are in fact unspent.
>
> Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
> type of deterministic, indexable, insertion ordered merkle tree, which
> allows
> new items to be cheaply appended to the tree with minimal storage
> requirements,
> just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
> never removed; if an output is spent its status is updated in place. Both
> the
> state of a specific item in the MMR, as well

[bitcoin-dev] BIP44 & BIP32 chain address look-ahead limits

[Jameson Lopp via bitcoin-dev]

I recently ran into an issue while importing a Mycelium HD wallet where it
was not finding all of my funds - upon further investigation with Mycelium
devs we realized that the wallet was following the BIP44 spec correctly,
but BIP44 may have a flaw.

The problem was a result of my creating 16 transactions in Mycelium in a
fairly short timeframe, but the first 15 transactions ended up never
confirming while the 16th was confirmed. As a result, when I later
reimported the account from the master seed, the chain derivation stopped
upon hitting this large gap of unused addresses on the internal / change
chain.

BIP44 recommends that there need not be a lookahead on internal chains
"because internal chains receive only coins that come from the associated
external chains."
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit

BIP32 also notes that "the look-ahead for internal chains can be very
small, as no gaps are to be expected here."
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Full_wallet_sharing_m

It seems to me that there /is/ an edge case that can result in significant
gaps in internal chain address usage and as such, the recommendation should
be to look ahead on both external and internal chains when performing
account discovery. On a related note, the recommended look-ahead of 20 may
not be safe enough - perhaps it should be raised to 100 if not higher.

In addition to recommending a larger look-ahead, it may also be advisable
for BIP44 to recommend that wallets "fill in" gaps of unused chain
addresses by "looking back" from the current tip of the internal chain's
index when the wallet decides to create a new change address. This could
help mitigate the size of gaps caused by failed transactions.

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

Re: [bitcoin-dev] SegWit testnet is live

[Jameson Lopp via bitcoin-dev]

BitGo also intends to support SegWit transactions as soon as possible.

- Jameson

On Thu, Jan 7, 2016 at 9:17 PM, Matthieu Riou via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not strictly speaking a wallet but we (BlockCypher) will also go down the
> segwit path as soon as the BIP and branch are mature enough.  All
> transactions built from our APIs should eventually be segwitted (just made
> up a verb).
>
> Thanks,
> Matthieu
> *CTO and Founder, Blockcypher*
> I have been informed that Breadwallet has also committed to supporting
> segwit.
>
> The list now includes Blocktrail, Breadwallet, GreenAddress, GreenBits,
> mSIGNA, and NBitcoin.
>
> ---
> Eric
>
> On January 7, 2016 5:28:18 AM PST, Eric Lombrozo 
> wrote:
>>
>> I am pleased to report that as of December 31, 2015 we have been
>> successfully running a segregated witness testnet, called segnet, and have
>> already implemented rudimentary wallets with support.
>>
>> For source code, please look at sipa's github repo:
>> https://github.com/sipa/bitcoin/tree/segwit
>>
>> And some example signing code at my repo:
>>
>> https://github.com/CodeShark/BitcoinScriptExperiments/blob/master/src/signwitnesstx.cpp
>>
>> Several wallets have already committed to supporting it including mSIGNA,
>> GreenAddress, GreenBits, Blocktrail, and NBitcoin. More wallets are
>> expected to be added to this list soon. If you're a wallet dev and are
>> interested in developing and testing on segnet please contact me.
>>
>> We're right on schedule and are very excited about the fundamental
>> improvements to bitcoin that segwit will enable.
>>
>> ---
>> Eric
>>
>>
> ___
> 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] Segregated Witness in the context of Scaling Bitcoin

[Jameson Lopp via bitcoin-dev]

On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
>
Over a year seems to be an extraordinarily long time frame is for deploying
a hard fork. It looks like  75%
of reachable nodes have upgraded in the past 6 months while as much as 25%
may not have been upgraded in over a year. However, viewing historical
stats of version upgrades doesn't seem to be an appropriate comparison
because node operators have never been faced with the same incentive to
upgrade. We can point to unintentional forks in the past that have been
resolved fairly quickly by reaching out to miners, but it's also a poor
comparison. Unfortunately, we have no way of knowing what percentage of
nodes are economically important - a great deal of them may be running and
not even be used by the operators.

Perhaps it would be better if we were to formalize the expectations for
full node operators, but it seems to me that node operators have a
responsibility to keep themselves informed and decide when it is
appropriate to update their software. I'm not so sure that it's the rest of
the ecosystem's responsibility to wait around for laggards.

- Jameson

On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> 1. Summary
>>
>> Segregated Witness (SegWitness, SW) is being presented in the context of
>> Scaling Bitcoin.  It has useful attributes, notably addressing a major
>> malleability vector, but is not a short term scaling solution.
>>
>>
>> 2. Definitions
>>
>> Import Fee Event, ECE, TFM, FFM from previous email.
>>
>> Older clients - Any software not upgraded to SW
>>
>> Newer clients - Upgraded, SW aware software
>>
>>
>> Block size - refers to the core block economic resource limit ed by
>> MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
>> Requires a hard fork to change.
>>
>> Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not
>> changed by SW.
>>
>>
>> Extended transaction - Newer, upgraded version of transaction data format.
>>
>> Extended block - Newer, upgraded version of block data format.
>>
>>
>> EBS - Extended block size.  Block size seen by newer clients.
>>
>>
>> 3. Context of analysis
>>
>> One proposal presents SW *in lieu of* a hard fork block size increase.
>> This email focuses directly on that.
>>
>> Useful features outside block size context, such as anti-malleability or
>> fraud proof features, are not covered in depth.
>>
>>
>> 4.1.  Observations on data structure formats and views
>>
>> SW creates two *views* of each transaction and block.  SW has blocks and
>> extended blocks.  Similarly, there exists transactions and extended
>> transactions.
>>
>> This view is rendered to clients depending on compatibility level.  Newer
>> clients see extended blocks and extended transactions.  Older clients see
>> blocks (limit 1M), and do not see extended blocks.  Older clients see
>> upgraded transactions as unsigned, anyone-can-pay transactions.
>>
>> Each extended transaction exists in two states, one unsigned and one
>> signed, each of which passes validation as a valid bitcoin transaction.
>>
>>
>> 4.2.  Observations on behavior of older transaction creation
>>
>> Transactions created by older clients will not use the extended
>> transaction format.  All data is stored the standard 1M block as today.
>>
>>
>> 4.3.  Observations on new block economic model
>>
>> SW complicates block economics by creating two separate, supply limited
>> resources.
>>
>> The core block economic resource is heavily contended.  Older clients use
>> core blocks exclusively.  Newer clients use core block s more
>> conservatively, storing as much data as possible in

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jameson Lopp via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik  wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1:   Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3:  If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>

Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.

I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.

A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.


> --
> 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] Variable Block Size Proposal

[Jameson Lopp via bitcoin-dev]

I don't think you'll find much support for introducing a mandatory minimum
block size. It's quite wasteful to "pad" blocks with transactions that the
miner is just sending back to themself. If you want to solve the block
propagation issue, I'd recommend instead working on O(1) block propagation.

The Bitcoin Relay Network already allows miners to relay blocks much
faster: http://bitcoinrelaynetwork.org/

The next step would be getting O(1) block propagation into the Bitcoin
protocol. Check out Gavin's proposal:
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2

- Jameson

On Sat, Aug 29, 2015 at 1:41 AM, Justin M. Wray via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hey Bitcoiners!
>
> While I am an avid Bitcoin supporter, long-term user, and have done
> development work on tools and platforms surrounding Bitcoin, I have
> been very busy these past few weeks and haven't had a chance to fully
> (or closely) monitor the Block Size debate.
>
> I'm familiar with the basics, and have read abstracts about the
> front-running proposals (BIP 100, 101, and 102). Though I've honestly
> not read those in depth either. With that said, I was driving
> the other day and thought of a potential idea. I'll be clear, this is
> just an idea, and I haven't fully fleshed it out. But I thought I'd
> throw it out there and see what people thought.
>
> My Goal:
>
> Provide a variable block size that provides for sustainable, long-term
> growth, and balances the block propagation, while also being mindful
> of potential spam attacks.
>
> The Proposal:
>
> Every 2016 blocks (approximately every two weeks, at the same time the
> difficulty is adjusted), the new block size parameters are calculated.
>
> The calculation determines the average (mean) size of the past 2016
> blocks. This "average" size is then doubled (200%) and used as the
> maximum block size for the subsequent 2016 blocks. At any point, if
> the new maximum size is calculated to be below 1MB, 1MB is used
> instead (which prevents regression from our current state).
>
> Introduce a block minimum, the minimum will be 25% of the current
> maximum, calculated at the same time (that is, every 2016 blocks, at
> the same time the maximum is calculated). All blocks must be at least
> this size in order to be valid, for blocks that do not have enough
> transactions to meet the 25%, padding will be used. This devalues the
> incentive to mine empty blocks in either an attempt to deflate the
> block size, or to obtain a propagation advantage. Miners will be
> incentivized to include transactions, as the block must meet the
> minimum. This should ensure that even miners wishing to always mine
> the minimum are still confirming Bitcoin transactions.
>
> At the block in which this is introduced the maximum would stay at 1MB
> for the subsequent 2016 blocks. With the minimum being enforced of 256KB
> .
>
> Example:
>
> * Average Block Size for the last 2016 blocks: 724KB
> * New Maximum: 1448KB
> * New Minimum: 362KB
>
> Example: (Regression Prevention)
>
> * Average Block Size for the last 2016 blocks: 250KB
> * New Maximum: 1MB
> * New Minimum: 256KB
>
> The Future:
>
> I believe that the 1MB regression prevention might need to be changed
> in the future, to prevent a large mining population from continually
> deflating the block size (and keeping us at the 1MB limit).
>
> For this, the hard limit could be changed in the future manually,
> through a process similar to the current one, though hopefully with
> far less urgency and hysteria.
>
> Another option is to add an additional calculation, preventing the new
> maximum from being lower than 75% of the current maximum. This would
> substantially slow down a block-size deflation attack.
>
>  Example of Block-Size Deflation Attack Prevention:
>
>  * Average Block Size for the last 2016 blocks:  4MB
>  * New Maximum:  8MB
>  * New Minimum:  2MB
>
>  * Average Block Size for the last 2016 blocks:  2MB
>  * New Maximum:  6MB  (2 * 200% = 4, 4< 75% of 8, So use 8 * .75 = 6)
>  * New Minimum:  1.5MB
>
> This would provide a maximum growth of 200% per recalculation, but a
> maximum shrinkage of 75%.
>
> Request For Comments:
>
> I'd love to hear your thoughts. Why wouldn't this work? What portion
> is flawed? Will the miners support such a proposal? Would this even
> solve the block size issue?
>
> I will note that I don't find the 100% and 25% to be hard and fast in
> my idea. Those we're just the values that initially jumped out at me.
> I could easily see the minimum being anything below 50% (above 50% and
> the network can never adjust to smaller block sizes). I could also see
> the maximum being anything over 100%.  Lastly, if a inflation attack
> is a valid concern, a hard upper limit could be set (or the historical
> 32MB limit could remain).
>
> I think the great part about this variable approach is that the
> network can ad

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu  wrote:

> On 19 August 2015 at 13:08, Jameson Lopp  wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I understand it. My proposal requires nodes to
> validate transactions that are unconfirmed, and to commit to the
> validation by doing a POW on it.
>
> It's possible to check that a transaction is cryptographically valid
without having any blockchain data available; are you referring to a
different type of validation?

If you're running an SPV node that is listening to full nodes on the
network, you can request an unconfirmed transaction from connected peers
after receiving the inventory message they send - that's how unconfirmed
transactions propagate through the node network. This is not 100% proof
that the transaction is valid for inclusion in the blockchain, but it's a
very good indicator.

- Jameson


> > On an unrelated note, it sounds like your proposal will significantly
> > increase the data size of every transaction, which will create even more
> > contention for block space.
>
> If we stipulate that the coinbase fields only hold space for a single
> pubkey, then the entire block header including the two coinbases
> should only take an extra 100 bytes or so. Transactions are already
> routinely 250 bytes+. So an increase of roughly 33%.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

If operating as an SPV node then it can check the transactions by querying
other nodes.

On an unrelated note, it sounds like your proposal will significantly
increase the data size of every transaction, which will create even more
contention for block space.

- Jameson

On Wed, Aug 19, 2015 at 7:48 AM, Hector Chu  wrote:

> On 19 August 2015 at 12:42, Jameson Lopp  wrote:
> > If you can actually come up with a technical solution that allows for a
> node
> > operator to prove to the rest of the network that they are running an
> honest
> > full node that hosts the entire blockchain, then you can move forward
> with a
> > direct monetary incentivization proposal. To my knowledge no one has been
> > successful in that endeavor. To be more clear, your proposal would need
> to
> > be able to differentiate between a full node and a pseudonode.
> > https://github.com/basil00/PseudoNode
>
> The proof is in the validation of transactions. How can a node
> reliably validate transactions unless it has the past history of
> transactions? Entire blockchain not required or necessary, but that's
> a plus.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin is imploding due to a failure of consensus. There has been a
> failure of consensus on how to fix the design flaw evinced by the block
> size fiasco.
>
> I disagree, but this isn't a technical claim so let's move on.

> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
> If you can actually come up with a technical solution that allows for a
node operator to prove to the rest of the network that they are running an
honest full node that hosts the entire blockchain, then you can move
forward with a direct monetary incentivization proposal. To my knowledge no
one has been successful in that endeavor. To be more clear, your proposal
would need to be able to differentiate between a full node and a
pseudonode. https://github.com/basil00/PseudoNode

The incentives for running a node may not be obvious to the average user,
but they are there. Rather than direct monetary incentives, they are
indirect. For one, it allows you to have a local copy of the blockchain
that you validated yourself - trustlessness is the entire point of this
system. Having local self-validated blockchain data is also essential for
any enterprise that needs to quickly access large volumes of it. The other
incentive is it supports the network. Users may feel that this is necessary
out of altruism or they may feel incentivized to protect their investments
in Bitcoin.

- Jameson



> This is the root cause of the disagreement. Not on what value the block
> size should be set to, a symptom and red herring. The whole argument
> against a block size increase is the further reduction in the node count.
>
> Therefore it makes sense to focus all energies on solving the root cause
> if we are to save Bitcoin in the short and long run. It is tempting to toy
> with the idea that a superior cryptocurrency which fixes the flaws can
> supplant Bitcoin while it dies, but there is significant merit in the
> suspicion that if Bitcoin fails the whole idea of cryptocurrencies will die
> with it for another generation.
>
> Below I will outline my thoughts on how Bitcoin can be improved so that
> more people will be incentivised to run nodes.
>
> 1. The current incentive is run like a lottery.
>
> Mining becomes more and more of a lottery the more value that Bitcoin
> acquires. Prudent and rational people don't partake in lotteries as the
> expected payoff is negative. Due to rewards at the block level, this leads
> to a winner-takes-all situation, which leads to centralisation.
>
> 2. Decentralised proof-of-work is equivalent to value.
>
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Nearly everyone has to agree on a change, and they have to do it without
> being forced or pressured into it.
>
> Proof-of-work is the basis of Bitcoin's security, which contributes to
> Bitcoin's value. Further, the more decentralised that proof-of-work is, the
> greater the value proposition of Bitcoin as a currency resistant to change
> by coercion.
>
> 3. Importance of a public technical forum.
>
> In order for there to be consensus, there must be a triumph of ideas over
> people. Ideas are immortal, people are not. Also, pragmatism over idealism.
> There must be no rank within the community, and no censorship or ignorance
> of others no matter their past contributions. However, it stands to reason
> that those who are more educated and experienced should be taken more
> seriously than those who are not.
>
> 4. Stronger ties between transaction validation and proof-of-work.
>
> As pointed out, mining in the pooled sense can be done without doing any
> validation whatsoever. By tying mining with transaction validation, the two
> must become inseparable.
>
> The logical conclusion of this is that instead of mining blocks per se,
> transactions must be mined individually.
>
> 5. Fees to be paid to nodes.
>
> The incentive to run nodes shall be made monetary. All the reward is
> currently going to those who do not really support the network.
>
> 50% of a transaction's fee should go to the node that mined the
> transaction.
>
> 6. The timechain.
>
> Currently it is difficult to envisage anything other than grouping
> transactions into blocks and timestamping them. The POW timestamping
> service must have sufficient time gap between blocks.
>
> Therefore as transactions are mined each one will have the possibility to
> become a block in the timechain. The POW difficulty for a block will
> obviously be much greater than the POW required to mine a single
> transaction.
>
> This also requires every mined transaction to contain a block header, in
> case it becomes a new block in the block chain. It will contain a prev
> block hash, a mer

Re: [bitcoin-dev] Fwd: Block size following technological growth

[Jameson Lopp via bitcoin-dev]

Anecdotally I've seen two primary reasons posed for not running a node:

1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
configuration option in bitcoind and a slider / selector in the QT client
to throttle the total bandwidth usage. This issue has been open for years:
https://github.com/bitcoin/bitcoin/issues/273 - if you want to make it
easier for enthusiasts to run nodes, I'd start there.

2) For businesses, it's not so much an issue with the resources of
installing / running / maintaining a node, it's an issue with the lack of
indexing options offered by bitcoind. Thus the business will also need to
run their own indexing solution - an out-of-the-box solution such as
Insight or Toshi might work, but for more custom indexing you have to roll
your own software - this is where it actually becomes expensive.

Depending upon the query volume / latency needs of the business, it may not
make sense to bother administering bitcoind instances, the indexing
software, and its databases - using a third party API will probably be more
efficient.

- Jameson

On Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If the incentives for running a node don't weight up against the
>> cost/difficulty using a full node yourself for a majority of people in the
>> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
>> improvement over other systems is the lack of need for trust, I believe
>> that with increased adoption should also come an increased (in absolute
>> terms) incentive for people to use a full node. I'm seeing the opposite
>> trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
> to trust nothing but the genesis block hash (decide to run a full node)
> there is a problem?
>
> If so, then we do have a fundamental difference of opinion, but I've
> misunderstood how you think about trust/centralization/convenience
> tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeoffs,
> and I believe that is OK-- people should be free to make those tradeoffs.
>
> And given that the majority of people in the ecosystem were deciding that
> using a centralized service or an SPV-level-security wallet was better even
> two or three years ago when blocks were tiny (I'd have to go back and dig
> up number-of-full-nodes and number-of-active-wallets at the big web-wallet
> providers, but I bet there were an order of magnitude more people using
> centralized services than running full nodes even back then), I firmly
> believe that block size has very little to do with the decision to run a
> full node or not.
>
>
> --
> --
> Gavin Andresen
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size following technological growth

[Jameson Lopp via bitcoin-dev]

I fully expect that new layers will someday allow us to facilitate higher
transaction volumes, though I'm concerned about the current state of the
network and the fact that there are no concrete timelines for the rollout
of aforementioned high volume networks.

As for reasoning behind why users will still need to settle on-chain even
with the existence of high volume networks, see these posts:

http://sourceforge.net/p/bitcoin/mailman/message/34119233/

http://sourceforge.net/p/bitcoin/mailman/message/34113067/

Point being, the scalability proposals that are currently being developed
are not magic bullets and still require the occasional on-chain settlement.
Larger blocks will be necessary with or without the actual scalability
enhancements.

- Jameson

On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop  wrote:

> On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Stated differently, if the cost or contention of using the network rises
>> to the point of excluding the average user from making transactions, then
>> they probably aren't going to care that they can run a node at trivial cost.
>
>
> That's an interesting claim; so suppose you're living in a future where
> transactions are summarizing millions or billions of other daily
> transactions, possibly with merkle hashes. You think that because a user
> can't individually broadcast his own personal transaction, that the user
> would not be interested in verifying the presence of a summarizing
> transaction in the blockchain? I'm just curious if you could elaborate on
> this effect. Why would I need to see my individual transactions on the
> network, but not see aggregate transactions that include my own?
>
> - 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] Block size following technological growth

[Jameson Lopp via bitcoin-dev]

I find it to be an admirable goal to try to keep node operation costs low
and accessible to the average user. On the other hand, if we are able to
keep the resource requirements of nodes at the level of, say, whatever the
latest Raspberry Pi model on a residential Internet connection can handle,
I'm not sure how helpful it will be if the demand for inclusion in blocks
results in transaction fees prices out more users. Stated differently, if
the cost or contention of using the network rises to the point of excluding
the average user from making transactions, then they probably aren't going
to care that they can run a node at trivial cost.

If we're approaching the block size from a resource usage standpoint, it
seems to me that someone is going to be excluded one way or another. Not
raising the block size will exclude some users from sending transactions
while raising the block size will exclude some users from running nodes.
The latter seems preferable to me because more users will grow the
ecosystem, which should increase the value of the ecosystem, which should
increase the cost that entities are willing to pay to run nodes.

I see two primary points of view / objectives clashing in this debate:

1) Decentralization and stability even if it retards growth of the ecosystem
2) Push the system's load as far as we are comfortable in order to
accommodate the growth it is experiencing

It's clear to me that Core developers have a responsibility to maintain a
stable platform for the ecosystem. I think it's less clear that they have a
responsibility to grow it or ask node operators to expend more resources in
order to support more users. As an operator of several nodes, I can
anecdotally state that I find their resource usage to be trivial and I
welcome more load.

- Jameson

On Thu, Jul 30, 2015 at 11:12 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1) Unlike previous blocksize hardfork proposals, this uses median time
> instead of block.nTime for activation. I like that more but my
> preference is still using height for everything. But that discussion
> is not specific to this proposal, so it's better if we discuss that
> for all of them here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
> 2) I think uncontroversial hardforks should also take miner
> confirmation into account, just like uncontroversial softforks do. We
> cannot make sure other users have upgraded before activating the
> chain, but we can know whether miners have upgraded or not. Having
> that tool available, why not use it. Of course other hardforks may not
> care about miners' upgrade state. For example "anti-miner hardforks,
> see
> https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork
> But again, this is common to all uncontroversial hardforks, so it
> would probably better to discussed it in
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
> (gmaxwell assigned to bip99 to my bip draft).
>
> 3) As commented to you privately, I don't like to make any assumptions
> about technological advancements (much less on economical growth). I
> don't expect many people to agree with me here (I guess I've seen too
> many "peak oil" [or more generally, peak energy production] plus I've
> read Nietzsche's "On the utility and liability of history for life"
> [1]; so considering morals, technology or economics as "monotonic
> functions" in history is simply a ridiculous notion to me), but it's
> undeniable that internet connections have improved overall around the
> world in the last 6 years. I think we should wait for the
> technological improvements to happen and then adapt the blocksize
> accordingly. I know, that's not a "definitive solution", we will need
> to change it from time to time and this is somewhat ugly.
> But even if I'm the only one that considers a "technological
> de-growth" possible, I don't think is wise to rely on pseudo-laws like
> Moore's or Nielsen’s so-called "laws".
> Stealing a quote from another thread:
>
> "Prediction is difficult, especially about the future." - Niels Bohr
>
> So I would prefer a more limited solution like bip102 (even though I
> would prefer to have some simulations leading to  a concrete value
> (even if it's bigger) rather than using 2MB's arbitrary number.
>
> Those are my 3 cents.
>
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf
>
> On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
>  wrote:
> > Hello all,
> >
> > here is a proposal for long-term scalability I've been working on:
> > https://gist.github.com/sipa/c65665fc360ca7a176a6
> >
> > Some things are not included yet, such as a testnet whose size runs
> ahead of
> > the main chain, and the inclusion of Gavin's more accurate sigop checking
> > after the hard fork.
> >
> > Comments?
> >
> > --
> > Pieter
> >
> >
> > ___
> > bitcoin-dev mailing li

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

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo  wrote:

>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp  wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>

Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run their own node (as opposed to
Satoshi's vision of beefy servers in data centers.) My impression is that
even most of these advocates agree that it will be acceptable to eventually
increase block sizes as resources become faster and cheaper because it
won't be 'pricing out' the average user from running their own node. If
this is the case, it seems to me that we have a problem given that there is
no established baseline for the acceptable performance / hardware cost
requirements to run a node. I'd really like to see further clarification
from these advocates around the acceptable cost of running a node and how
we can measure the global reduction in hardware and bandwidth costs in
order to establish a baseline that we can use to justify additional
resource usage by nodes.

- Jameson

>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
>
> Let’s be absolutely clear about one thing - block size increases are *not*
> about scaling the network. Can we please stop promoting this falsehood? It
> doesn’t matter by what number we multiply the block size…we can NEVER
> satisfy the full demand if we insist on every single transaction from every
> single person everywhere in the world being on the blockchain…it’s just
> absurd.
>
>
Increasing block size only temporarily addresses one significant issue -
> how to postpone having to deal with transaction fees, which by design, are
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we’ve all known about from the beginning…so
> please stop claiming otherwise.
>
>
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear. On the flip side, the scalability
proposals will still require larger blocks if we are ever to support
anything close to resembling "mainstream" usage. This is not an either/or
proposition - we clearly need both.

- Jameson

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There’s been tremendous progress here in addressing scalability,
> yet I don’t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you’re saying, Jorge…but It’s even worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people to
> rely on others to validate for them…and increasing block size only makes
> the problem worse.
>
> - Eric Lombrozo
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Node Speed Test

[Jameson Lopp via bitcoin-dev]

Are you willing to share the code that you used to run the test?

- Jameson

On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On this day, the Bitcoin network was crawled and reachable nodes surveyed
> to find their maximum throughput in order to determine if it can safely
> support a faster block rate. Specifically this is an attempt to prove or
> disprove the common statement that 1MB blocks were only suitable slower
> internet connections in 2009 when Bitcoin launched, and that connection
> speeds have improved to the point of obviously supporting larger blocks.
>
>
> The testing methodology is as follows:
>
>  * Nodes were randomly selected from a peers.dat, 5% of the reachable
> nodes in the network were contacted.
>
>  * A random selection of blocks was downloaded from each peer.
>
>  * There is some bias towards higher connection speeds, very slow
> connections (<30KB/s) timed out in order to run the test at a reasonable
> rate.
>
>  * The connecting node was in Amsterdam with a 1GB NIC.
>
>
> Results:
>
>  * 37% of connected nodes failed to upload blocks faster than 1MB/s.
>
>  * 16% of connected nodes uploaded blocks faster than 10MB/s.
>
>  * Raw data, one line per connected node, kilobytes per second
> http://pastebin.com/raw.php?i=6b4NuiVQ
>
>
> This does not support the theory that the network has the available
> bandwidth for increased block sizes, as in its current state 37% of nodes
> would fail to upload a 20MB block to a single peer in under 20 seconds
> (referencing a number quoted by Gavin). If the bar for suitability is
> placed at taking only 1% of the block time (6 seconds) to upload one block
> to one peer, then 69% of the network fails for 20MB blocks. For comparison,
> only 10% fail this metric for 1MB blocks.
> ___
> 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