<unnamed>

Public Key

npub170s9de2ganthnna75443h70tnsn2lvmcq5365r0juk8nfa93lthqwjr45x

Profile Code

nprofile1qqs08czku4ywe4mee7l226cml84ecf40kduq2ga2phewtre57jcl4mspzpmhxue69uhkummnw3ezuamfdejs9ey22k

Publishing to

nostr.wine

Last Notes

2023-06-07 17:35:44 UTC

- reply

📅 Original date posted:2015-08-17
📝 Original message:On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
Is he talking about "full nodes" i.e. validating-only, or nodes in the
sense of the original whitepaper (i.e. miners)? Because there is already
plenty of incentive for running a node (i.e. the coinbase).
The issue is that the reward is more or less like a decentralised lottery
with high entry cost. If the income could be smoothed like in a mining
pool, without actually being a mining pool, then perhaps more people would
pay to enter the mining game. A bit like making P2Pool the one and only
pool allowed on the network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/4c6230a0/attachment.html>

2023-06-07 17:33:39 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:You people are the most selfish kind of people in the world. Blackmail
developers with overload of the system, to try to force them to urgently
come up with solutions to the problem. The solution is always going to
be... wait for it... "increase the block size". There is not enough time or
manpower to do anything else. We are witnessing a tragedy of the commons
before our very eyes.
On 9 August 2015 at 00:05, Alex Morcos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I agree
> There are a lot of difficult technical problems introduced by insufficient
> block space that are best addressed now. As well as problems that scale
> will exacerbate like bootstrapping that we should develop solutions for
> first.
>
>
> Sent from my iPad
>
> On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I see value in lowering the block size or leaving it where it is. We
> expect to run out of space, and I think it's a good idea to prepare for
> that, rather than avoid it. When we run out of space and the block size is
> low, we will see problems. If we raise the block size, we will NOT see
> these problems until bitcoin is bigger and more important and the pressure
> is higher.
>
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem. I don't think it is. It is a problem for those who
> don't wait for even one confirmation, but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain. I am comfortable leaving those zero-conf people in a little bit
> of trouble. Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space. Yes, $5 transactions suck, but $0.15 is not so bad and about
> twice the average right now.
>
> Meanwhile, the higher fees everyone starts feeling like paying, along with
> the visibility of the problems caused by full-blocks, will provide
> excellent justification and motivation for increasing the limit. My
> favorite thing to do is to have a solution ready for a problem I expect to
> see, see the problem (so I can measure things about it) and then implement
> the solution.
>
> In my experience, the single biggest reason not to run a full node has to
> do with starting from scratch: "I used to run a full node, but last time I
> had to download the full blockchain, it took ___ days, so I just use (some
> wallet) now." I think that has been improved with headers-first, but many
> people don't know it.
>
> I have some ideas how a "full node" could postpone being "full" but still
> be nearly completely operational so that the delay between startup and
> having a full blockchain is nearly painless. It involves bonded
> representation of important not-so-large pieces of data (blocks that have
> my transactions, the complete UTXO as of some height, etc.). If I know
> that I have some btc, I could offer it (say, 100 or 1000 transaction fees'
> worth) to anyone who will guarantee good data to me, and then when I have
> the whole blockchain, I will know if they were honest. If done right, the
> whole network could know whether or not they were honest and enforce the
> bond if they weren't. Credit the Lightening paper for parts of this idea.
>
> Dave
>
> On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Please try to focus on constructive technical comments.
>>
>> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > What will the backlash be when people here that are pushing for
>> "off-chain-
>> > transactions" fail to produce a properly working alternative, which
>> > essentially means we have to say NO to more users.
>>
>> But > 99% of Bitcoin transactions are already off-chain. There are
>> multiple competing companies offering consumer & retail service with
>> off-chain settlement.
>>
>> I wasnt clear but it seemed in your previous mail that you seemed to
>> say you dont mind trusting other people with your money, and so
>> presumably you are OK using these services, and so have no problem?
>>
>> > At this time and this size of bitcoin community, my personal experience
>> (and
>> > I've been part of many communities) saying NO to new customers
>>
>> Who said no to anything? The systems of off-chain transfer already
>> exist and are by comparison to Bitcoins protocol simple and rapid to
>> adapt and scale.
>>
>> Indications are that we can even do off-chain at scale with Bitcoin
>> similar trust-minimisation with lightning, and duplex payment
>> channels; and people are working on that right now.
>>
>> I think it would be interesting and useful for someone, with an
>> interest in low trust, high scale transactions, to work on and propose
>> an interoperability standard and API for such off-chain services to be
>> accessed by wallets, and perhaps periodic on-chain inter-service
>> netting.
>>
>> Adam
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/e8166ff2/attachment.html>

2023-06-07 17:33:06 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:Ok good. We have established it to be a non-trivial cost.
Now, what is the growth complexity of the total cost of the network in
terms of number of connections each hub has to other hubs? And then,
consider a payment channel with many hops in it. The end-to-end users would
have to swallow all the costs of the hubs in the channel.
On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The costs of operating a hub are as follows:
>
> Time value of the funds the Hub has locked up in payment channels.
> Enhanced risk of loss of control of private keys (the keys necessarily
> need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>
> Tom, my understanding is that the money that is debited from a payment hub
> is simultaneously credited from either another payment hub or the person
> making the payment, so that the net funds flow at a payment hub always sums
> to zero. So no, there is no credit advanced by the payment hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for the
> Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
> part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a payment
> hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
> transactions would be passed on as a cost to the clients of the payment
> hub. Also there is a cost to locking up funds in a payment channel (time
> value of money). The lost interest or opportunity cost on those funds would
> need to be paid for by its clients as well. And don't forget normal running
> costs such as networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/ab206edd/attachment.html>

2023-06-07 17:33:05 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:Tom, my understanding is that the money that is debited from a payment hub
is simultaneously credited from either another payment hub or the person
making the payment, so that the net funds flow at a payment hub always sums
to zero. So no, there is no credit advanced by the payment hub to anyone.
Given Mark's previous answer of using CPFP and other tricks to pay for the
Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
part in the payment channel balances.
So, the interesting question is what are the costs of running a payment
hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
transactions would be passed on as a cost to the clients of the payment
hub. Also there is a cost to locking up funds in a payment channel (time
value of money). The lost interest or opportunity cost on those funds would
need to be paid for by its clients as well. And don't forget normal running
costs such as networking and electricity.
On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/da65aa23/attachment-0001.html>

2023-06-07 17:33:02 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:In the Lightning network it is assumed that the balances can always be
settled on the blockchain if any of the parties along the channel has a
problem. What if the fee on the settlement transactions is not high enough
to enter the blockchain? You can't do replace-by-fee after the fact. Do the
fees always have to assume worst case scenarios on the Bitcoin fee market?
On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Tom, you appear to be misunderstanding how lightning network and
> micropayment hub-and-spoke models in general work.
>
> > But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies). Nothing requires the
> payment hub to do this.
>
> On the contrary the funds were advanced by the hub on the creation of the
> channel. There is no credit involved. if the funds aren't already available
> for Bob to immediately claim his balance, the payment doesn't go through in
> the first place.
>
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>
>> > Don't turn Bitcoin into something uninteresting, please.
>>
>> Consider how Bob will receive money using the Lightning Network.
>>
>> Bob receives a payment by applying a contract to his local payment
>> channel, increasing the amount payable to him when the channel is closed.
>>
>> There are two possible sources of funding for Bob's increased claim.
>> They can appear alone, or in combination:
>>
>>
>> Funding Source (1)
>> A deposit from Bob's payment hub
>>
>> Bob can receive funds, if his payment hub has made a deposit to the
>> channel. Another name for this is "credit".
>>
>> This credit has no default risk: Bob cannot just take payment hub's
>> deposit. But neither can Bob receive money, unless payment hub has
>> advanced it to the channel (or (2) below applies). Nothing requires the
>> payment hub to do this.
>>
>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>> It will come with a fee and, in an important way, it is worse than the
>> current banking system. If a bank will not even open an account for Bob
>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>> paid through a Poon-Dryja channel?
>>
>>
>> Funding Source (2)
>> Bob's previous spends
>>
>> If Bob has previously spent from the channel, decreasing his claim on
>> its funds (which he could have deposited himself), that claim can be
>> re-increased.
>>
>> To avoid needing credit (1), Bob has an incentive to consolidate
>> spending and income in the same payment channel, just as with today's
>> banks. This is at odds with the idea that Bob will have accounts with
>> many payment hubs. It is an incentive for centralization.
>>
>>
>> With Lightning Network, Bob will need a powerful middleman to send and
>> receive money effectively. *That* is uninteresting to me.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/749c2207/attachment.html>

2023-06-07 17:32:29 UTC

- reply

📅 Original date posted:2015-08-04
📝 Original message:On 4 August 2015 at 12:59, Jorge Timón <jtimon at jtimon.cc> wrote:
> That is not my position. Again, I don't know what the right blocksize
> for the short term is (I don't think anybody does).
>
You have no position (i.e. neutral). In other words, keeping the existing
limit.
> Therefore how the change can affect mining centralization must be the
> main concern, instead of (also artificial) projections about usage
> growth (no matter how organic their curves look).
>
The degree of mining decentralization is only one of many concerns. Users'
main concern is timely confirmation of low-fee transactions. Miners'
concern is the amount of profit they make.
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.
>
The limit won't even get to be hit, because all the users that get thrown
out of Bitcoin will have moved over to a system supporting a larger block
size.
I don't know where you get your "majority" from or what it even means
> (majority of users, majority of the coins, of miners?)
>
The majority which the miners are beholden to is the economic majority.
https://en.bitcoin.it/wiki/Economic_majority
> But there's something I'm missing something there...why my position
> doesn't matter if it's not a majority?
>
Your position is only one of many and it does not carry excess weight to
the others. Individually it won't matter, because you can't control the
implementation that other people run.
> How is what the the majority has been told it's best an objective argument?
>
Don't fight the market. The way the system is designed, the miners will
follow along with what the economic majority have decided.
So if you say 8, I must ask, why not 9?
> Why 9 MB is not safe for mining centralization but 8 MB is?
>
8MB has simply been the focal point for this debate. 9MB is also safe if
8MB is, but I suppose the opponents will be even less happy with 9 than
with 8, and we don't want to unnecessarily increase the conflict.
It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
>
A one-time increase to 8MB is safer than a dynamically growing limit over
time for exactly this reason. Admittedly whenever the next debate to
increase the block size over 8MB happens it will be even more painful and
non-obvious, but that is the safety check to prevent unbounded block size
increase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/b832895e/attachment.html>

2023-06-07 17:32:26 UTC

- reply

📅 Original date posted:2015-08-04
📝 Original message:On 4 August 2015 at 14:13, Jorge Timón <jtimon at jtimon.cc> wrote:
> 2) It doesn't matter who is to blame about the current centralization:
> the fact remains that the blocksize maximum is the only** consensus
> rule to limit mining centralization.
>
Repeating a claim ad-nauseum doesn't make it necessarily true. A block size
limit won't prevent miners in the future from buying each other out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/6368b601/attachment.html>

2023-06-07 17:32:24 UTC

- reply

📅 Original date posted:2015-08-04
📝 Original message:Things apparently aren't bad enough to prevent the majority from clamoring
for larger blocks.
If the majority agreed that things had got worse till this point, and that
this was to be blamed on the block size, they would be campaigning for the
other direction. Even yourselves aren't asking for a reduction in the block
size, as you know full well that you would be laughed out.
On 4 August 2015 at 12:27, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> I would say that things already demonstrately got terrible. The mining
> landscape is very centralized, with apparently a majority depending on
> agreements to trust each other's announced blocks without validation. Full
> node count is at its historically lowest value in years, and outsourcing of
> full validation keeps growing.
>
> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
> --
> Pieter
> On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Mike's position is that he wants the block size limit
>> to eventually be removed. That is of course an extreme view. Meanwhile,
>> your view that the block size should be artificially constrained below the
>> organic growth curve (in a way that will penalize a majority of existing
>> and future users) lies at the other extreme. The majority position lies
>> somewhere in between (i.e. a one-time increase to 8MB). This is the
>> position that ultimately matters.
>>
>> If the block size is increased to 8MB and things get demonstrably a whole
>> lot worse, then you will have a solid leg to stand on. In that case we can
>> always do another hard fork later to reduce the block size back to
>> something smaller, and henceforth the block size will never be touched
>> again.
>>
>> On 4 August 2015 at 11:35, Jorge Timón <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>>> >> How more users or more nodes can bring more miners, or more
>>> importantly,
>>> >> improve mining decentralization?
>>> >
>>> >
>>> > Because the bigger the ecosystem is the more interest there is in
>>> taking
>>> > part?
>>>
>>> As explained by Venzen, this is a non-sequitur.
>>>
>>> > I mean, I guess I don't know how to answer your question.
>>>
>>> I don't know the answer either, that's fine. It's the opposite
>>> question that I've been insistently repeating and you've been
>>> (consciously or not) consistently evading.
>>> But that's also fine because I believe you finally answer it a few lines
>>> below.
>>>
>>> > When Bitcoin was
>>> > new it had almost no users and almost no miners. Now there are
>>> millions of
>>> > users and factories producing ASICs just for Bitcoin.
>>>
>>> The emergence of a btc price enabled the emergence of professional
>>> miners, which in turn enabled the emergence of sha256d-specialized
>>> hardware production companies.
>>> Nothing surprising there.
>>> By no means it consitutes an example of how a bigger consensus sizes
>>> can cause less mining centralization.
>>>
>>> > Surely the correlation is obvious?
>>>
>>> Correlation does not imply causation. I will better leave it at that...
>>>
>>> >> I'm sorry, but until there's a simulation that I can run with
>>> different
>>> >> sizes' testchains (for example using #6382) to somehow compare them,
>>> I will
>>> >> consider any value arbitrary.
>>> >
>>> >
>>> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
>>> was
>>> > well documented here:
>>> >
>>> >
>>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>>> >
>>> > I chose 20MB as a reasonable block size to target because 170
>>> gigabytes per
>>> > month comfortably fits into the typical 250-300 gigabytes per month
>>> data
>>> > cap– so you can run a full node from home on a “pretty good” broadband
>>> plan.
>>> >
>>> > Did you think 20mb was picked randomly?
>>>
>>> No, I think 20 MB was chosen very optimistically, considering 3rd
>>> party services rates (not the same service as self-hosting) in the
>>> so-called "first world". And then 20 MB goes to 20 GB, again with
>>> optimistic and by no means scientific expectations.
>>>
>>> But where the number comes from it's not really what I'm demaning,
>>> what I want is some criterion that can tell you that a given size
>>> would be "too centralized" but another one isn't.
>>> I haven't read any analysis on why 8GB is a better option than 7GB and
>>> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
>>> or 21 GB).
>>> A simulation test passing 20 GB but not 21 GB would make it far less
>>> arbitrary.
>>>
>>> >> Agreed on the first sentence, I'm just saying that the influence of
>>> >> the blocksize in that function is monotonic: with bigger sizes, equal
>>> >> or worse mining centralization.
>>> >
>>> >
>>> > I have a hard time agreeing with this because I've seen Bitcoin go from
>>> > blocks that were often empty to blocks that are often full, and in
>>> this time
>>> > the number of miners and hash power on the network has gone up a huge
>>> amount
>>> > too.
>>>
>>> I'm of course talking about consensus maximum blocksize, not about
>>> actual blocksize.
>>> Yes, again, when mining becomes profitable, economic actors tend to
>>> appear and get those profits.
>>> But don't confuse total hashrate improvements with an "increase in the
>>> number of miners" or with mining decentralization.
>>>
>>> > You can argue that a miner doesn't count if they pool mine. But if a
>>> miner
>>> > mines on a pool that uses exactly the same software and settings as the
>>> > miner would have done anyway, then it makes no difference. Miners can
>>> switch
>>> > between pools to find one that works the way they like, so whilst less
>>> > pooling or more decentralised pools would be nice (e.g.
>>> getblocktemplate),
>>> > and I've written about how to push it forward before, I still say
>>> there are
>>> > many more miners than in the past.
>>> >
>>> > If I had to pick between two changes to improve mining
>>> decentralisation:
>>> >
>>> > 1) Lower block size
>>>
>>> Finally, I think you finally answered my repetitive question here.
>>> If I say "Mike Hearn understands that the consensus block size maximum
>>> rule is a tool for limitting mining centralization" I'm not putting
>>> words in your mouth, right?
>>> I think many users advocating for an increase in the consensus limit
>>> don't understand this, which is extremely unfortunate for the debate.
>>>
>>> > 2) Finishing, documenting, and making the UX really slick for a
>>> > getblocktemplate based decentralised mining pool
>>> >
>>> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>>>
>>> Great! Maybe after 2 mining centralization improves so much that we're
>>> confortable not only not lowering it but rather increasing it.
>>>
>>> >> you should be consequently advocating for full removal of the limit
>>> rather
>>> >> than changes towards bigger arbitrary values.
>>> >
>>> >
>>> > I did toy with that idea a while ago. Of course there can not really
>>> be no
>>> > limit at all because the code assumes blocks fit into RAM/swap, and
>>> nodes
>>> > would just end up ignoring blocks they couldn't download in time
>>> anyway.
>>> > There is obviously a physical limit somewhere.
>>>
>>> Did the fact that you "understand that the consensus block size
>>> maximum rule is a tool for limitting mining centralization" influenced
>>> your rejection of that idea at all?
>>>
>>> > But it is easier to find common ground with others by compromising. Is
>>> 8mb
>>> > better than no limit? I don't know and I don't care much: I think
>>> Bitcoin
>>> > adoption is a slow, hard process and we'll be lucky to increase average
>>> > usage 8x over the next couple of years. So if 8mb+ is better for
>>> others,
>>> > that's OK by me.
>>>
>>> The only way that "not caring much whther we have a consensus limit or
>>> not" and "understand that the consensus block size maximum rule is a
>>> tool for limitting mining centralization" at the same time is by not
>>> caring about mining centralization at all.
>>> Is that your position?
>>>
>>> If you don't care about having a limit but you don't want to limit
>>> transaction volume, then ++current_size will ALWAYs be your
>>> "compromise position" and no blocksize increase will ever be enough
>>> until the limit is completely removed.
>>> Is that your position?
>>>
>>> > Re: exchange profit. You can pick some other useful service provider
>>> if you
>>> > like. Payment processors or cold storage providers or the TREZOR
>>> > manufacturers or whoever.
>>>
>>> Yes, and I believe the same points stand.
>>>
>>> > My point is you can't have a tiny high-value-transactions only
>>> currency AND
>>> > all the useful infrastructure that the Bitcoin community is making.
>>> It's a
>>> > contradiction. And without the infrastructure bitcoin ceases to be
>>> > interesting even to people who are willing to pay huge sums to use it.
>>>
>>> You keep talking about "high-value-transactions-only" like if
>>> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
>>> automatically result in that "high-value-transactions-only" Bitcoin.
>>> Please, stop talking as if someone was proposing a
>>> "high-value-transactions-only" Bitcoin. That may happen but nobody
>>> really knows. If it happens it may not be bad thing necessarily (ie
>>> bitcoin microtransactions can still happen using trustless payment
>>> channels and x is still cheaper than x% for any transacted value
>>> higher than 100) but that's really not what we're talking about here
>>> so it seems distraction that can only help further polirizing this
>>> discussion.
>>>
>>> What we're talking about here is that hitting the limit would
>>> (hopefully) make miners start caring about fees. Enough that they stop
>>> being irrational about free transactions. If both things happen,
>>> non-urgent transaction fees will likely rise (as said, above zero).
>>>
>>> You think that would be a catastrophe for adoption and I disagree.
>>> But (as Pieter has repeatedly explained) for any size there will be
>>> use cases that will be eventually priced out.
>>> So when rising this consensus limit, not increasing centralization
>>> should be the priority and the potential impact in market fees a much
>>> more secondary concern.
>>> Do you agree with this?
>>>
>>> I'm sure there are many intermediate positions between "caring more
>>> about mining centralization than market fees when deciding about a
>>> consensus rule that limits mining centralization" and "not caring
>>> about mining centralization at all".
>>> I really don't want to put words in your mouth, but I honestly don't
>>> know what your position is.
>>> I don't really know how else can I ask the same question: you don't
>>> care the consensus maximum blocksize rule being here at all or not
>>> (you just said that).
>>> Is it because you don't think it limits mining centralization or
>>> because you don't care about limiting mining centralization with
>>> consensus rules at all?
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> 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/20150804/da27bb34/attachment-0001.html>

