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 <brianlockh...@gmail.com>
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 

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 

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] 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 

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

[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] 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] 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 

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 hector...@gmail.com wrote:

 On 19 August 2015 at 12:42, Jameson Lopp jameson.l...@gmail.com 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 merkle tree of mined transactions in the mempool, a nonce and
 two separate coinbase 

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 kanz...@gmail.com 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] Bitcoin Core and hard forks

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com wrote:


 On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com 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