Nostr notes by

📅 Original date posted:2017-03-31 📝 Original message:> ...

2023-06-07T17:58:22Z

In reply to nevent1q…n8x0
_________________________

📅 Original date posted:2017-03-31
📝 Original message:> Nodes don't do politics. People do, and politics is a lot larger with a lot more moving parts than just node operation.

Node operation is making a stand on what money you will accept.

Ie Your local store will only accept US Dollars and not Japanese Yen. Without being able to run a node, you have no way to independently determine what you are receiving, you could be paid Zimbawe Dollars and wouldn't know any better.

> Full nodes protect from nothing if the chain they attempt to use is nonfunctional.

This is highly subjective.
Just because it is nonfunctional to you, does not mean it is nonfunctional to existing users.

> This power is far more complicated than just nodes.

I never implied otherwise.

> You're implying that node operation == political participation.

Ofcourse it is. Try paying for my goods using BU/Ehtereum/Dash/etc.. or a Bitcoin forked with inflation, you will not get any goods regardless of how much hashrate those coins have.

> Miners being distributed in enough countries and locations to avoid any single outside attacker group from having enough leverage to prevent transaction inclusion, and miners also having enough incentives(philosophical or economic) to refuse to collude towards transaction exclusion.

It's good that you see the importance of this. You should also take into consideration the number of independent mining entities it takes to achieve 51% hashrate. It will be of little use to have thousands on independent miners/pools if 3 large pools make up 51% of hash rate and collude to attack the network.

> If users refused to get on board, exchanges would follow users. If miners refused to get on board, the attempt would be equally dead in the water. It would require a majority of users, businesses and miners to change the limit;

> Nodes have absolutely no say in the matter if they can't segment the network, and even if they could their impact could be repaired. Users != Nodes.

Nodes define which network they want to follow. Without a Node, you don't even get to decide which segement you are on. Either miners decide( for SPV wallets) or your wallet's server decides(Node). You have no control without a

>> What makes transactions irreversible
>Nodes have absolutely no say in the matter, they always follow the longest chain unless a hardfork was applied.

My bad here, hashpower decides order. This is the sole reason we have mining, to order transactions.

> Mutual destruction comes from the market forces on the exchanges, and they could give a rats ass whether you run a node or not.

Ability to run a node and validate rules => Confidence in currency => Higher demand => Higher exchange rate

I would not be holding any Bitcoins if it was unfeasible for me to run a Node and instead had to trust some 3rd party that the currency was not being inflated/censored. Bitcoin has value because of it's trustless properties. Otherwise, there is no difference between cryptocurrencies and fiat.

> Literally the only reason we have 10s of billions of dollars of value is because speculation, which includes nearly all Bitcoin users/holders and almost all businesses and miners. While Bitcoin borrows useful features from gold, it has more possible uses, including uses that were never possible before Bitcoin existed, and we believe that gives it huge potential.
> The ability of other systems to do transactions, like visa or cash, come with the limitations of those systems. Bitcoin was designed to break those limitations and STILL provide the ability to do transactions. We might all agree Bitcoin isn't going to ever solve the microtransaction problem, at least not on-chain, but saying Bitcoin doesn't need utility is just foolish. Gold doesn't need utility, gold has 4,000 years of history. We don't.
> There's no reason those blocksize increases can't be tied to or related to usage increases

Blocksize has nothing to do with utility, only cost of on-chain transactions.
OTOH increasing the blocksize has alot to do with introducing the very limitations that Visa/Cash have.
Why would you risk destroying Bitcoin's primary proposition (removing limitations of Cash/Visa) for insignificant capacity increase?

> That's like saying it would be better to do nothing so someone else solves our problem for us than it would be for us to do what we can to solve it ourselves. Someone else solving our problem may very well be Ethereum, and "solving it for us" is pulling Bitcoin investments, users and nodes away into Ethereum.

Who says nothing is being done? Segwit, Lightning, pre-loaded wallets like Coinbase are all solutions.

On Thu, Mar 30, 2017 at 12:11 AM, Luv Khemani <luvb at hotmail.com<mailto:luvb at hotmail.com>> wrote:

>> If home users are not running their own full nodes, then home users have to trust and rely on other, more powerful nodes to represent them. Of course, the more powerful nodes, simply by nature of having more power, are going to have different opinions and objectives from the users.

>I think you're conflating mining with node operation here. Node users only power is to block the propagation of certain things. Since miners also have a node endpoint, they can cut the node users out of the equation by linking with eachother directly - something they already do out of practicality for propagation. Node users do not have the power to arbitrate consensus, that is why we have blocks and PoW.

You are only looking at technical aspects and missing the political aspect.