2023-06-07 17:32:22 UTC

- reply

📅 Original date posted:2015-08-04
📝 Original message:Mike's position is that he wants the block size limit
to eventually be removed. That is of course an extreme view. Meanwhile,
your view that the block size should be artificially constrained below the
organic growth curve (in a way that will penalize a majority of existing
and future users) lies at the other extreme. The majority position lies
somewhere in between (i.e. a one-time increase to 8MB). This is the
position that ultimately matters.
If the block size is increased to 8MB and things get demonstrably a whole
lot worse, then you will have a solid leg to stand on. In that case we can
always do another hard fork later to reduce the block size back to
something smaller, and henceforth the block size will never be touched
again.
On 4 August 2015 at 11:35, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> >> How more users or more nodes can bring more miners, or more importantly,
> >> improve mining decentralization?
> >
> >
> > Because the bigger the ecosystem is the more interest there is in taking
> > part?
>
> As explained by Venzen, this is a non-sequitur.
>
> > I mean, I guess I don't know how to answer your question.
>
> I don't know the answer either, that's fine. It's the opposite
> question that I've been insistently repeating and you've been
> (consciously or not) consistently evading.
> But that's also fine because I believe you finally answer it a few lines
> below.
>
> > When Bitcoin was
> > new it had almost no users and almost no miners. Now there are millions
> of
> > users and factories producing ASICs just for Bitcoin.
>
> The emergence of a btc price enabled the emergence of professional
> miners, which in turn enabled the emergence of sha256d-specialized
> hardware production companies.
> Nothing surprising there.
> By no means it consitutes an example of how a bigger consensus sizes
> can cause less mining centralization.
>
> > Surely the correlation is obvious?
>
> Correlation does not imply causation. I will better leave it at that...
>
> >> I'm sorry, but until there's a simulation that I can run with different
> >> sizes' testchains (for example using #6382) to somehow compare them, I
> will
> >> consider any value arbitrary.
> >
> >
> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
> was
> > well documented here:
> >
> >
> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
> >
> > I chose 20MB as a reasonable block size to target because 170 gigabytes
> per
> > month comfortably fits into the typical 250-300 gigabytes per month data
> > cap– so you can run a full node from home on a “pretty good” broadband
> plan.
> >
> > Did you think 20mb was picked randomly?
>
> No, I think 20 MB was chosen very optimistically, considering 3rd
> party services rates (not the same service as self-hosting) in the
> so-called "first world". And then 20 MB goes to 20 GB, again with
> optimistic and by no means scientific expectations.
>
> But where the number comes from it's not really what I'm demaning,
> what I want is some criterion that can tell you that a given size
> would be "too centralized" but another one isn't.
> I haven't read any analysis on why 8GB is a better option than 7GB and
> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
> or 21 GB).
> A simulation test passing 20 GB but not 21 GB would make it far less
> arbitrary.
>
> >> Agreed on the first sentence, I'm just saying that the influence of
> >> the blocksize in that function is monotonic: with bigger sizes, equal
> >> or worse mining centralization.
> >
> >
> > I have a hard time agreeing with this because I've seen Bitcoin go from
> > blocks that were often empty to blocks that are often full, and in this
> time
> > the number of miners and hash power on the network has gone up a huge
> amount
> > too.
>
> I'm of course talking about consensus maximum blocksize, not about
> actual blocksize.
> Yes, again, when mining becomes profitable, economic actors tend to
> appear and get those profits.
> But don't confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
>
> > You can argue that a miner doesn't count if they pool mine. But if a
> miner
> > mines on a pool that uses exactly the same software and settings as the
> > miner would have done anyway, then it makes no difference. Miners can
> switch
> > between pools to find one that works the way they like, so whilst less
> > pooling or more decentralised pools would be nice (e.g.
> getblocktemplate),
> > and I've written about how to push it forward before, I still say there
> are
> > many more miners than in the past.
> >
> > If I had to pick between two changes to improve mining decentralisation:
> >
> > 1) Lower block size
>
> Finally, I think you finally answered my repetitive question here.
> If I say "Mike Hearn understands that the consensus block size maximum
> rule is a tool for limitting mining centralization" I'm not putting
> words in your mouth, right?
> I think many users advocating for an increase in the consensus limit
> don't understand this, which is extremely unfortunate for the debate.
>
> > 2) Finishing, documenting, and making the UX really slick for a
> > getblocktemplate based decentralised mining pool
> >
> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>
> Great! Maybe after 2 mining centralization improves so much that we're
> confortable not only not lowering it but rather increasing it.
>
> >> you should be consequently advocating for full removal of the limit
> rather
> >> than changes towards bigger arbitrary values.
> >
> >
> > I did toy with that idea a while ago. Of course there can not really be
> no
> > limit at all because the code assumes blocks fit into RAM/swap, and nodes
> > would just end up ignoring blocks they couldn't download in time anyway.
> > There is obviously a physical limit somewhere.
>
> Did the fact that you "understand that the consensus block size
> maximum rule is a tool for limitting mining centralization" influenced
> your rejection of that idea at all?
>
> > But it is easier to find common ground with others by compromising. Is
> 8mb
> > better than no limit? I don't know and I don't care much: I think
> Bitcoin
> > adoption is a slow, hard process and we'll be lucky to increase average
> > usage 8x over the next couple of years. So if 8mb+ is better for others,
> > that's OK by me.
>
> The only way that "not caring much whther we have a consensus limit or
> not" and "understand that the consensus block size maximum rule is a
> tool for limitting mining centralization" at the same time is by not
> caring about mining centralization at all.
> Is that your position?
>
> If you don't care about having a limit but you don't want to limit
> transaction volume, then ++current_size will ALWAYs be your
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed.
> Is that your position?
>
> > Re: exchange profit. You can pick some other useful service provider if
> you
> > like. Payment processors or cold storage providers or the TREZOR
> > manufacturers or whoever.
>
> Yes, and I believe the same points stand.
>
> > My point is you can't have a tiny high-value-transactions only currency
> AND
> > all the useful infrastructure that the Bitcoin community is making. It's
> a
> > contradiction. And without the infrastructure bitcoin ceases to be
> > interesting even to people who are willing to pay huge sums to use it.
>
> You keep talking about "high-value-transactions-only" like if
> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
> automatically result in that "high-value-transactions-only" Bitcoin.
> Please, stop talking as if someone was proposing a
> "high-value-transactions-only" Bitcoin. That may happen but nobody
> really knows. If it happens it may not be bad thing necessarily (ie
> bitcoin microtransactions can still happen using trustless payment
> channels and x is still cheaper than x% for any transacted value
> higher than 100) but that's really not what we're talking about here
> so it seems distraction that can only help further polirizing this
> discussion.
>
> What we're talking about here is that hitting the limit would
> (hopefully) make miners start caring about fees. Enough that they stop
> being irrational about free transactions. If both things happen,
> non-urgent transaction fees will likely rise (as said, above zero).
>
> You think that would be a catastrophe for adoption and I disagree.
> But (as Pieter has repeatedly explained) for any size there will be
> use cases that will be eventually priced out.
> So when rising this consensus limit, not increasing centralization
> should be the priority and the potential impact in market fees a much
> more secondary concern.
> Do you agree with this?
>
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all".
> I really don't want to put words in your mouth, but I honestly don't
> know what your position is.
> I don't really know how else can I ask the same question: you don't
> care the consensus maximum blocksize rule being here at all or not
> (you just said that).
> Is it because you don't think it limits mining centralization or
> because you don't care about limiting mining centralization with
> consensus rules at all?
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150804/4c51100f/attachment-0001.html>

