Danny Thorpe [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-12 to 2017-10-30
💬 Posted a total of 22 messages
📚 Participated in the following categories: Bitcoin-development, RFC, bitcoin-dev, BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:07:15

- reply

📅 Original date posted:2017-10-30
📝 Original message:Humans are very visually oriented, recognizing differences in images more
easily than differences in text.
What about generating an image based on the bytes of an address, using
something like identicon, used by gravatar? Any small change to the text
input produces a significantly different image.
-Danny
On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If you are going to rely on human verification of addresses, the best way
> might be map it to words.
>
> For example, with a 6000 word list, a 25 byte address (with a checksum)
> could be mapped to 16 words like this:
>
> vocally acquire removed unfounded
> euphemism sanctuary sectional driving
> entree freckles aloof vertebrae
> scribble surround prelaw effort
>
> In my opinion, that is much faster to verify than this:
>
> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>
> or
>
> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>
> Although I really do love Bech32.
>
> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>> 62 bytes ! This is very very long. This will create lot of usability
>> problems in
>>
>> - Blockexplorers (atleast user should be visually able to compare in a
>> transaction having multiple outputs which one his address)
>> - Mobiles
>> - Payment terminals
>>
>> From my limited understanding, the purpose of inventing a bitcoin address
>> format is for usability and ease of identification (versus a ECDSA public
>> key), While I get the error/checksum capabilities Bech32 brings, any user
>> would prefer a 20 byte address with a checksum over an address that would
>> wrap several lines !!
>>
>>
>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>> thompson.benedictjames at gmail.com> wrote:
>>
>>> Checking the first few bytes of a Bitcoin Address should not be
>>> considered sufficient for ensuring that it is correct as it takes less than
>>> a second to generate a 3 character vanity address that matches the first 3
>>> characters of an address.
>>>
>>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> When I copy and paste bitcoin address, I double check the first few
>>>> bytes, to make sure I copied the correct one. This is to make sure some
>>>> rogue software is not changing the address, or I incorrectly pasted the
>>>> wrong address.
>>>>
>>>>
>>>> With Bech32 address, its seems like in this department we are taking as
>>>> step in the backward direction. With the traditional address, I could
>>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>>> and compare which is likely to be same anyway. Note that most users will
>>>> only compare the first few bytes only (since addresses themselves are very
>>>> long and will overflow in a mobile text box).
>>>>
>>>> Is there anyway to make the Bech32 addresses format more visually
>>>> distinct (atleast the first few bytes) ?
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20171030/ec4752a9/attachment.html>

2023-06-07 19:42:55

- reply

📅 Original date posted:2015-10-05
📝 Original message:What does "package" mean here?
When you say 25 txs, does that mean maximum linked chain depth, or total
number of dependent transactions regardless of chain depth?
Thanks,
-Danny
On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'd like to propose updates to the new policy limits on unconfirmed
> transaction chains.
>
> The existing limits in master and scheduled for release in 0.12 are:
> Ancestor packages = 100 txs and 900kb total size
> Descendant packages = 1000 txs and 2500kb total size
>
> Before 0.12 is released I would like to propose a significant reduction in
> these limits. In the course of analyzing algorithms for mempool limiting,
> it became clear that large packages of unconfirmed transactions were the
> primary vector for mempool clogging or relay fee boosting attacks. Feedback
> from the initial proposed limits was that they were too generous anyway.
>
> The proposed new limits are:
> Ancestor packages = 25 txs and 100kb total size
> Descendant packages = 25 txs and 100kb total size
>
> Based on historical transaction data, the most restrictive of these limits
> is the 25 transaction count on descendant packages. Over the period of
> April and May of this year (before stress tests), 5.8% of transactions
> would have violated this limit alone. Applying all the limits together
> would have affected 6.1% of transactions.
>
> Please keep in mind these are policy limits that affect transactions which
> depend on other unconfirmed transactions only. They are not a change to
> consensus rules and do not affect how many chained txs a valid block may
> contain. Furthermore, any transaction that was unable to be relayed due to
> these limits need only wait for some of its unconfirmed ancestors to be
> included in a block and then it could be successfully broadcast. This is
> unlikely to affect the total time from creation to inclusion in a block.
> Finally, these limits are command line arguments that can easily be changed
> on an individual node basis in Bitcoin Core.
>
> Please give your feedback if you know of legitimate use cases that would
> be hindered by these limits.
>
> Thanks,
> Alex
>
> On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos <morcos at gmail.com> wrote:
>
>> Thanks for everyone's review. These policy changes have been merged in
>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which
>> just implements these limits and no mempool limiting yet. The default
>> ancestor package size limit is 900kb not 1MB.
>>
>> Yes I think these limits are generous, but they were designed to be as
>> generous as was computationally feasible so they were unobjectionable
>> (since the existing policy was no limits). This does not preclude future
>> changes to policy that would reduce these limits.
>>
>>
>>
>>
>>
>> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe at gmail.com>
>> wrote:
>>
>>> The limits Alex proposed are generous (bordering on obscene!), but
>>> dropping that down to allowing only two levels of chained unconfirmed
>>> transactions is too tight.
>>>
>>> Use case: Brokered asset transfers may require sets of transactions with
>>> a dependency tree depth of 3 to be published together. ( N seller txs, 1
>>> broker bridge tx, M buyer txs )
>>>
>>> If the originally proposed depth limit of 100 does not provide a
>>> sufficient cap on memory consumption or loop/recursion depth, a depth limit
>>> of 10 would provide plenty of headroom for this 3 level use case and
>>> similar patterns.
>>>
>>> -Danny
>>>
>>> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> I dont see any problem with such limits. Though, hell, if you limited
>>>> entire tx dependency trees (ie transactions and all required unconfirmed
>>>> transactions for them) to something like 10 txn, maximum two levels
>>>> deep, I also wouldnt have a problem.
>>>>
>>>> Matt
>>>>
>>>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>>>> > Hi everyone,
>>>> >
>>>> >
>>>> > I'd like to propose a new set of requirements as a policy on when to
>>>> > accept new transactions into the mempool and relay them. This policy
>>>> > would affect transactions which have as inputs other transactions
>>>> which
>>>> > are not yet confirmed in the blockchain.
>>>> >
>>>> > The motivation for this policy is 6470
>>>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit
>>>> the
>>>> > size of a mempool. As discussed in that pull
>>>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736
>>>> >,
>>>> > once the mempool is full a new transaction must be able to pay not
>>>> only
>>>> > for the transaction it would evict, but any dependent transactions
>>>> that
>>>> > would be removed from the mempool as well. In order to make sure this
>>>> > is always feasible, I'm proposing 4 new policy limits.
>>>> >
>>>> > All limits are command line configurable.
>>>> >
>>>> > The first two limits are required to make sure no chain of
>>>> transactions
>>>> > will be too large for the eviction code to handle:
>>>> >
>>>> > Max number of descendant txs : No transaction shall be accepted if it
>>>> > would cause another transaction in the mempool to have too many
>>>> > descendant transactions (all of which would have to be evicted if the
>>>> > ancestor transaction was evicted). Default: 1000
>>>> >
>>>> > Max descendant size : No transaction shall be accepted if it would
>>>> cause
>>>> > another transaction in the mempool to have the total size of all its
>>>> > descendant transactions be too great. Default : maxmempool / 200 =
>>>> 2.5MB
>>>> >
>>>> > The third limit is required to make sure calculating the state
>>>> required
>>>> > for sorting and limiting the mempool and enforcing the first 2 limits
>>>> is
>>>> > computationally feasible:
>>>> >
>>>> > Max number of ancestor txs: No transaction shall be accepted if it
>>>> has
>>>> > too many ancestor transactions which are not yet confirmed (ie, in the
>>>> > mempool). Default: 100
>>>> >
>>>> > The fourth limit is required to maintain the pre existing policy goal
>>>> > that all transactions in the mempool should be mineable in the next
>>>> block.
>>>> >
>>>> > Max ancestor size: No transaction shall be accepted if the total size
>>>> of
>>>> > all its unconfirmed ancestor transactions is too large. Default: 1MB
>>>> >
>>>> > (All limits include the transaction itself.)
>>>> >
>>>> > For reference, these limits would have affected less than 2% of
>>>> > transactions entering the mempool in April or May of this year.
>>>> During
>>>> > the period of 7/6 through 7/14, while the network was under stress
>>>> test,
>>>> > as many as 25% of the transactions would have been affected.
>>>> >
>>>> > The code to implement the descendant package tracking and new policy
>>>> > limits can be found in 6557
>>>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off of
>>>> 6470.
>>>> >
>>>> > Thanks,
>>>> > Alex
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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/20151005/a1640a71/attachment.html>

2023-06-07 19:39:11

- reply

📅 Original date posted:2015-09-01
📝 Original message:Rather than using an inhumanly long hex string from the genesis hash to
distinguish between mainnet and testnet, why not use the network magic
bytes instead? Much shorter, just as distinct.
I'd still prefer a common network name mapping for the sake of humanity.
Few bitcoin library implementations use the same string names for mainnet
and testnet. This BIP could simply define one string name alias for each
supported network and leave mapping to local lingo to the implementors.
-Danny
On Sat, Aug 29, 2015 at 1:10 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 9:01 PM, Matt Whitlock via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > That's still not right, since "mainnet" and "testnet" are not host names.
> >
> > You'd have to do something like:
> >
> >
> blockchain:?network=testnet&txid=3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> I would really prefer chain=<chainID> over network=<chainPetnameStr>
> By chainID I mean the hash of the genesis block, see
>
> https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39
> I'm completely fine with doing that using an optional parameter (for
> backwards compatibility).
>
> I agree with Andreas Schildbach that respecting the most commonly used
> schemes is desirable.
> So my preference would be:
>
>
> /tx/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?chain=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
>
> (a tx in testnet)
>
>
> /block/00000000000000000b0d504d142ac8bdd1a2721d19f423a8146d0d6de882167b?chain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> (a block in bitcoin's mainnet)
> _______________________________________________
> 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/20150901/bd5d758c/attachment.html>

2023-06-07 19:36:44

- reply

📅 Original date posted:2015-08-19
📝 Original message:>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<
Ok, glad to hear that.
>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<
I saw your post about that awhile ago, thanks for doing the work! My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.
How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?
Thanks,
-Danny
On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/dabc7a84/attachment.html>

2023-06-07 19:36:41

- reply

📅 Original date posted:2015-08-18
📝 Original message:Again, I'm not suggesting further testing in sterile environments. I'm
suggesting testing on the public global testnet network, so that real-world
hazards such as network lag, bandwidth constraints, traffic bottlenecks,
etc can wreak what havoc they can on the proposed implementation. Also, a
test deployment would give more people an opportunity to see how the
proposed implementation works and "kick the tires", which might help to
reduce some degree of angst about the proposals.
Your point appears to be that the biggest challenge facing Bitcoin is not
technical, but political. Sadly, you may be right.
On Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> People have already been testing big blocks on testnets.
>
> The biggest problem here isn’t whether we can test the code in a fairly
> sterile environment. The biggest problem is convincing enough people to
> switch without:
>
> 1) Pissing off the other side enough to the point where regardless of who
> wins the other side refuses to cooperate
> 2) Screwing up the incentive model, allowing people to sabotage the
> process somehow
> 3) Setting a precedent enabling hostile entities to destroy the network
> from within in the future
> etc…
>
> These kinds of things seem very hard to test on a testnet.
>
> On Aug 18, 2015, at 2:06 PM, Danny Thorpe <danny.thorpe at gmail.com> wrote:
>
> Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
>
> And when I refer to testnet, I mean the public global testnet blockchain,
> not in-house isolated networks like testnet-in-a-box.
>
> On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> Problem is if you know most of the people running the testnet personally
>> (as is pretty much the case with many current testnets) then the deployment
>> amounts to “hey guys, let’s install the new version”
>>
>> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Deploying experimental code onto the "live" bitcoin blockchain seems
>> unnecessarily risky. Why not deploy a blocksize limit experiment for long
>> term trials using testnet instead?
>>
>> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> As I understand, there is already a consensus among core dev that block
>>> size should/could be raised. The remaining questions are how, when, how
>>> much, and how fast. These are the questions for the coming Bitcoin
>>> Scalability Workshops but immediate consensus in these issues are not
>>> guaranteed.
>>>
>>> Could we just stop the debate for a moment, and agree to a scheduled
>>> experimental hardfork?
>>>
>>> Objectives (by order of importance):
>>>
>>> 1. The most important objective is to show the world that reaching
>>> consensus for a Bitcoin hardfork is possible. If we could have a successful
>>> one, we would have more in the future
>>>
>>> 2. With a slight increase in block size, to collect data for future
>>> hardforks
>>>
>>> 3. To slightly relieve the pressure of full block, without minimal
>>> adverse effects on network performance
>>>
>>> With the objectives 1 and 2 in mind, this is to NOT intended to be a
>>> kick-the-can-down-the-road solution. The third objective is more like a
>>> side effect of this experiment.
>>>
>>>
>>> Proposal (parameters in ** are my recommendations but negotiable):
>>>
>>> 1. Today, we all agree that some kind of block size hardfork will happen
>>> on t1=*1 June 2016*
>>>
>>> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we
>>> will adopt the backup plan
>>>
>>> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
>>> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>>>
>>> 4. If the backup plan is adopted, we all agree that a better solution
>>> should be found before t4=*31 Dec 2017*.
>>>
>>> Rationale:
>>>
>>> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
>>> prepare for a hardfork. Although we do not know what actually will happen
>>> but we know something must happen around that moment.
>>>
>>> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
>>> months after the workshops). If it is successful, we don't need to activate
>>> the backup plan
>>>
>>> t3 = 30 days is chosen to make sure every full nodes have enough time to
>>> upgrade after the actual hardfork date is confirmed
>>>
>>> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
>>> hopefully we would find a better solution. It is important to acknowledge
>>> that the backup plan is not a final solution
>>>
>>> m = 80%: We don't want a very small portion of miners to have the power
>>> to veto a hardfork, while it is important to make sure the new fork is
>>> secured by enough mining power. 80% is just a compromise.
>>>
>>> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that
>>> all types of technology has since improved by >50%. I don't mind making it
>>> a bit smaller but in that case not much valuable data could be gathered and
>>> the second objective of this experiment may not be archived.
>>>
>>> --------------------
>>>
>>> If the community as a whole could agree with this experimental hardfork,
>>> we could announce the plan on bitcoin.org and start coding of the patch
>>> immediately. At the same time, exploration for a better solution continues.
>>> If no further consensus could be reached, a new version of Bitcoin Core
>>> with the patch will be released on or before 1 Feb 2016 and everyone will
>>> be asked to upgrade immediately.
>>> _______________________________________________
>>> 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/20150818/6ce5aad3/attachment.html>