Node users decide what a Bitcoin is. It matters not how much hash power is behind a inflationary supply chain fork, full nodes protect the user from the change of any properties of Bitcoin which they do not agree with. The ability to retain this power for users is of prime importance and is arguably what gives Bitcoin most of it's value. Any increase in the cost to run a full node is an increase in cost to maintain monetary sovereignty. The ability for a user to run a node is what keeps the miners honest and prevents them from rewriting any of Bitcoin's rules.

If it's still difficult to grasp the above paragraph, ask yourself the following questions,
- What makes Bitcoin uncensorable
- What gives confidence that the 21 million limit will be upheld
- What makes transactions irreversible
- If hashpower was king as you make it to be, why havn't miners making up majority hashrate who want bigger blocks been able to change the blocksize?

The market is not storing 10s of billions of dollars in Bitcoin despite all it's risks because it is useful for everyday transactions, that is a solved problem in every part of the world (Cash/Visa/etc..).

Having said that, i fully empathise with your view that increasing transaction fees might allow competitors to gain marketshare for low value use cases. By all means, we should look into ways of solving the problem. But all these debates around blocksize is a total waste of time. Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction capacity will still be too low for global usage in the medium-long term. The additional capacity from blocksize increases are linear improvements with very large systemic costs compared with the userbase and usage which is growing exponentially. Lightning potentially offers a couple or orders of magnitude of scaling and will make blocksize a non-issue for years to come. Even if it fails to live up to the hype, you should not discount the market innovating solutions when there is money to be made.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/04e79a13/attachment-0001.html>;

📅 Original date posted:2017-03-30 📝 Original ...

2023-06-07T17:58:21Z

In reply to nevent1q…2m4t
_________________________

📅 Original date posted:2017-03-30
📝 Original message:>> If home users are not running their own full nodes, then home users have to trust and rely on other, more powerful nodes to represent them. Of course, the more powerful nodes, simply by nature of having more power, are going to have different opinions and objectives from the users.

>I think you're conflating mining with node operation here. Node users only power is to block the propagation of certain things. Since miners also have a node endpoint, they can cut the node users out of the equation by linking with eachother directly - something they already do out of practicality for propagation. Node users do not have the power to arbitrate consensus, that is why we have blocks and PoW.

You are only looking at technical aspects and missing the political aspect.

Node users decide what a Bitcoin is. It matters not how much hash power is behind a inflationary supply chain fork, full nodes protect the user from the change of any properties of Bitcoin which they do not agree with. The ability to retain this power for users is of prime importance and is arguably what gives Bitcoin most of it's value. Any increase in the cost to run a full node is an increase in cost to maintain monetary sovereignty. The ability for a user to run a node is what keeps the miners honest and prevents them from rewriting any of Bitcoin's rules.

If it's still difficult to grasp the above paragraph, ask yourself the following questions,
- What makes Bitcoin uncensorable
- What gives confidence that the 21 million limit will be upheld
- What makes transactions irreversible
- If hashpower was king as you make it to be, why havn't miners making up majority hashrate who want bigger blocks been able to change the blocksize?

The market is not storing 10s of billions of dollars in Bitcoin despite all it's risks because it is useful for everyday transactions, that is a solved problem in every part of the world (Cash/Visa/etc..).

Having said that, i fully empathise with your view that increasing transaction fees might allow competitors to gain marketshare for low value use cases. By all means, we should look into ways of solving the problem. But all these debates around blocksize is a total waste of time. Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction capacity will still be too low for global usage in the medium-long term. The additional capacity from blocksize increases are linear improvements with very large systemic costs compared with the userbase and usage which is growing exponentially. Lightning potentially offers a couple or orders of magnitude of scaling and will make blocksize a non-issue for years to come. Even if it fails to live up to the hype, you should not discount the market innovating solutions when there is money to be made.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/bf2ad53b/attachment-0001.html>;

📅 Original date posted:2017-03-28 📝 Original message:Hi ...

2023-06-07T17:58:09Z

In reply to nevent1q…xf6f
_________________________

📅 Original date posted:2017-03-28
📝 Original message:Hi Juan

> I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s Law all has been verified for many years and support that 32 MB in 2020 are possible and equals or less than 1 MB in 2010.

Protocol development, especially one in control of people's money cannot be based on beliefs. Do you have actual data to show significant increases in desktop CPU, memory and bandwidth?

All empirical evidence points to the opposite.

Intel has been struggling to eek out 5-10% gains for each generation of its CPUs. The growth of the total blockchain size at 1MB alone is much faster than this.

CPU Core counts have also been stagnant for a decade.

Disk Space growth has also been slowing and with the trend towards SSDs, available disk space in a typical PC has turned negative sharply.

Regards

Luv