2023-06-07 17:32:04 UTC

- reply

📅 Original date posted:2015-07-31
📝 Original message:I haven't seen much discussion on this list of what will happen when the
blockchain forks due to larger blocks. I think the debate surrounding this
issue is a storm in a teacup, because transactions on the smaller chain can
and will appear on the bigger chain also. There is nothing tying
transactions to the blocks they appear in.
Miners will migrate to the bigger chain in search of higher profits due to
higher volume of fees. They can also collect the higher fees of the smaller
chain by including into the bigger chain as many as possible of the
transactions from the smaller chain.
To stop this from happening the smaller chain would somehow need to change
the serialized format of their transactions so the signatures would no
longer be valid across chains.
Incidentally I read somewhere that the losing chain would have their coins
sold down. Trying to sell the smaller chain's coins in the short term at
least is not advisable, as those transactions will appear on the bigger
chain too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150801/ada31652/attachment.html>

2023-06-07 15:47:27 UTC

- reply

2023-06-07 15:47:20 UTC

- reply

📅 Original date posted:2015-08-20
📝 Original message:Security is provided via POW. If you want the chains to stop attacking
each other, change the POW algorithms.
Then it wouldn't matter if one chain was longer than another, each
fork would select the best chain according to their valid version of
POW algorithm.
If Bitcoin Core loses miner majority to XT this is probably what it
will have to do to maintain security of its chain.
On 20 August 2015 at 12:32, Milly Bitcoin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The same with -XT, nobody should be able to affect the entire bitcoin
>> ecosystem regardless how many miners or bitcoin companies you can lobby.
>> If this is possible, then Bitcoin is not as secure as we thought.
>
>
> Bitcoin is only as secure as the developers, users, and miners allow it to
> be. If you can get the majority of developers, users, and miners to do
> insecure things then Bitcoin will be insecure.
>
> Russ
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:46:24 UTC

