<unnamed>

Public Key

npub1l3uf9m4yw2y7x8wyjeswhelsqyy8ql4jaca4nyy6en0s474yadssg69pvv

Profile Code

nprofile1qqs0c7yja6j89z0rrhzfvc8tulcqzzrs06ewuw6ejzdvehc2l2jwkcgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqyjwek9

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:45:55 UTC

- reply

📅 Original date posted:2015-12-08
📝 Original message:Payment recipients would need to operate a daemon for each chain, thus
guaranteeing no scaling advantage.
(There are other issues, but I believe that to be enough of a show
stopper not to continue).
On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:
> Hello,
>
> I am seeking some expert feedback on an idea for scaling Bitcoin. As a
> brief introduction: I work in the payment industry and I have twenty
> years' experience in development. I have some experience with process
> groups and ordering protocols too. I think I understand Satoshi's
> paper but I admit I have not read the source code.
>
> The idea is to run more than one simultaneous chain, each chain
> defeating double spending on only part of the coin. The coin would be
> partitioned by radix (or modulus, not sure what to call it.) For
> example in order to multiply throughput by a factor of ten you could
> run ten parallel chains, one would work on coin that ends in "0", one
> on coin that ends in "1", and so on up to "9".
>
> The number of chains could increase automatically over time based on
> the moving average of transaction volume.
>
> Blocks would have to contain the number of the partition they belong
> to, and miners would have to round-robin through partitions so that an
> attacker would not have an unfair advantage working on just one partition.
>
> I don't think there is much impact to miners, but clients would have
> to send more than one message in order to spend money. Client messages
> will need to enumerate coin using some sort of compression, to save
> space. This seems okay to me since often in computing client software
> does have to break things up in equal parts (e.g. memory pages, file
> system blocks,) and the client software could hide the details.
>
> Best wishes for continued success to the project.
>
> Regards,
> Akiva
>
> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH"
>
>
>
> _______________________________________________
> 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/20151208/82e0a25d/attachment.html>

2023-06-07 17:45:55 UTC

- reply

📅 Original date posted:2015-12-08
📝 Original message:If partition is selected from a random key (the hash of the output for
example) then payment recipients would need to operate a full node on
each of the chains.
What's the point of partitioning if virtually everybody needs to operate
each partition?
The mining aspect has it's own set of issues, but I'm not going to get
into those.
On 12/08/2015 01:23 PM, Akiva Lichtner wrote:
> It's true that miners would have to be prepared to work on any
> partition. I don't see where the number affects defeating double
> spending, what matters is the nonce in the block that keeps the next
> successful miner random.
>
> I expect that the number of miners would be ten times larger as well,
> so an attacker would have no advantage working on one partition.
>
> On Tue, Dec 8, 2015 at 3:50 PM, Patrick Strateman via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Payment recipients would need to operate a daemon for each chain,
> thus guaranteeing no scaling advantage.
>
> (There are other issues, but I believe that to be enough of a show
> stopper not to continue).
>
> On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:
>> Hello,
>>
>> I am seeking some expert feedback on an idea for scaling Bitcoin.
>> As a brief introduction: I work in the payment industry and I
>> have twenty years' experience in development. I have some
>> experience with process groups and ordering protocols too. I
>> think I understand Satoshi's paper but I admit I have not read
>> the source code.
>>
>> The idea is to run more than one simultaneous chain, each chain
>> defeating double spending on only part of the coin. The coin
>> would be partitioned by radix (or modulus, not sure what to call
>> it.) For example in order to multiply throughput by a factor of
>> ten you could run ten parallel chains, one would work on coin
>> that ends in "0", one on coin that ends in "1", and so on up to "9".
>>
>> The number of chains could increase automatically over time based
>> on the moving average of transaction volume.
>>
>> Blocks would have to contain the number of the partition they
>> belong to, and miners would have to round-robin through
>> partitions so that an attacker would not have an unfair advantage
>> working on just one partition.
>>
>> I don't think there is much impact to miners, but clients would
>> have to send more than one message in order to spend money.
>> Client messages will need to enumerate coin using some sort of
>> compression, to save space. This seems okay to me since often in
>> computing client software does have to break things up in equal
>> parts (e.g. memory pages, file system blocks,) and the client
>> software could hide the details.
>>
>> Best wishes for continued success to the project.
>>
>> Regards,
>> Akiva
>>
>> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK
>> AT MATH"
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20151208/e19fe53b/attachment.html>

2023-06-07 17:43:52 UTC

- reply