________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Juan Garavaglia via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Wednesday, March 29, 2017 6:36 AM
To: Alphonse Pace; Wang Chun
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Alphonse,

Even when several of the experts involved in the document you refer has my respect and admiration, I do not agree with some of their conclusions some of their estimations are not accurate other changed like Bootstrap Time, Cost per Confirmed Transaction they consider a network of 450,000,00 GH and today is 3.594.236.966 GH, the energy consumption per GH is old, the cost of electricity is wrong even when the document was made and is hard to find any parameter used that is valid for an analysis today.

Again with all respect to the experts involved in that analysis is not valid today.

I tend to believe more in Moore’s law, Butters' Law of Photonics and Kryder’s Law all has been verified for many years and support that 32 MB in 2020 are possible and equals or less than 1 MB in 2010.

Again may be is not possible Johnson Lau and LukeJr invested a significant amount of time investigating ways to do a safe HF, and may be not possible to do a safe HF today but from processing power, bandwidth and storage is totally valid and Wang Chung proposal has solid grounds.

Regards

Juan

From: Alphonse Pace [mailto:alp.bitcoin at gmail.com]
Sent: Tuesday, March 28, 2017 2:53 PM
To: Juan Garavaglia <jg at 112bit.com>; Wang Chun <1240902 at gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Juan,

I suggest you take a look at this paper: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf It may help you form opinions based in science rather than what appears to be nothing more than a hunch. It shows that even 4MB is unsafe. SegWit provides up to this limit.

On Scaling Decentralized Blockchains<http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf>;
fc16.ifca.ai
On Scaling Decentralized Blockchains (A Position Paper) Kyle Croman 0 ;1, Christian Decker 4, Ittay Eyal , Adem Efe Gencer , Ari Juels 0 ;2, Ahmed Kosba 0 ;3, Andrew ...

8MB is most definitely not safe today.

Whether it is unsafe or impossible is the topic, since Wang Chun proposed making the block size limit 32MiB.

Wang Chun,

Can you specify what meeting you are talking about? You seem to have not replied on that point. Who were the participants and what was the purpose of this meeting?

-Alphonse

On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com<mailto:jg at 112bit.com>> wrote:

Alphonse,

In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and 32MB limit valid in next halving, from network, storage and CPU perspective or 1MB was too high in 2010 what is possible or 1MB is to low today.

If is unsafe or impossible to raise the blocksize is a different topic.

Regards

Juan

From: bitcoin-dev-bounces at lists.linuxfoundation.org<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>] On Behalf Of Alphonse Pace via bitcoin-dev
Sent: Tuesday, March 28, 2017 2:24 PM
To: Wang Chun <1240902 at gmail.com<mailto:1240902 at gmail.com>>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting

What meeting are you referring to? Who were the participants?

Removing the limit but relying on the p2p protocol is not really a true 32MiB limit, but a limit of whatever transport methods provide. This can lead to differing consensus if alternative layers for relaying are used. What you seem to be asking for is an unbound block size (or at least determined by whatever miners produce). This has the possibility (and even likelihood) of removing many participants from the network, including many small miners.

32MB in less than 3 years also appears to be far beyond limits of safety which are known to exist far sooner, and we cannot expect hardware and networking layers to improve by those amounts in that time.

It also seems like it would be much better to wait until SegWit activates in order to truly measure the effects on the network from this increased capacity before committing to any additional increases.

-Alphonse

On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:

I've proposed this hard fork approach last year in Hong Kong Consensus
but immediately rejected by coredevs at that meeting, after more than
one year it seems that lots of people haven't heard of it. So I would
post this here again for comment.

The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.

Despite spam tx on the network, the block capacity is approaching its
limit, and we must think ahead. Shall we code a patch right now, to
remove the block size limit of 1MB, but not activate it until far in
the future. I would propose to remove the 1MB limit at the next block
halving in spring 2020, only limit the block size to 32MiB which is
the maximum size the current p2p protocol allows. This patch must be
in the immediate next release of Bitcoin Core.

With this patch in core's next release, Bitcoin works just as before,
no fork will ever occur, until spring 2020. But everyone knows there
will be a fork scheduled. Third party services, libraries, wallets and
exchanges will have enough time to prepare for it over the next three
years.

We don't yet have an agreement on how to increase the block size
limit. There have been many proposals over the past years, like
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
on. These hard fork proposals, with this patch already in Core's
release, they all become soft fork. We'll have enough time to discuss
all these proposals and decide which one to go. Take an example, if we
choose to fork to only 2MB, since 32MiB already scheduled, reduce it
from 32MiB to 2MB will be a soft fork.

Anyway, we must code something right now, before it becomes too late.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/e38abd87/attachment-0001.html>;