- reply

📅 Original date posted:2015-08-08
📝 Original message:Has there ever been any discussion of locking coins till a certain date for
casting votes on an issue?
Say that the date for counting votes is 3 months from now. Every one who
wants to cast a vote must lock coins until the vote closes (using CLTV). To
increase the weight of your vote, lock more coins. Write your choice in the
scriptPubKey or an OP_RETURN data output.
On the date the vote closes the nodes tally up the coin values for the
various vote options, and the choice with the highest total is the winner.
Not saying this could be used to solve the block size issue necessarily,
but we could have choices like:
1) Keep block size the same
2) Reduce block size by 10%.
3) Increase block size by 10%.
The vote could be a rolling one. When the present vote is decided the vote
for the next 3 months starts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/8ebd677b/attachment-0001.html>

2023-06-07 15:45:46 UTC

- reply

2023-06-07 15:45:22 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:Lightning will never catch on as it basically demands that everyone who
uses it to become a speculator. Payment hubs and merchants will be at the
mercy of the bitcoin price while their funds stay locked up in payment
channels. This idea is a dead-end.
On 10 August 2015 at 22:43, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In terms of usage I think you'd more imagine a wallet that basically
> parks Bitcoins onto channels at all times, so long as they are
> routable there is no loss, and the scalability achieved thereby is
> strongly advantageous, and there is even the potential for users to
> earn fees by having their wallets participate in channel rebalancing
> (where hubs pay users to rebalance channels - end up with the same net
> position but move funds from one user-owned channel to another.)
> Exchange deposit, withdrawal, payments, even in-exchange trades can
> usefully happen in lightning for faster, cheaper more scalable
> transactions.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150811/cb129674/attachment.html>