2023-06-07 19:36:40

- reply

📅 Original date posted:2015-08-18
📝 Original message:Ya, so? All that means is that the experiment might reach the hard fork
tipping point faster than mainnet would. Verifying that the network can
handle such transitions, and how larger blocks affect the network, is the
point of testing.
And when I refer to testnet, I mean the public global testnet blockchain,
not in-house isolated networks like testnet-in-a-box.
On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Problem is if you know most of the people running the testnet personally
> (as is pretty much the case with many current testnets) then the deployment
> amounts to “hey guys, let’s install the new version”
>
> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Deploying experimental code onto the "live" bitcoin blockchain seems
> unnecessarily risky. Why not deploy a blocksize limit experiment for long
> term trials using testnet instead?
>
> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As I understand, there is already a consensus among core dev that block
>> size should/could be raised. The remaining questions are how, when, how
>> much, and how fast. These are the questions for the coming Bitcoin
>> Scalability Workshops but immediate consensus in these issues are not
>> guaranteed.
>>
>> Could we just stop the debate for a moment, and agree to a scheduled
>> experimental hardfork?
>>
>> Objectives (by order of importance):
>>
>> 1. The most important objective is to show the world that reaching
>> consensus for a Bitcoin hardfork is possible. If we could have a successful
>> one, we would have more in the future
>>
>> 2. With a slight increase in block size, to collect data for future
>> hardforks
>>
>> 3. To slightly relieve the pressure of full block, without minimal
>> adverse effects on network performance
>>
>> With the objectives 1 and 2 in mind, this is to NOT intended to be a
>> kick-the-can-down-the-road solution. The third objective is more like a
>> side effect of this experiment.
>>
>>
>> Proposal (parameters in ** are my recommendations but negotiable):
>>
>> 1. Today, we all agree that some kind of block size hardfork will happen
>> on t1=*1 June 2016*
>>
>> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will
>> adopt the backup plan
>>
>> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
>> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>>
>> 4. If the backup plan is adopted, we all agree that a better solution
>> should be found before t4=*31 Dec 2017*.
>>
>> Rationale:
>>
>> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
>> prepare for a hardfork. Although we do not know what actually will happen
>> but we know something must happen around that moment.
>>
>> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
>> months after the workshops). If it is successful, we don't need to activate
>> the backup plan
>>
>> t3 = 30 days is chosen to make sure every full nodes have enough time to
>> upgrade after the actual hardfork date is confirmed
>>
>> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
>> hopefully we would find a better solution. It is important to acknowledge
>> that the backup plan is not a final solution
>>
>> m = 80%: We don't want a very small portion of miners to have the power
>> to veto a hardfork, while it is important to make sure the new fork is
>> secured by enough mining power. 80% is just a compromise.
>>
>> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all
>> types of technology has since improved by >50%. I don't mind making it a
>> bit smaller but in that case not much valuable data could be gathered and
>> the second objective of this experiment may not be archived.
>>
>> --------------------
>>
>> If the community as a whole could agree with this experimental hardfork,
>> we could announce the plan on bitcoin.org and start coding of the patch
>> immediately. At the same time, exploration for a better solution continues.
>> If no further consensus could be reached, a new version of Bitcoin Core
>> with the patch will be released on or before 1 Feb 2016 and everyone will
>> be asked to upgrade immediately.
>> _______________________________________________
>> 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/20150818/8eb19293/attachment.html>