📅 Original date posted:2015-10-22
📝 Original message:Benchmarks?
I cant imagine that's very fast.
On 10/22/2015 02:26 PM, Jeff Garzik via bitcoin-dev wrote:
> Here is the beginnings of an implementation to replace leveldb with
> sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite
>
> It builds, but still needs work before passing tests.
>
> It was noted that leveldb is unmaintained, and this is part of
> researching alternatives that are maintained and reliable.
>
>
>
>
> _______________________________________________
> 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/20151022/a4fb1966/attachment.html>

2023-06-07 17:40:55 UTC

- reply

📅 Original date posted:2015-09-18
📝 Original message:Full nodes using UTXO set commitments is a change to the bitcoin
security model.
Currently an attacker with >50% of the network hashrate can rewrite history.
If full nodes rely on UTXO set commitments such an attacker could create
an infinite number of bitcoins (as in many times more than the current
21 million bitcoin limit).
Before we consider mechanisms for UTXO set commitments, we should
seriously discuss whether the security model reduction is reasonable.
On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> Currently, when a new node wants to join the network, it needs to retrieve the entire blockchain history, starting from January 2009 and up until now, in order to derive a UTXO set that it can verify new blocks/transactions against. With a blockchain size of 40GB and a UTXO size of around 1GB, the extra bandwidth required is significant, and will keep increasing indefinitely. If a newly mined block were to include the UTXO set hash of the chain up until the previous block — the hash of the UTXO set on top of which this block builds — then new nodes, who want to know whether a transaction is valid, would be able to acquire the UTXO set in a trustless manner, by only verifying proof-of-work headers, and knowing that a block with an invalid UTXO set hash would be rejected.
>
> I’m not talking about calculating a complicated tree structure from the UTXO set, which would put further burden on already burdened Bitcoin Core nodes. We simply include the hash of the current UTXO set in a newly created block, such that the transactions in the new block build *on top* of the UTXO set whose hash is specified. This actually alleviates Bitcoin Core nodes, as it will now become possible for nodes without the entire blockchain to answer SPV queries (by retrieving the UTXO set trustlessly and using this to answer queries). It also saves bandwidth for Bitcore Core nodes, who only need to send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. I will continue to run a full Bitcoin Core node, saving the entire blockchain history, but it shouldn’t be a requirement to hold the entire transaction history in order to start verifying new transactions.
>
> As far as I can see, this also forces miners to actually maintain an UTXO set, rather than just build on top of the chain with the most proof-of-work. Producing a UTXO set and verifying a block against a chain is the same thing, so by including the hash of the UTXO set we force miners to verify the block that they want to build on top of.
>
> Am I missing something obvious, because as far as I can see, this solves the problem of quadratic time complexity for initial sync: http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
>
> The only added step to verifying a block is to hash the UTXO set. So it does require additional computation, but most modern CPUs have a SHA256 throughput of around 500 MB/s, which means it takes only two seconds to hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, in my opinion.
>
> /Rune
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:38:15 UTC

- reply

📅 Original date posted:2015-08-27
📝 Original message:Are you aware of the prior work in this field?
https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/
On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
> Hi,
>
> I am proposing to create a AML-KYC module to control the network and
> also qualify use cases in OFAC compliant way.
> Here is the attached doc.
>
> Please provide your feedback and suggestions.
>
> Best,
> Prabhat Kumar Singh
>
>
> _______________________________________________
> 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/20150827/427f2fc0/attachment.html>

2023-06-07 17:36:18 UTC

- reply

📅 Original date posted:2015-08-17
📝 Original message:Nobody is going to click that...
On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> 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/20150817/7ba96795/attachment-0001.html>

2023-06-07 17:33:06 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message: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
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org
> <mailto: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
> <mailto: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/862c0d23/attachment.html>

2023-06-07 15:47:54 UTC

- reply

2023-06-07 15:45:21 UTC

- reply

📅 Original date posted:2015-08-10
📝 Original message:If a path cannot be built to the recipient through the lightning network
then a standard transaction should be used.
On 08/10/2015 01:27 AM, Thomas Zander via bitcoin-dev wrote:
> On Sunday 9. August 2015 23.51.50 Btc Drak via bitcoin-dev wrote:
>> I thought it's worth mentioning there is a specific Lightning Network
>> development mailing list at
>> http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
>> some pretty interesting explanations in the archives.
> While that is interesting, and I'll surely check it out, I think this list
> should get a good idea of what the limitations are.
>
> Where does it NOT make sense to use LN, where would it be better to put the
> transaction directly on the blockchain?
>
> This is what I'd like to know.
>
> Gavins usecase is useful, I'm also wondering about remittances and allowing
> international payments and global economy (company in Nairobi buys stock from
> company in Spain).