2023-06-07 15:45:20 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:Sorry about that Patrick. Gmail hides previous messages including sender
names. Regardless, no worries.
On 9 August 2015 at 23:27, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> That was not in reply to you.
>
>
> On 08/09/2015 03:09 PM, Hector Chu wrote:
>
> Right, you've stated a bunch of facts, but how does it answer my concerns
> of the exploding cost of the network the more interconnected it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I suspect there is some amount of confusion here on terms.
>>
>> The hub is essentially swapping funds between payment channels.
>>
>> The hub's entire business is centered around having payment channels open
>> with other hubs/users.
>>
>> If the hub requires user funds to open these channels... then the users
>> have no reason to pay the hub anything in fees.
>>
>> A hub that doesn't use it's own funds to open payment channels to other
>> hubs/merchants is useless.
>>
>>
>> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/55553328/attachment-0001.html>

2023-06-07 15:45:19 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:Right, you've stated a bunch of facts, but how does it answer my concerns
of the exploding cost of the network the more interconnected it it?
On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I suspect there is some amount of confusion here on terms.
>
> The hub is essentially swapping funds between payment channels.
>
> The hub's entire business is centered around having payment channels open
> with other hubs/users.
>
> If the hub requires user funds to open these channels... then the users
> have no reason to pay the hub anything in fees.
>
> A hub that doesn't use it's own funds to open payment channels to other
> hubs/merchants is useless.
>
>
> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150809/ed27b9af/attachment.html>