2023-06-07 19:36:39

- reply

📅 Original date posted:2015-08-18
📝 Original message:Deploying experimental code onto the "live" bitcoin blockchain seems
unnecessarily risky. Why not deploy a blocksize limit experiment for long
term trials using testnet instead?
On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As I understand, there is already a consensus among core dev that block
> size should/could be raised. The remaining questions are how, when, how
> much, and how fast. These are the questions for the coming Bitcoin
> Scalability Workshops but immediate consensus in these issues are not
> guaranteed.
>
> Could we just stop the debate for a moment, and agree to a scheduled
> experimental hardfork?
>
> Objectives (by order of importance):
>
> 1. The most important objective is to show the world that reaching
> consensus for a Bitcoin hardfork is possible. If we could have a successful
> one, we would have more in the future
>
> 2. With a slight increase in block size, to collect data for future
> hardforks
>
> 3. To slightly relieve the pressure of full block, without minimal adverse
> effects on network performance
>
> With the objectives 1 and 2 in mind, this is to NOT intended to be a
> kick-the-can-down-the-road solution. The third objective is more like a
> side effect of this experiment.
>
>
> Proposal (parameters in ** are my recommendations but negotiable):
>
> 1. Today, we all agree that some kind of block size hardfork will happen
> on t1=*1 June 2016*
>
> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will
> adopt the backup plan
>
> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>
> 4. If the backup plan is adopted, we all agree that a better solution
> should be found before t4=*31 Dec 2017*.
>
> Rationale:
>
> t1 = 1 June 2016 is chosen to make sure everyone have enough time to
> prepare for a hardfork. Although we do not know what actually will happen
> but we know something must happen around that moment.
>
> t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
> months after the workshops). If it is successful, we don't need to activate
> the backup plan
>
> t3 = 30 days is chosen to make sure every full nodes have enough time to
> upgrade after the actual hardfork date is confirmed
>
> t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
> hopefully we would find a better solution. It is important to acknowledge
> that the backup plan is not a final solution
>
> m = 80%: We don't want a very small portion of miners to have the power to
> veto a hardfork, while it is important to make sure the new fork is secured
> by enough mining power. 80% is just a compromise.
>
> s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all
> types of technology has since improved by >50%. I don't mind making it a
> bit smaller but in that case not much valuable data could be gathered and
> the second objective of this experiment may not be archived.
>
> --------------------
>
> If the community as a whole could agree with this experimental hardfork,
> we could announce the plan on bitcoin.org and start coding of the patch
> immediately. At the same time, exploration for a better solution continues.
> If no further consensus could be reached, a new version of Bitcoin Core
> with the patch will be released on or before 1 Feb 2016 and everyone will
> be asked to upgrade immediately.
> _______________________________________________
> 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/20150818/4f1217ce/attachment-0001.html>