2023-06-07 15:45:19 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message: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
> <mailto: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
>> <mailto: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 <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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/20150809/03767706/attachment.html>

2023-06-07 15:45:19 UTC

- reply

📅 Original date posted:2015-08-10
📝 Original message:> I would be surprised if the rates charged to consumers for BTC credit
aren't much closer to today's BTC borrowing rates.
The borrowing rates you're talking about involve the risk of default.
In lightning the hubs funds are not at risk so long as they maintain
control of the private keys.
The rates charged by hubs will almost certainly be orders of magnitude
below the rates charged on the various p2p lending sites....
But that seems fairly obvious... did I miss something?
On 08/09/2015 06:52 PM, Tom Harding via bitcoin-dev wrote:
> On 8/9/2015 2:45 PM, Hector Chu 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.
>
> That describes the steady-state dynamics. I refer to the hub funding
> required to initiate and maintain the ability to receive payments.
>
> If Bob opens a channel at his hub, doesn't use it for spending, and
> Alice sends 1 BTC to the channel, her payment can only be applied if the
> hub has funded the channel with at least 1 BTC.
>
> Yes, the hub receives an offsetting payment (from Alice, ultimately) in
> another channel. But to make this work, it must subject 1 BTC to shared
> control with Bob and forfeit the use of that money for other purposes
> (opportunity cost) while the channel is open. The opportunity cost is
> likened to gold lease rates in the LN paper. I would be surprised if
> the rates charged to consumers for BTC credit aren't much closer to
> today's BTC borrowing rates. We'll see.
>
> Burying this cost in general fees might not work very well, because
> different Bobs may want different maximum payment amounts, and channels
> open for different lengths of time.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:45:19 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message: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
> <mailto: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/81b04cea/attachment-0001.html>

2023-06-07 15:45:18 UTC

- reply

📅 Original date posted:2015-08-09
📝 Original message:On the contrary those costs are clearly very low.
Both the time value of money and operating expenses will be trivial with
even a small volume of transactions.
The true cost of operating a hub is clearly in the enhanced risk of loss.
It's clear that risk of loss will be moderated by market forces.
The hubs which are better at securing their systems will reduce their
risk of loss and obtain a competitive advantage.
It's also important to note that the risk of loss is the same whether
the hub is doing 1 transaction/second or 1 million transactions/second.
At 1 transaction/second the cost (but not necessarily the fees) is going
to be quite high.
At 1 million transactions/second the cost is going to be very very low.
On 08/09/2015 03:03 PM, Hector Chu wrote:
> 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
> <mailto: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
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"
>> <mark at friedenbach.org <mailto: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
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20150809/07c84557/attachment.html>

2023-06-07 15:45:17 UTC

- reply

2023-06-07 15:40:34 UTC

- reply