2023-06-07 15:45:18 UTC

- reply

2023-06-07 15:45:17 UTC

- reply

2023-06-07 15:45:15 UTC

- reply

2023-06-07 15:44:49 UTC

- reply

2023-06-07 15:44:46 UTC

- reply

2023-06-07 15:44:44 UTC

- reply

2023-06-07 15:44:43 UTC

- reply

2023-06-07 15:44:40 UTC

- reply

📅 Original date posted:2015-08-03
📝 Original message:On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo at gmail.com> wrote:
> We already have much more efficient, far more scalable systems that allow
> this kind of cooperation you speak of without the inconveniences of
> blockchains and such.
>
There is a degree of difference between cooperation in day-to-day usage of
the system and cooperation in the rare cases the system has a bug.
These incidents do, fortunately, present some of the better sides of
> humanity…but…the design of the network *broke* - and for reasons that are
> now well understood to be only worsened by larger blocks. These incidents
> are *not supposed to happen* - and if they do, it means we’ve botched
> something up and need to fix it. And by fix it, I mean fix the protocol so
> that given our best understanding of things in the present we can
> significantly reduce the potential for its occurrence in the future.
>
Distribution by consensus is inherently a fragile system. The network will
continue to break again and again as long as programmers are fallible. But
the types of bugs that occur will change over time as we learn the best
practices for maintaining the system.
The correct incentives here were not due to people potentially losing a lot
> of money. The incentives here were well-intentioned altruism. Some miners
> lost money as a result of these actions…and they didn’t put up a fight. if
> you want to design a system around the assumption that this is how all such
> incidents will be resolved, please don’t spoil this for the rest of us.
>
Altruism is a facade that hides other motivations. The party cooperating
with the miners losing money were doing so to maintain good relationships
with those miners and to make sure those miners stay within the system and
not attack it.
>
> - Eric
>
> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu at gmail.com> wrote:
>
> What's wrong with a little cooperation to resolve things now and then? Man
> is not an island unto himself, we compete with each other and we cooperate
> with each other occasionally if it's mutually beneficial.
>
> You said yourself that a lot of money would have been lost if the two hard
> forks cited weren't resolved - that's the correct incentives at work again.
>
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>> There have already been two notable incidents requiring manual
>> intervention and good-faith cooperation between core devs and mining pool
>> operators that would have either never gotten resolved alone or would have
>> ended up costing a lot of people a lot of money had no action been taken
>> (March 2013 and July 2015). They were both caused by consensus disagreement
>> that directly or indirectly were brought about by bigger blocks. There is
>> *strong* evidence…and a great deal of theory explaining it…that links
>> larger blocks with the propensity for consensus forks that require manual
>> intervention.
>>
>> Please, can we stop saying this is merely about decentralization and
>> trustlessness? The very model upon which the security of the system is
>> based *broke*…as in, we were only able to recover because a few individuals
>> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>> we more highly prioritize fixing the issues that can lead to these
>> incidents than trying to increase throughput? Increasing block size cannot
>> possibly make these forking tendencies better…but it very well could make
>> them worse.
>>
>> - Eric
>>
>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org> wrote:
>>
>>> Again this should not be a political or business compromise model - we
>>> must focus on scientific evaluation, technical requirements and
>>> security.
>>>
>>
>> I will assert that the block size is political because it affects nearly
>> all users to some degree and not all those users are technically inclined
>> or care to keep decentralisation in the current configuration as you do.
>> This debate has forgotten the current and future users of Bitcoin. Most of
>> them think the hit to node count in the short term preferable to making it
>> expensive and competitive to transact.
>>
>> We all need a little faith that the system will reorganise and readjust
>> after the move to big blocks in a way that still has a reasonable degree of
>> decentralisation and trustlessness. The incentives of Bitcoin remain, so
>> everyone's decentralised decision throughout the system, from miners,
>> merchants and users, will continue to act according to those incentives.
>> _______________________________________________
>> bitcoin-dev mailing list
>> 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/20150803/6a96c793/attachment.html>