2023-06-07 19:36:26

- reply

📅 Original date posted:2015-08-18
📝 Original message:I like the simplicity of this approach. Demand driven response.
Is there really a need to reduce the max block size at all? It is just a
maximum limit, not a required size for every block. If a seasonal
transaction surge bumps the max block size limit up a notch, what harm is
there in leaving the max block size limit at the "high water mark"
indefinitely, even though periods of decreased transaction volume?
I'd argue to remove the reduction step, making the max block size
calculation a monotonic increasing function. Cut the complexity in half.
-Danny
On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Regarding:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>
>
> I am arguing with the following statement here...
>
> *I see problems to this approach. The biggest one I see is that a miner
>> with 11% of hash power could sabotage block size increases by only ever
>> mining empty blocks.*
>
>
>
> First, I would like to argue from economics' point of view. If someone
> wants to hold back the block size increase with 11% hash power by mining
> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
> hash power will most likely be a pool and pool miners will find out soon
> that they are losing Tx fees because of pool owner's intention. Hence,
> they'll switch pool and pool owner will lose out. This is the same reason
> why 51% attack will never happen, even if a pool gets more than 51% hash
> power.
>
>
> Next, I would like to propose a slightly modified technical solution to
> this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
> Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
> Half MaxBlockSize
> Else
> Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 50%
> hash power. Those who want to stop decrease, need to have more than 10%
> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
> this approach, not only miners, but also the end user have their say.
> Because, end users will fill up the mempool, from where miners will take Tx
> to fill up the blocks. Please note that, taking first 2000 of the last 2016
> blocks is important to avoid data discrepancy among different nodes due to
> orphan blocks. It is assumed that a chain can not be orphaned after having
> 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
> _______________________________________________
> 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/20150818/c9dc8d59/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-13
📝 Original message:Please forgive my ignorance, but why should Bitcoin users have a say in
block size limits? It's the miners and Bitcoin node operators that bear
the burden of managing large blocks, no?
Users voting on network parameters sounds like neighbors voting on how deep
my swimming pool should be.
Thanks,
-Danny
On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete at petertodd.org> wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
>
> https://www.mail-archive.com/[email protected]/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/da34f3e3/attachment.html>