📅 Original date posted:2015-06-26
📝 Original message:Planning for a hard forks which change the consensus rules (including
the blocksize limit) is something we can all agree is worthy of time and
effort.
However there is clearly not consensus sufficient today to deploy a hard
fork that changs the blocksize without there being serious and
potentially experiment ending consequences.
For a proposed hard fork to reach a level of consensus necessary to be
safe requires that there be a clear and self evident course of action.
That simply does not exist on the blocksize limit question.
On 06/26/2015 11:23 AM, Jeff Garzik wrote:
> Failure to plan now for a hard fork increase 6(?) months in the future
> produces that lumpy, unpredictable market behavior.
>
> The market has baked in the years-long behavior of low fees. From the
> market PoV, inaction does lead to precisely that, a sudden change over
> the span of a few months.
>
> At a higher level, people look at bitcoin and see people delaying,
> waiting, dawdling until the barn is actually on fire before taking
> action to put out the fire.
>
> They see a system that is not responsive to higher level externalities
> of people & businesses making plans for the future. Based on current
> proposal of change-through-inaction, businesses will simply shelve
> plans to use bitcoin and not bother putting those new users on the
> network.
>
> If you wait until the need to increase block size is acute, it is
> already too late. (1) Businesses have permanently shelved plans to
> use bitcoin and (2) change at that point produces _larger_ disruption
> to the fee market.
>
> Hard forks require planning many months in advance. Gavin's timing is
> sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal.
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
>
> I am not saying that economic change is what we want. Only that it
> is inevitable, independent of whether larger blocks happen or not.
>
> I am saying that acting because of fear of economic change is a
> bad reason. The reason for increase should be because of the
> higher utility. We need it at some point, but there should be no rush.
>
> I do understand that we want to avoid a *sudden* change in
> economic policy, but I'm generally not too worried. Either fees
> increase and they get paid, and we're good. But more likely is
> that some uses just move off-chain because the block chain does
> not offer what they need. That's sad, but it is inevitable at any
> size: some uses fit, some don't.
>
> --
> Pieter
>
> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com
> <mailto:jgarzik at gmail.com>> wrote:
>
> It is not "fear" of fee pressure.
>
> 1) Blocks are mostly not-full on average.
>
> 2) Absent long blocks and stress tests, there is little fee
> pressure above the anti-spam relay fee metric, because of #1.
>
> 3) As such, inducing fee pressure is a delta, a change from
> years-long bitcoin economic policy. Each time we approach the
> soft limit, Bitcoin Core increases the soft limit to prevent
> "full" blocks. Mike Hearn et. al. lobbies miners to upgrade.
>
> (note - this is not an endorsement of these actions - it is a
> neutral observation)
>
> 4) Inaction leads to consistent fee pressure as the months
> tick on and system volume grows; thus, inaction leads to
> economic policy change.
>
> 5) Economic policy change leads to market and software
> disruption. The market and software - notably wallets - is
> not prepared for this.
>
> 6) If you want to change economic policy, that's fine. But be
> honest and admit you are arguing for a change, a delta from
> current market expectations and behavior.
>
> 7) It is critical to first deal with what _is_, not what you
> wish the world to be. You want a fee market to develop.
> There is nothing wrong with that desire. It remains a delta
> from where we are today, and that is critically relevant in a
> $3b+ market.
>
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
>
> Hello all,
>
> here I'm going to try to address a part of the block size
> debate which has been troubling me since the beginning:
> the reason why people seem to want it.
>
> People say that larger blocks are necessary. In the long
> term, I agree - in the sense that systems that do not
> evolve tend to be replaced by other systems. This
> evolution can come in terms of layers on top of Bitcoin's
> blockchain, in terms of the technology underlying various
> aspects of the blockchain itself, and also in the scale
> that this technology supports.
>
> I do, however, fundamentally disagree that a fear for a
> change in economics should be considered to necessitate
> larger blocks. If it is, and there is consensus that we
> should adapt to it, then there is effectively no limit
> going forward. This is similar to how Congress voting to
> increase the copyright term retroactively from time to
> time is really no different from having an infinite
> copyright term in the first place. This scares me.
>
> Here is how Gavin summarizes the future without increasing
> block sizes in PR 6341:
>
> > 1. Transaction confirmation times for transactions with
> a given fee will rise; very-low-fee transactions will fail
> to get confirmed at all.
> > 2. Average transaction fee paid will rise
> > 3. People or applications unwilling or unable to pay the
> rising fees will stop submitting transactions
> > 4. People and businesses will shelve plans to use
> Bitcoin, stunting growth and adoption
>
> Is it fair to summarize this as "Some use cases won't fit
> any more, people will decide to no longer use the
> blockchain for these purposes, and the fees will adapt."?
>
> I think that is already happening, and will happen at any
> scale. I believe demand for payments in general is nearly
> infinite, and only a small portion of it will eventually
> fit on a block chain (independent of whether its size is
> limited by consensus rules or economic or technological
> means). Furthermore, systems that compete with Bitcoin in
> this space already offer orders of magnitude more capacity
> than we can reasonably achieve with any blockchain
> technology at this point.
>
> I don't know what subset of use cases Bitcoin will cater
> to in the long term. They have already changed - you see
> way less betting transactions these days than a few years
> ago for example - and they will keep changing, independent
> of what effective block sizes we end up with. I don't
> think we should be afraid of this change or try to stop it.
>
> If you look at graphs of block sizes over time (for
> example, http://rusty.ozlabs.org/?p=498), it seems to me
> that there is very little "organic" growth, and a lot of
> sudden changes (which could correspond to changing
> defaults in miner software, introduction of popular
> sites/services, changes in the economy). I think these can
> be seen as the economy changing to full up the available
> space, and I believe these will keep happening at any size
> effectively available.
>
> None of this is a reason why the size can't increase.
> However, in my opinion, we should do it because we believe
> it increases utility and understand the risks; not because
> we're afraid of what might happen if we don't hurry up.
> And from that point of view, it seems silly to make a huge
> increase at once...
>
> --
> Pieter
>
>
> _______________________________________________
> 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
>
>
>
>
>
> _______________________________________________
> 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/20150626/6adbfdb4/attachment-0001.html>