2023-06-07 15:44:39 UTC

- reply

📅 Original date posted:2015-08-03
📝 Original message:On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org> wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>
I will assert that the block size is political because it affects nearly
all users to some degree and not all those users are technically inclined
or care to keep decentralisation in the current configuration as you do.
This debate has forgotten the current and future users of Bitcoin. Most of
them think the hit to node count in the short term preferable to making it
expensive and competitive to transact.
We all need a little faith that the system will reorganise and readjust
after the move to big blocks in a way that still has a reasonable degree of
decentralisation and trustlessness. The incentives of Bitcoin remain, so
everyone's decentralised decision throughout the system, from miners,
merchants and users, will continue to act according to those incentives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/580e9b04/attachment.html>

2023-06-07 15:44:39 UTC

- reply

📅 Original date posted:2015-08-03
📝 Original message:What's wrong with a little cooperation to resolve things now and then? Man
is not an island unto himself, we compete with each other and we cooperate
with each other occasionally if it's mutually beneficial.
You said yourself that a lot of money would have been lost if the two hard
forks cited weren't resolved - that's the correct incentives at work again.
On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo at gmail.com> wrote:
> There have already been two notable incidents requiring manual
> intervention and good-faith cooperation between core devs and mining pool
> operators that would have either never gotten resolved alone or would have
> ended up costing a lot of people a lot of money had no action been taken
> (March 2013 and July 2015). They were both caused by consensus disagreement
> that directly or indirectly were brought about by bigger blocks. There is
> *strong* evidence…and a great deal of theory explaining it…that links
> larger blocks with the propensity for consensus forks that require manual
> intervention.
>
> Please, can we stop saying this is merely about decentralization and
> trustlessness? The very model upon which the security of the system is
> based *broke*…as in, we were only able to recover because a few individuals
> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
> we more highly prioritize fixing the issues that can lead to these
> incidents than trying to increase throughput? Increasing block size cannot
> possibly make these forking tendencies better…but it very well could make
> them worse.
>
> - Eric
>
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 3 August 2015 at 08:53, Adam Back <adam at cypherspace.org> wrote:
>
>> Again this should not be a political or business compromise model - we
>> must focus on scientific evaluation, technical requirements and
>> security.
>>
>
> I will assert that the block size is political because it affects nearly
> all users to some degree and not all those users are technically inclined
> or care to keep decentralisation in the current configuration as you do.
> This debate has forgotten the current and future users of Bitcoin. Most of
> them think the hit to node count in the short term preferable to making it
> expensive and competitive to transact.
>
> We all need a little faith that the system will reorganise and readjust
> after the move to big blocks in a way that still has a reasonable degree of
> decentralisation and trustlessness. The incentives of Bitcoin remain, so
> everyone's decentralised decision throughout the system, from miners,
> merchants and users, will continue to act according to those incentives.
> _______________________________________________
> bitcoin-dev mailing list
> 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/20150803/47306e83/attachment.html>

2023-06-07 15:44:38 UTC

- reply

📅 Original date posted:2015-08-03
📝 Original message:On 3 August 2015 at 08:16, Simon Liu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Increasing the block size shouldn't be a problem for Chinese miners.
> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
> already signed a draft agreement indicating they are fine with an
> increase to 8 MB: http://www.8btc.com/blocksize-increase-2
What's the current stance of the Chinese pools on Bitcoin XT, should
Bitcoin Core refuse to increase the block size to 8 MB in a timely fashion?
Would they run it if the economic majority (e.g. Coinbase, Bitpay, etc.)
publicly stated their support for big blocks?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/ca2d77ac/attachment.html>