Marcel Jamin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-01 to 2018-08-01
💬 Posted a total of 26 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rk

Profile Code

nprofile1qqs2ev59s399je5eu5sqphs24ujc6gu6m2n2z929rsy4g6p707pgwucc9kg8g

Author Public Key

npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rk

Show more details

Last Notes

2023-06-09 12:47:40

- reply

📅 Original date posted:2017-11-15
📝 Original message:
... and Matt blue!
Your hair color related hard fork did not have consensus.
On 15 November 2017 at 04:41, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> +1
>
> Keep Bitcoin Weird.
>
> On November 14, 2017 10:16:56 PM EST, Satoshi Nakamoto <satoshinjp at gmx.com>
> wrote:
>>
>> Hello Every Ones,
>>
>>
>>
>> I was travelling all around the cyberspace to find my twin brother, who
>> has been lost in the unknown since 2007. By chance I was passing by, so I
>> thought it would be good to stop over my Intergalactic Cyberspace Craft as I
>> have noticed something lightning here; I think you all are here trying to do
>> something to achieve something greater than others which is more transparent
>> and efficient. It is always good to try and expect far greater success.
>> There is nothing wrong being optimistic and expecting something very large
>> if it is measureable by quantum mechanism no matter what others may think or
>> they may say ?
>>
>>
>>
>> Try your best but plan ahead with systemitic strategic capacity. I used to
>> hear from the older folks two and a half decades ago ‘something must emerge,
>> something must emerge’ they used to say it day and night but when something
>> has emerged they cannot see it, some of them are day blind and the rest have
>> gone out of their own mind; I think you all will find, what you are looking
>> forward to find but please be kind to each other no matter what the
>> backbiter say distressful things behind your back ? Be determined and try;
>> try and try again and again until you find a perfect algorithm to complete
>> your mission.
>>
>>
>>
>> Satoshi Nakamoto
>>
>>
>>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

2023-06-07 18:13:53

- reply

📅 Original date posted:2018-08-01
📝 Original message:IMHO you should almost never publish a service that asks users for private
keys.
A warning isn't enough. Your server might get compromised.
"Move your coins by yourself" isn't even correct if your server is involved.
On Tue, 31 Jul 2018 at 13:26, Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I know this list is not to advertise personal projects but
> https://peersm.com/wallet might be of some interest, this is the web
> interface for https://github.com/Ayms/bitcoin-transactions since
> apparently quasi nobody succeeds to use it
>
> As far as I know (and surprisingly) this is the only online tool that
> converts bech32 addresses (Sipa's one does not output something
> understandable by everybody, the tool is using his code), the only one
> that converts from any address to any address, maybe the only one that
> decodes simply redeem scripts and probably the only one that allows to
> create transactions by its own (the advanced mode is not implemented for
> now but will be soon)
>
> Ideally it should be an offline tool if there is some incentive to do
> so, so of course it is not advised to use his private keys for now
>
> Maybe they are mistaken but some users are reporting invalid bech32
> addresses from their Electrum wallet, after segwit, bech32 confusion
> seems to be the topic of the moment
>
> Regards
>
> Aymeric
>
> --
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev 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/20180801/7f4e4e8f/attachment.html>

2023-06-07 18:08:43

- reply

📅 Original date posted:2017-12-15
📝 Original message:I think one could make the argument that the only people who talk
about and understand 24 bit audio or 256 bit cryptography are the ones
who can tell the difference very easily.
To me, your example seems to try hard to make the case for a problem
that won't exist in reality.
Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
>correct< approach. It's tidy, systematic and precise. But that won't
stop people from using something that's easier to deal with as I just
had to google the µ character again.
Let's also keep in mind that Coinbase has been using "bits" as the
default for over 2 years now:
https://blog.coinbase.com/bits-is-the-new-default-and-all-new-users-get-100-bits-for-free-9165f757594b
Just from a linguistic standpoint, chances are we'll end up with bits
anyway. Why fight it? We don't have a SI prefix educational mandate.
Marcel
On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
>
> Reposting /u/BashCo's post on reddit here, for visibility:
>
> ---8<---------------------------------------------------------------
>
>> Before anyone says 'bits' are too confusing because it's a computer
>> science term, here's a list of homonyms
>> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every
>> day. Homonyms are fine because our brains are able to interpret language
>> based on context, so it's a non-argument.
>
>
> This ignores the fact that there exists multiple meanings of bits *within
> the same context*, and that beginners likely can't tell them apart.
>
> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
> value with somebody who doesn't understand Bitcoin. Then explain that the
> cryptography uses 256 bit keys. I would be surprised if you could find
> somebody who would not be confused by that.
>
> Let's say a website says a song is 24 bits. Was that 24 bit audio resolution
> or 24 bit price? Somebody writes about 256 bit keys, are that their size or
> value?
>
> You guys here can probably tell the difference. Can everybody...? Bits will
> cause confusion, because plenty of people will not be able to tell these
> apart. They will not know WHEN to apply one definition or the other.
>
> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>
>

2023-06-07 18:08:42

- reply

📅 Original date posted:2017-12-14
📝 Original message:On 13 December 2017 at 22:36, David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> - Microbitcoins is not a homonym for any other word in English (and
> probably not in any other language), whereas "bit" and "bits" have
> more than a dozen homonyms in English---some of which are quite common
> in general currency usage, Bitcoin currency usage, or Bitcoin
> technical usage.
Reposting /u/BashCo's post on reddit here, for visibility:
---8<---------------------------------------------------------------
> Before anyone says 'bits' are too confusing because it's a computer science term, here's a list of homonyms [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every day. Homonyms are fine because our brains are able to interpret language based on context, so it's a non-argument. Also, the term 'bits' was used in reference to money long before 'bits and bytes' came along, and even before the metric system itself.
> https://en.wikipedia.org/wiki/Bit_(money)
> https://en.wikipedia.org/wiki/Spanish_colonial_real
> 'Bits' are superior to mBTC partly because we'll need to transition to bits eventually anyways (one transition is easier than two), but more importantly, bits have two decimal places, matching the format of dozens of other major currencies.
> No other currency has 8 decimal places, or even 4 decimal places. Most of them have 2. Dollars and cents, Bits and satoshis.
> If people actually want this to happen, then they need to train their own brains by switching their wallets and exchange settings to bits. The shift will probably happen eventually, although the major Bitcoin denomination probably isn't going anywhere any time soon, even if the majority of people use 'bits' as a matter of habit.
> 99.99 bits is currently equal to $1.63 USD.
---8<---------------------------------------------------------------
>
> - Microbitcoins trains users to understand SI prefixes, allowing them to
> easily migrate from one prefix to the next. This will be important
> when bitcoin prices rise to $10M USD[1] and the bits denomination has
> the same problems the millibitcoin denomination has now, but it's also
> useful in the short term when interacting with users who make very
> large payments (bitcoin-scale) or very small payments
> (nanobitcoin-scale).[2] Maybe a table of scale can emphasize this
> point:
>
> Wrong (IMO): Right (IMO):
> --------------- --------------
> BTC BTC
> mBTC mBTC
> bits µBTC
> nBTC nBTC
>
I wouldn't expect people to type out µBTC. I think the best you can
hope for here is uBTC. As for saying "microbitcoins", I can virtually
guarantee that this will be abbreviated to "microbits" and/or
eventually "bits" anyway. Bits and sats.
> [1] A rise in price to $10M doesn't require huge levels of growth---it
> only requires time under the assumption that a percentage of bitcoins will
> be lost every year due to wallet mishaps, failure to inherit bitcoins,
> and other issues that remove bitcoins from circulation. In other words,
> it's important to remember that Bitcoin is expected to become a
> deflationary currency and plan accordingly.
>
> [2] Although Bitcoin does not currently support committed
> nanobitcoin-scale payments in the block chain, it can be supported in a
> variety of ways by offchain systems---including (it is hypothesized)
> trustless systems based on probabilistic payments.
>
> Thanks,
>
> -Dave
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:00:28

- reply

📅 Original date posted:2017-04-18
📝 Original message:Probably a bad idea for various reasons, but tagging (fee paying)
transactions with info about the capabilities of the node that created
it might be interesting? Might be useful to gauge economic support for
certain upgrades, especially if excluding long transaction chains,
etc. In the very least it would be a far better indicator than simply
counting reachable nodes.
On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If users added a signal to OP_RETURN, might it be possible to tag all
> validated input addresses with that signal.
>
> Then a node can activate a new feature after the percentage of tagged input
> addresses reaches a certain level within a certain period of time?
>
> This could be used in addition to a flag day to trigger activation of a
> feature with some reassurance of user uptake.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:56:56

- reply

📅 Original date posted:2017-03-05
📝 Original message:> This could even come in the form of a Bitcoin address.
Wouldn't this actually *need* to be a bitcoin address that is included in a
block to get any real assurances about the age if this node id? Otherwise
malicous nodes could lie and claim to have seen a brand new node id years
ago already.
Even if included in a block, people could sell their aged IDs (if we were
to rely on those for anything).
Also funding that ID address would might tie your economic activity (or
even identity) to a node.
On 4 March 2017 at 17:04, John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> john at seebitcoin.com
>
>
> _______________________________________________
> 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/20170305/baaa502c/attachment.html>

2023-06-07 17:56:55

- reply

📅 Original date posted:2017-03-07
📝 Original message:> Why are multiple results separated by a line-feed rather than using a JSON Array?
> * Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file.
> * Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time.
> What if long descriptions require line and paragraph breaks?
> * Clients should word-wrap long lines, and JSON escapes newlines as "\n" which can be used doubly ("\n\n") for paragraph breaks.
I'd file this under premature optimization at the cost of
interoperability. If you use JSON, then please use it properly.
I'd also say it's the job of the parser to offer a way of doing that,
e.g. in .NET you can easily achieve that with Newtonsoft's JSON
parser: http://stackoverflow.com/questions/20374083/deserialize-json-array-stream-one-item-at-a-time.
On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Investigating what it would take to add fiat currency information to Bitcoin
> Knots, I noticed Electrum currently has many implementations, one for each
> exchange rate provider, due to lack of a common format for such data.
>
> Therefore, I put together an initial draft of a BIP that could standardise
> this so wallets (or other software) and exchange rate providers can simply
> interoperate without a lot of overhead reimplementing the same thing many
> ways.
>
> One thing I am unsure about, is that currently this draft requires using XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis, but those
> don't really have a pseudo-ISO currency code to fit in nicely...
>
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.mediawiki
>
> Thoughts? Anything critical missing? Ways to make the interface better?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:47:24

- reply

📅 Original date posted:2015-12-30
📝 Original message:I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.
2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> As a first impression, I think this proposal is intellectually
> interesting, but crufty and hackish and should never actually be deployed.
> Writing code for Bitcoin in a future in which we have deployed a few
> generalized softforks this way sounds terrifying.
>
> Instead of this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> return block->vtx[index];
> }
>
> We might have this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> if (!IsBIP102sBlock(block)) {
> return block->vtx[index];
> } else {
> if (!IsOtherGeneralizedSoftforkBlock(block)) {
> // hooray! only one generalized softfork level to deal
> with!
> return
> LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
> } else {
> throw NotImplementedError; // I'm too lazy to write
> pseudocode this complicated just to argue a point
> }
> }
>
> It might be possible to make that a bit simpler with recursion, or by
> doing subsequent generalized softforks in a way that doesn't have
> multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.
>
>
>
>
> On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Below is a proof-of-concept implementation of BIP102 as a softfork:
> >
> > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> >
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
> >
> > BIP102 is normally a hardfork. The softfork version (unofficial
> > codename BIP102s) uses the idea described here:
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
> >
> > The basic idea is that post-fork blocks are constructed in such a way
> > they can be mapped to valid blocks under the pre-fork rules. BIP102s
> > is a softfork in the sense that post-fork miners are still creating a
> > valid chain under the old rules, albeit indirectly.
> >
> > From the POV of non-upgraded clients, BIP102s circumvents the
> > block-size limit by moving transaction validation data "outside" of
> > the block. This is a similar trick used by Segregated Witness and
> > Extension Blocks (both softfork proposals).
> >
> > From the POV of upgraded clients, the block layout is unchanged,
> > except:
> > - A larger 2MB block-size limit (=BIP102);
> > - The header Merkle root has a new (backwards compatible)
> > interpretation;
> > - The coinbase encodes the Merkle root of the remaining txs.
> > Aside from this, blocks maintain their original format, i.e. a block
> > header followed by a vector of transactions. This keeps the
> > implementation simple, and is distinct from SW and EB.
> >
> > Since BIP102s is a softfork it means that:
> > - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This
> > is not true for a hardfork.
> > - Fraud risk is significantly reduced (6-conf unlikely depending on
> > activation threshold).
> > This should address some of the concerns with deploying a block-size
> > increase using a hardfork.
> >
> > Notes:
> >
> > - The same basic idea could be adapted to any of the other proposals
> > (BIP101, 2-4-8, BIP202, etc.).
> > - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> > The activation logic is left unchanged.
> > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> > code :-(
> >
> > --joe
> >
> > _______________________________________________
> > 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/20151230/5c2838ea/attachment.html>

2023-06-07 17:46:38

- reply

📅 Original date posted:2015-12-17
📝 Original message:Maybe we should first gather concrete estimates about and roughly agree on
- how long SW (SF) development will probably take
- how long the ecosystem needs to prepare for a hardfork (SW (HF) or a
simple can kicking block size increase)
Opinions differ wildly from what it looks like, but maybe we can get to
estimates that the majority here can accept.
---
Personally, I think that the disclaimer "Bitcoin is an experiment" is
pervasive. It's still a pre-release, even with a $6bn vote of confidence.
If you don't follow developments in this phase, don't upgrade and then have
an elevated risk of losing money by getting scammed, then that's a little
bit your fault. I'd absolutely support a change in mentality on that once
1.0.0 arrives, but until then is bitcoin a work-in-progress experiment and
a high risk investment.
A planned hard-fork is an experiment that needs to be run anyway. When do
we want to do that, if not now?
2015-12-16 21:50 GMT+01:00 Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
> On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> 1. Summary
>>
>> Segregated Witness (SegWitness, SW) is being presented in the context of
>> Scaling Bitcoin. It has useful attributes, notably addressing a major
>> malleability vector, but is not a short term scaling solution.
>>
>>
>> 2. Definitions
>>
>> Import Fee Event, ECE, TFM, FFM from previous email.
>>
>> Older clients - Any software not upgraded to SW
>>
>> Newer clients - Upgraded, SW aware software
>>
>>
>> Block size - refers to the core block economic resource limit ed by
>> MAX_BLOCK_SIZE. Witness data (or extension block data) is excluded.
>> Requires a hard fork to change.
>>
>> Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE. Not
>> changed by SW.
>>
>>
>> Extended transaction - Newer, upgraded version of transaction data format.
>>
>> Extended block - Newer, upgraded version of block data format.
>>
>>
>> EBS - Extended block size. Block size seen by newer clients.
>>
>>
>> 3. Context of analysis
>>
>> One proposal presents SW *in lieu of* a hard fork block size increase.
>> This email focuses directly on that.
>>
>> Useful features outside block size context, such as anti-malleability or
>> fraud proof features, are not covered in depth.
>>
>>
>> 4.1. Observations on data structure formats and views
>>
>> SW creates two *views* of each transaction and block. SW has blocks and
>> extended blocks. Similarly, there exists transactions and extended
>> transactions.
>>
>> This view is rendered to clients depending on compatibility level. Newer
>> clients see extended blocks and extended transactions. Older clients see
>> blocks (limit 1M), and do not see extended blocks. Older clients see
>> upgraded transactions as unsigned, anyone-can-pay transactions.
>>
>> Each extended transaction exists in two states, one unsigned and one
>> signed, each of which passes validation as a valid bitcoin transaction.
>>
>>
>> 4.2. Observations on behavior of older transaction creation
>>
>> Transactions created by older clients will not use the extended
>> transaction format. All data is stored the standard 1M block as today.
>>
>>
>> 4.3. Observations on new block economic model
>>
>> SW complicates block economics by creating two separate, supply limited
>> resources.
>>
>> The core block economic resource is heavily contended. Older clients use
>> core blocks exclusively. Newer clients use core block s more
>> conservatively, storing as much data as possible in extended blocks.
>>
>> The extended block economic resource is less heavily contended, though
>> that of course grows over time as clients upgrade.
>>
>> Because core blocks are more heavily contended, it is presumed that older
>> clients will pay a higher fee than newer clients (subject to elasticity
>> etc.).
>>
>>
>> 5.1. Problem: Pace of roll-out will be slow - Whole Ecosystem must be
>> considered.
>>
>> The current apparent proposal is to roll out Segregated Witness as a soft
>> fork, and keep block size at 1M.
>>
>> The roll-out pace cannot simply be judged by soft fork speed - which is
>> months at best. Analysis must the layers above: Updating bitcoin-core
>> (JS) and bitcoinj (Java), and then the timelines to roll out those updates
>> to apps, and then the timeline to update those apps to create extended
>> transactions.
>>
>> Overall, wallet software and programmer libraries must be upgraded to
>> make use of this new format, adding many more months (12+ in some stacks)
>> to the roll out timeline. In the meantime, clients continue to contend
>> entirely for core block space.
>>
>>
>> 5.2. Problem: Hard fork to bigger block size Just Works(tm) with most
>> software, unlike SW.
>>
>> A simple hard fork such as BIP 102 is automatically compatible with the
>> vast range of today's ecosystem software.
>>
>> SW requires merchants to upgrade almost immediately, requires wallet and
>> other peripheral software upgrades to make use of. Other updates are
>> opt-in and occur more slowly. BIP 70 processors need some updates.
>>
>> The number of LOC that must change for BIP 102 is very small, and the
>> problem domain well known, versus SW.
>>
>>
>> 5.3. Problem: Due to pace, Fee Event not forestalled.
>>
>> Even presuming SW is merged into Bitcoin Core tomorrow, this does not
>> address the risk of a Fee Event and associated Economic Change in the
>> coming months.
>>
>>
>> 5.4. Problem: More complex economic policy, new game theory, new
>> bidding structure risks.
>>
>> Splitting blocks into two pieces, each with separate and distinct
>> behaviors and resource values, creates *two fee markets.*
>>
>> Having two pricing strata within each block has certainly feasible - that
>> is the current mining policy of (1) fee/KB followed by (2) priority/age.
>>
>> Valuable or not - e.g. incentivizing older clients to upgrade - the fact
>> remains that SW creates a more-complex bidding structure by creating a
>> second economic resource.
>>
>> *This is clearly a change to a new economic policy* with standard risks
>> associated with that. Will that induce an Economic C hange Event (see def
>> last email)? *Unlikely*, due to slow rollout pace.
>>
>>
>> 5.5. Problem: Current SW mining algorithm needs improvement
>>
>> Current SW block template maker does a reasonable job, but makes some
>> naive assumptions about the fee market across an entire extended block.
>> This is a mismatch with the economic reality (just described).
>>
>> 5.6. Problem: New, under-analyzed attack surfaces
>>
>> Less significant and fundamental but still worth noting.
>>
>> This is not a fundamental SW problem, but simply standard complexity risk
>> factors: splitting the signatures away from transactions, and creating a
>> new apparently-unsigned version of the transaction opens t he possibility
>> of some network attacks which cause some clients to degrade down from
>> extended block to core block mode temporarily.
>>
>> There is a chance of a failure mode that fools older clients into
>> thinking fraudulent data is valid (judgement: unlikely vis hashpower but
>> not impossible)
>>
>> 6. Conclusions and recommendations
>>
>> It seems unlikely that SW provides scaling in the short term, and SW
>> introduces new economics complexities.
>>
>> A "short term bump" hard fork block size increase addresses economic and
>> ecosystem risks that SW does not.
>>
>> Bump + SW should proce ed in parallel, independent tracks, as orthogonal
>> issues.
>>
>>
>> 7. Appendix - Other SW comments
>>
>> Hard forks provide much stronger validation, and ensure the network
>> operates at a fully trustless level.
>>
>> SW hard fork is preferred, versus soft fork. Soft forking SW places a
>> huge amount of trust on miners to validate transaction signatures, versus
>> the rest of the network, as the network slowly upgrades to newer clients.
>>
>> An SW hard fork could also add several zero-filled placeholders in a
>> merkle tree for future use.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> 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/20151217/689f5cee/attachment.html>

2023-06-07 17:42:45

- reply

📅 Original date posted:2015-10-06
📝 Original message:This is childish and very disappointing to see.
2015-10-06 9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> I prefer the term "clown".
>
> Can we please move on?
>
> ------ Original Message ------
> From: "cipher anthem via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>
> To: milly at bitcoins.info
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Sent: 10/6/2015 12:17:14 AM
> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
> technical debate
>
> Sent: Monday, October 05, 2015 at 8:21 PM
>>> From: "Milly Bitcoin via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org>
>>> To: bitcoin-dev at lists.linuxfoundation.org
>>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
>>> technical debate
>>> On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
>>>
>>>> It's pretty clear Mike has turned into concern troll and bully.
>>>>
>>>
>> "troll" and, even worse, "concern troll" are terms generally used by
>>> teenagers on places like Reddit to complain about someone who doesn't
>>> agree with them.
>>>
>>
>> They should substitute troll for cultist so they appear more
>> professional...
>> _______________________________________________
>> 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/20151006/10d3c219/attachment.html>

2023-06-07 17:42:14

- reply

📅 Original date posted:2015-10-01
📝 Original message:2015-10-01 12:15 GMT+02:00 Wladimir J. van der Laan <laanwj at gmail.com>:
> On Thu, Oct 01, 2015 at 12:10:45PM +0200, Marcel Jamin wrote:
> > I think the question has already been answered for you by the companies
> > that build on top of it, the investments being made and the $3.5 billion
> > market cap. The 1.0.0 tag is probably long overdue.
>
> May I remind you that by far, most of that investment is not in the
> Bitcoin Core software.
>
As I understand it, right now the bitcoin protocol is defined by the
bitcoin core implementation. Or is there anything else to point to? So I'd
say my point still stands.
Other implementations copy what bitcoin core does.
> > Then you could start using the version as a signaling mechanism.
>
> We certainly could, it is a decision to not to.
>
Simply because of the "1.0.0" issue or for other reasons as well?
> 2015-10-01 11:56 GMT+02:00 Wladimir J. van der Laan <laanwj at gmail.com>:
> >
> > > On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
> > > > I guess the question then becomes why bitcoin still is <1.0.0
> > >
> > > I'll interpret the question as "why is the Bitcoin Core software still
> > > <1.0.0". Bitcoin the currency doesn't have a version, the
> block/transaction
> > > versions are at v3/v1 respectively, and the highest network protocol
> > > version is 70011.
> > >
> > > Mostly because we don't use the numbers as a signaling mechanism. They
> > > just count up, every half year.
> > >
> > > Otherwise, one'd have to ask hard questions like 'is the software
> mature
> > > enough to be called 1.0.0', which would lead to long arguments, all of
> > > which would eventually lead to nothing more than potentially
> increasing a
> > > number. We're horribly stressed-out as is.
> > >
> > > Wladimir
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/bb50904f/attachment.html>

2023-06-07 17:42:13

- reply

📅 Original date posted:2015-10-01
📝 Original message:---------- Forwarded message ----------
From: Marcel Jamin <marcel at jamin.net>
Date: 2015-10-01 11:39 GMT+02:00
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
To: Btc Drak <btcdrak at gmail.com>
I guess the question then becomes why bitcoin still is <1.0.0
I'd say it's safe to say that it's used in production.
2015-10-01 11:17 GMT+02:00 Btc Drak <btcdrak at gmail.com>:
> On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>>
>
> We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
> are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/17164b7e/attachment.html>

2023-06-07 17:42:13

- reply

📅 Original date posted:2015-10-01
📝 Original message:> Mostly because we don't use the numbers as a signaling mechanism. They
just count up, every half year.
OK, but then it's not semantic versioning (as btcdrak claims).
> Otherwise, one'd have to ask hard questions like 'is the software mature
enough to be called 1.0.0'
I think the question has already been answered for you by the companies
that build on top of it, the investments being made and the $3.5 billion
market cap. The 1.0.0 tag is probably long overdue.
Then you could start using the version as a signaling mechanism.
> We're horribly stressed-out as is.
Yeah, probably not a very important topic right now.
2015-10-01 11:56 GMT+02:00 Wladimir J. van der Laan <laanwj at gmail.com>:
> On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
> > I guess the question then becomes why bitcoin still is <1.0.0
>
> I'll interpret the question as "why is the Bitcoin Core software still
> <1.0.0". Bitcoin the currency doesn't have a version, the block/transaction
> versions are at v3/v1 respectively, and the highest network protocol
> version is 70011.
>
> Mostly because we don't use the numbers as a signaling mechanism. They
> just count up, every half year.
>
> Otherwise, one'd have to ask hard questions like 'is the software mature
> enough to be called 1.0.0', which would lead to long arguments, all of
> which would eventually lead to nothing more than potentially increasing a
> number. We're horribly stressed-out as is.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/9ae2c230/attachment.html>

2023-06-07 17:42:12

- reply

📅 Original date posted:2015-10-01
📝 Original message:Any particular reason bitcoin versioning doesn't follow the SemVer spec?
2015-10-01 10:50 GMT+02:00 Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On Wed, Sep 30, 2015 at 05:57:42PM +0000, Luke Dashjr wrote:
> > On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
> > bitcoin-dev wrote:
> > > 2015-12-01
> > > -----------
> > > - Feature freeze
> >
> > Where is "Consensus freeze"? Shouldn't this be put off until after the HK
> > workshop in case a hardfork is decided on? Or have we de-coupled it from
> the
> > release process entirely anyway (since old versions need an update for it
> > too)?
>
> In principle, "feature freeze" means that any large code changes will no
> longer go into 0.12, unless fixing critical bugs.
>
> I'm not keen on postponing 0.12 for such reasons - after the HK workshop
> I'm sure that it will take some development/testing/review before code
> makes it into anything. Apart from that there's a good point to decouple
> consensus changes from Bitcoin Core major releases.
>
> We've seen lot of release date drift due to "this and this change needs to
> make it in" in the past, that was a major reason to switch to a time-based
> instead of feature-based release schedule.
>
> We can always do a 0.12.1.
>
> Wladimir
> _______________________________________________
> 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/20151001/5dca9e61/attachment.html>

2023-06-07 17:42:11

- reply

📅 Original date posted:2015-10-02
📝 Original message:2015-10-02 15:14 GMT+02:00 jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> According to the Oxford Dictionary, "coin" as a verb means "invent (a new
> word or phrase)". Undoubtedly you created the first functional SPV client
> but please retract the claim "I coined the term SPV" or that's plagiarism.
>
>
Or simply stop pursuing this silly distraction.
> And I'd like to highlight the following excerpt from the whitepaper: "the
> simplified method can be fooled by an attacker's fabricated transactions
> for as long as the attacker can continue to overpower the network. One
> strategy to protect against this would be to accept alerts from network
> nodes when they detect an invalid block, prompting the user's software to
> download the full block and alerted transactions to confirm the
> inconsistency."
>
> Header only clients without any fraud detecting mechanism are functional
> but incomplete SPV implementations, according to Sathoshi's original
> definition. This might be good enough for the first generation SPV wallet,
> but eventually SPV clients should be ready to detect any rule violation in
> the blockchain, including things like block size (as Satoshi mentioned
> "invalid block", not just "invalid transaction").
>
> Mike Hearn via bitcoin-dev 於 2015-10-02 08:23 寫到:
>
>> FWIW the "coining" I am referring to is here:
>>
>> https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285 [4]
>>
>> OK, with that, here goes. Firstly some terminology. I'm going to call
>> these things SPV clients for "simplified payment verification".
>> Headers-only is kind of a mouthful and "lightweight client" is too
>> vague, as there are several other designs that could be described as
>> lightweight like RPC frontend and Stefans WebCoin API approach
>>
>> At that time nobody used the term "SPV wallet" to refer to what apps
>> like BreadWallet or libraries like bitcoinj do. Satoshi used the term
>> "client only mode", Jeff was calling them "headers only client" etc.
>> So I said, I'm going to call them SPV wallets after the section of the
>> whitepaper that most precisely describes their operation.
>>
>
> _______________________________________________
> 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/20151002/d26d51af/attachment.html>

2023-06-07 17:39:54

- reply

📅 Original date posted:2015-09-11
📝 Original message:> Therefore it is important that it be reasonably convenient to run full
nodes for decentralisation security.
Yes, and I'm suggesting to define what "reasonably convenient" is in 2016.
Most likely node operators have more than a little headroom for larger
blocks. If you just use more of the processing power / storage / bandwidth
you very likely already paid for then there is no increase in costs.
> I think you maybe misunderstanding what the Chinese miners said also, about
8MB, that was a cap on the maximum they felt they could handle with current
network infrastructure.
And what they felt "remained fair to all to all miners and node operators
worldwide." Increasing network connection requirements might even decrease
mining centralization right now.
2015-09-11 18:47 GMT+02:00 Adam Back <adam at cypherspace.org>:
> Bitcoin security depends on the enforcement of consensus rules which
> is done by economically dependent full nodes. This is distinct from
> miners fullnodes, and balances miners interests, otherwise SPV nodes
> and decentralisation of policy would tend degrade, I think. Therefore
> it is important that it be reasonably convenient to run full nodes for
> decentralisation security.
>
> Also you may want to read this summary of Bitcoin decentralisation by Mark:
>
>
> https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3
>
> I think you maybe misunderstanding what the Chinese miners said also,
> about 8MB, that was a cap on the maximum they felt they could handle
> with current network infrastructure.
>
> I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once
> the hard-fork is upgraded by everyone in the network. (I dont
> consider miner triggers, as with soft-fork upgrades, to be an
> appropriate roll out mechanism because it is more important that
> economically dependent full nodes upgrade, though it can be useful to
> know that miners also have upgraded to a reasonable extent to avoid a
> temporary hashrate drop off affecting security).
>
> Adam
>
> On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think the overlap of people who want to run a serious mining operation
> and
> > people who are unable to afford a slightly above average internet
> connection
> > is infinitesimally small.
> >
> > 2015-09-09 20:51 GMT+02:00 Jorge Timón <jtimon at jtimon.cc>:
> >>
> >>
> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev"
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> >
> >> > I propose to:
> >> >
> >> > a) assess what blocklimit is currently technically possible without
> >> > driving up costs of running a node up too much. Most systems currently
> >> > running a fullnode probably have some capacity left.
> >>
> >> What about the risk of further increasing mining centralization?
> >
> >
> >
> > _______________________________________________
> > 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/20150911/e31daa59/attachment.html>

2023-06-07 17:39:53

- reply

📅 Original date posted:2015-09-09
📝 Original message:I think the overlap of people who want to run a serious mining operation
and people who are unable to afford a slightly above average internet
connection is infinitesimally small.
2015-09-09 20:51 GMT+02:00 Jorge Timón <jtimon at jtimon.cc>:
>
> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > I propose to:
> >
> > a) assess what blocklimit is currently technically possible without
> driving up costs of running a node up too much. Most systems currently
> running a fullnode probably have some capacity left.
>
> What about the risk of further increasing mining centralization?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150909/67a529ec/attachment.html>

2023-06-07 17:39:53

- reply

📅 Original date posted:2015-09-09
📝 Original message:I propose to:
a) assess what blocklimit is currently technically possible without driving
up costs of running a node up too much. Most systems currently running a
fullnode probably have some capacity left.
b) set the determined blocklimit at the next reward halving
c) then double the blocksize limit at every halving thereafter up to a
hardlimit of 8GB.
Reasoning:
Doubling every four years will stay within expected technological growth.
Cisco's VNI forecast predicts a 2.1-fold increase in global average fixed
broadand speed from 2014 to 2019. Nielsen's law, which looks more at the
power user (probably more fitting) is even more optimistic with +50% per
year.
This proposal can be considered a compromise between Pieter's and Gavin's
proposals. While the growth rate is more or less what Pieter proposes, it
includes an initial increase to kickstart the growth. If we start with 8MB,
which seems to be popular among miners, we would reach 8GB in 2056 (as
opposed to 2036 in BIP101). The start date (ca. mid 2016) is also a
compromise between Pieter's 01/2017 and Gavin's 01/2016.
It's simple, predictable and IMHO elegant -- block subsidy halves,
blocksize limit doubles.
It might make sense to update the limit more often in between, though.
Either completely linearly based on a block's timestamp like in BIP101, or
for example for each difficulty period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150909/4e5271e9/attachment.html>

2023-06-07 17:36:38

- reply

📅 Original date posted:2015-08-18
📝 Original message:I'm going to list a few assumtions / observations / understandings around
this debate. Please point out the incorrect ones.
* Most developers here agree that 1 MB is not a magic constant and that the
limit has to increase eventually.
* Most developers want to reduce the amount of policy decisions
bitcoin-core makes as much as possible.
* The most conservative option for the 4 billion dollar system that is
bitcoin is to keep the limit.
* Technological growth in bandwidth, cpu and storage exists and relative to
that growth, the blocksize limit is effectively decreased. Keeping the
limit as it is today, or was five years ago, means we need to adjust for
technological growth.
* Doing so will not reduce current decentralization, however measured.
* Increasing the blocksize limit will always require a hard-fork.
Decreasing, or stopping the growth of the blocksize limit will always be
possible via soft-fork.
* Problems arising from underestimating the need for a larger blocksize
limit are increasingly harder to fix. Problems arising from a limit that is
getting too high are more easy to fix.
* This means we can be optimistic when estimating future technological
growth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/c30bf53a/attachment.html>

2023-06-07 17:35:44

- reply

📅 Original date posted:2015-08-17
📝 Original message:His account on that website was also compromised.
2015-08-17 21:02 GMT+02:00 Anon Moto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Satoshi,
>
> As much as I want to believe this is you it's very difficult to ignore the
> fact that Vistomail could have been hacked and I'm currently speaking to a
> troll.
> Can you copy and paste what you wrote above, to
> http://p2pfoundation.ning.com as well, like how you did during the Dorian
> fiasco?
>
>
> Much appreciated.
>
>
> On Sat, Aug 15, 2015 at 10:43 AM, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have been following the recent block size debates through the mailing
>> list. I had hoped the debate would resolve and that a fork proposal would
>> achieve widespread consensus. However with the formal release of Bitcoin
>> XT 0.11A, this looks unlikely to happen, and so I am forced to share my
>> concerns about this very dangerous fork.
>>
>> The developers of this pretender-Bitcoin claim to be following my
>> original vision, but nothing could be further from the truth. When I
>> designed Bitcoin, I designed it in such a way as to make future
>> modifications to the consensus rules difficult without near unanimous
>> agreement. Bitcoin was designed to be protected from the influence of
>> charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or
>> Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have
>> to do it without being forced or pressured into it. By doing a fork in
>> this way, these developers are violating the "original vision" they claim
>> to honour.
>>
>> They use my old writings to make claims about what Bitcoin was supposed
>> to be. However I acknowledge that a lot has changed since that time, and
>> new knowledge has been gained that contradicts some of my early opinions.
>> For example I didn't anticipate pooled mining and its effects on the
>> security of the network. Making Bitcoin a competitive monetary system
>> while also preserving its security properties is not a trivial problem, and
>> we should take more time to come up with a robust solution. I suspect we
>> need a better incentive for users to run nodes instead of relying solely on
>> altruism.
>>
>> If two developers can fork Bitcoin and succeed in redefining what
>> "Bitcoin" is, in the face of widespread technical criticism and through the
>> use of populist tactics, then I will have no choice but to declare Bitcoin
>> a failed project. Bitcoin was meant to be both technically and socially
>> robust. This present situation has been very disappointing to watch unfold.
>>
>> 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/20150817/cb0411d3/attachment-0001.html>

2023-06-07 17:34:49

- reply

📅 Original date posted:2015-08-14
📝 Original message:In that case it didn't remedy the problem of constantly full blocks, but
got a ton of people on board the bitcoin train in the meanwhile. And with
them more interest, investments, research and ideas.
In the case we increase the limit and no government or banking group
immediately uses up all the space in blocks, it of course would prevent
constantly full blocks for the time being. Bitcoin keeps working reliably,
is fast and cheap -- more users on board the bitcoin train. And as long as
we do not immediately increase it to 1.6GB (something no one is
suggesting), we could still maintain a good level of decentralization,
maybe even increase it together with an increase in users.
Eventually we'll have to deal with the fading subsidy, but there's no
reason to deal with it at this point in time. What we need today is more
users and artifically limiting the blocksize doesn't help with that. At the
very least we should try to incorporate technological growth into bitcoin.
Keep the 2010 1MB limit, but account for "inflation". If you're arguing
that noone can predict the future development of bandwidth, cpu and storage
I'd say it doesn't matter if we are too optimistic, because when we start
seeing that a future doubling of the limit will cause major issues, it will
be easy to find consensus and change the rule accordingly.
2015-08-14 4:26 GMT+02:00 Venzen Khaosan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Geir,
>
> In the scenario below, you argue that the current 1MB limit would lead
> to "constantly full" blocks. If the limit is increased to say 1.6GB
> then a government or banking group may choose to utilize 1.5GB of the
> capacity of each block (and pay fees or not) for their settlement
> network. Then how did upping the blocksize remedy anything? Or is this
> use-case not plausible?
>
> I would like to ask you, or anyone on the list: when we say that
> mining secures the network, what does that mean?
>
>
>
> On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote:
> > 3) A few more people begin using bitcoin. Bitcoin buckles and
> > dies.
> >
> > - Something happens a few months from now causing an influx of new
> > users and more transactions. - Blocks are constantly full. - A
> > backlog of transactions keeps growing indefinitely. - At first
> > people say "bitcoin is slow". After a while they say "bitcoin
> > doesn't work". - Changing the hard limit on block size requires a
> > fork and takes too long. - As bitcoin no longer works people stop
> > using it. - Bitcoin lives out the last of its days in the
> > backwaters of the internet with only 5 users. They keep telling
> > people "we increased the block size now". Unfortunately noone is
> > listening anymore. - People laugh at you and say "I told you that
> > buttcoin thing was doomed to fail. After all it wasn't real
> > money."
> >
> > If the hard limit had been increased earlier then mining pools
> > would have been able to react quickly by upping their own soft
> > limit. But this was not the case and so ended Bitcoin.
> >
> > So in summary:
> >
> > By increasing the block size limit you run the risk of: - The
> > transaction fee market takes a little longer to develop. By not
> > increasing the limit you run the risk of: - Bitcoin dies. The end.
> >
> > Transaction fees should not be the main topic of this discussion,
> > and probably not even a part of it at all. That seems outright
> > irresponsible to me.
> >
> > Regards, Geir H. Hansen, Bitminter mining pool
> >
> > On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
> >> I believe all concerns I've read can be classified in the
> >> following groups:
> >>
> >>> 1) Potential indirect consequence of rising fees.
> >>
> >> - Lowest fee transactions (currently free transactions) will
> >> become more unreliable. - People will migrate to competing
> >> systems (PoW altcoins) with lower fees.
> >>
> >>> 2) Software problem independent of a concrete block size that
> >>> needs to be solved anyway, often specific to Bitcoin Core (ie
> >>> other implementations, say libbitcoin may not necessarily share
> >>> these problems).
> >>
> >> - Bitcoin Core's mempool is unbounded in size and can make the
> >> program crash by using too much memory. - There's no good way to
> >> increase the fee of a transaction that is taking too long to be
> >> mined without the "double spending" transaction with the higher
> >> fee being blocked by most nodes which follow Bitcoin Core's
> >> default policy for conflicting spends replacements (aka "first
> >> seen" replacement policy).
> >>
> >> I have started with the 3 concerns that I read more often, but
> >> please suggest more concerns for these categories and suggest
> >> other categories if you think there's more.
> >> _______________________________________________ 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
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVzVHWAAoJEGwAhlQc8H1myaoH+QFo+eTqPqMps/h/Lt5P4Ker
> UIyCbouatdrRnKqJlpa+dy70+nK+nkz6fizXLC8fuWFDLPQ2uk1cUnp7FPcJ+f6L
> LdGiUktcF/osbA5DW/Xt1DQnClnfbR04oH3+l5ouwhTG2FL8018RQKTAZXYaQafE
> /GUzXBZt+dxpENE2ZE0YDORcm62cysFB8KiqS7NmrNC3sig/Bnw0k8x8y745LcSO
> j/icLJ/zlSVhtceb8AnSg5bC2xhKXrTsGQBfr4foDh78n0+xcbEQO/6xc29rydeB
> l8VwzqCwyFZScM/4lhgYHgEB2KE3MecGNy0vh7jKVqh9lQUMlWtpHRy/Nony5mA=
> =MEzL
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150814/5899a173/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-31
📝 Original message:> Quite possibly bigger blocks == more users == more nodes and more miners.
I agree and would say that this is the only prediction of bitcoin's future
we can be absolutely sure of: more users equals more decentralization as
long as the cost of running a node is not prohibitively high.
It's incredibly cheap today and won't be too high with any of the current
proposals for the time being. If the "laws" of Nielsen & co suddenly don't
apply anymore, we can always react to that with another hardfork reducing
the rate of growth. Hardforks are way easier if the network is in danger
and the necessary change is obvious and non-controversial (e.g. "reduce
blocksize limit growth").
As long as hobbyists can participate in running the network and it's
affordable for everyone to transact on it, bitcoin will grow and its
decentralization with it, however you measure it.
2015-07-31 14:15 GMT+02:00 Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Hey Jorge,
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
>
> To repeat: it's not obvious to me at all that everything wrong with
> Bitcoin can be solved by shrinking blocks. I don't think that's going to
> suddenly make everything magically more decentralised.
>
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be
> high enough to ensure organic growth is not constrained, which is good
> enough.
>
> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the
> source code.
>
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
>
> None of these factors have anything to do with traffic levels.
>
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
>
> > So why should anyone go through the massive hassle of setting up
>> exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed
>> to maximize the profits of Bitcoin exchanges?
>>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The
> motivation is profit, and profits are higher when there are more users to
> sell to. This is business 101.
>
> If you remove the potential for future profit, you remove the motivation
> to create the services that we now enjoy and take for granted. Because if
> you think Bitcoin can be useful without exchanges then let me tell you, I
> was around when there were none. Bitcoin was useless.
>
> _______________________________________________
> 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/20150731/1e4a3fc2/attachment-0001.html>

2023-06-07 15:43:19

- reply

📅 Original date posted:2015-07-23
📝 Original message:He measured the upload capacity of the peers by downloading from them, or
am I being dumb? :)
2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >This does not support the theory that the network has the available
> >bandwidth for increased block sizes, as in its current state 37% of
> >nodes would fail to upload a 20MB block to a single peer in under 20
> >seconds (referencing a number quoted by Gavin). If the bar for
> >suitability is placed at taking only 1% of the block time (6 seconds)
> >to upload one block to one peer, then 69% of the network fails for 20MB
> >blocks. For comparison, only 10% fail this metric for 1MB blocks.
>
> Note how due to bandwidth being generally asymetric your findings are
> probably optimistic - you've measured download capacity. On top of that
> upload is further reduced by the fact that multiple peers at once need to
> be sent blocks for reliability.
>
> Secondly you're measuring a network that isn't under attack - we need
> significant additional margin to resist attack as performance is
> consensus-critical.
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsRCj
> AAoJEMCF8hzn9Lnc47AIAIQbznavjd2Rbqxeq5a3GLqeYoI4BZIQYqfWky+6OQtq
> yGRKaqPtGuES5y9L0k7efivT385mOl87PWnWMy61xxZ9FJgoS+YHkEx8K4tfgfA2
> yLOKzeFSar2ROCcjHYyPWa2XXjRbNmiLzfNuQyIBArg/Ch9//iXUUM+GG0mChF5k
> nUxLstXgXDNh5H8xkHeLi4lEbt9HFiwcZnT1Tzeo2dvVTujrtyNb/zEhNZScMXDc
> UOlT8rBLxzHlytKdXt1GNKIq0feTRJNbreBh7/EB4nYTT54CItaaVXul0LdHd5/2
> kgKtdbUdeyaRUKrKcvxiuIwclyoOuRQp0DZThsB262o=
> =tBUM
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20150723/a4aa2bc7/attachment.html>

2023-06-07 15:38:49

- reply

📅 Original date posted:2015-06-19
📝 Original message:> At the risk of stating cliches, the Mac came before the Windows PC…Yahoo!
came before Google…MySpace came before Facebook…
And TCP/IP came before... oh wait...
2015-06-19 14:02 GMT+02:00 Eric Lombrozo <elombrozo at gmail.com>:
>
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam at cypherspace.org> wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon. They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
>
>
> Exactly, Adam.
>
> Except, I think the genie is out of the bottle - these ideas are too
> powerful for them to be killed forever. They will probably survive even if
> this scenario comes to pass…but in a different network under a different
> name…and Bitcoin will be relegated to the history books and walls of
> museums.
>
> Most of the potential brainpower available on this Earth to make serious,
> profound contributions to this movement haven’t even begun to touch it.
> Just because you happen to run a Bitcoin startup right now…even if you’ve
> received millions of dollars in funding…don’t think that the whole world
> has low standards and is lazy! Someone WILL eventually build something
> better than we can presently imagine.
>
> First mover advantage and the network effect are vastly overrated. At the
> risk of stating cliches, the Mac came before the Windows PC…Yahoo! came
> before Google…MySpace came before Facebook…Bitcoin came before <we don’t
> know yet>.
>
>
> - Eric Lombrozo
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150619/78d7b5cf/attachment.html>

2023-06-07 15:38:20

- reply

📅 Original date posted:2015-06-16
📝 Original message:> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.
Neither do you or anyone else.
> There is protocol for how change is effected in a FOSS project.
And it allows the minority to hold the majority hostage.
> If you take the risks with Mike&GavCoin, that would be fine, but you are
about to take them with community-owned Bitcoin and Other People's Money!
The same can be said about the other camp.
BitcoinXT is not going to fork the chain on a specific date no matter what.
People will be able to vote via block versions and once a sufficient
majority supports the extensions, everyone else will have a grace period to
upgrade. Only after that is a very small minority at risk of losing money.
That being said, I'd rather see a solution that everyone agrees on. My
personal opinion/hope is that Mike and Gavin are just applying pressure
where it's needed. But in the end, they can do whatever they want if they
have the necessary support. Permissionless innovation is one of bitcoins
virtues. In the end, only adoption will decide what bitcoin is and isn't.
2015-06-16 7:18 GMT+02:00 Venzen <venzen at mail.bihthai.net>:
> Mike Hearn,
>
> In the light of your responses to Adam Back's questions, below, I feel
> it is time to speak up because what I now understand, and is implied,
> is that Mike Hearn and Gavin Andresen have planned and deployed the
> infrastructure for a Bitcoin hard-fork and intend to action it despite
> majority opposition. http://xtnodes.com/
>
> I'll try to keep it brief:
>
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus. Your actions are bad for the
> Bitcoin project and its ideals, disrespectful of your peers and years
> of their passionate hard work, and dangerous for Bitcoin in the
> marketplace and bitcoin in peoples' wallets.
>
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it. Your hard-fork is tantamount to theft and you and
> your collaborators will effectively ex-communicate yourselves from
> this project and community. It appears that you are consciously trying
> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
> You clearly do not comprehend the array of risks - especially the
> unanticipated ones. As the market saying goes: "If you think
> speculation is easy, it is because you are ignorant about the risks".
> If you take the risks with Mike&GavCoin, that would be fine, but you
> are about to take them with community-owned Bitcoin and Other People's
> Money!
>
> You are causing a lot of stress, unnecessarily, and grave concern
> surrounds your proposed renegade action. You can dissolve the threat:
> those players to whom you have made promises can be appeased and
> eventually get most of what they need from this FOSS project. The
> developers whom you are railroading to get your way, and the way in
> which you are doing it, is about to cause a schism that will expand
> outward from this community.
>
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
> If an individual in an objectively agreed-to FOSS-modelled
> collaborative project has the audacity to threaten his peers and the
> world with a unilateral hard-fork despite majority objection and a
> probability distribution that includes terminal risks and unintended
> consequences, then what would an impartial outsider think? Some of
> their thoughts would include that the antagonist could be acting in
> self-interest, or may be a paid actor, or worse, a saboteur. What
> would they advise? Stop that individual, at once!
>
> Bitcoin is a Free and Open Source Software project that serves as
> flagship for the blockchain. It has a payment network but the key
> benefits are censorship resistance and trustless decentralization.
> There is protocol for how change is effected in a FOSS project. For
> the sake of everything that is good and useful in Bitcoin, reconsider
> your dangerous plan and its intended and unintended consequences. Put
> your feet back on the ground, return to the fold and let the
> collaborative FOSS model, and the skills available here, gradually
> scale Bitcoin to your (and all our) grand vision.
>
> Venzen Khaosan
>
>
> On 06/15/2015 04:56 PM, Mike Hearn wrote:
> > Hi Adam,
> >
> > Provisional answers below!
> >
> > - Are you releasing a BIP for that proposal for review?
> >
> >
> > The work splits like this:
> >
> > * Gavin is writing the code and I think a BIP as well
> >
> > * I will review both and mostly delegate to Gavin's good taste
> > around the details, unless there is some very strong disagreement.
> > But that seems unlikely.
> >
> > * I have been handling gitian and the patch rebases, the code
> > signing and so on, so far. I've also been doing some work to setup
> > the basic infrastructure of the project (website etc).
> >
> >
> > - If the reviewers all say NACK will you take on board their
> > suggestions?
> >
> >
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> > requests aren't scored in any way. The final decision rests with
> > the maintainer as in ~all open source projects.
> >
> >
> >
> > - On the idea of a non-consensus hard-fork at all, I think we can
> > assume you will get a row of NACKs. Can you explain your
> > rationale for going ahead anyway? The risks are well understood
> > and enormous.
> >
> >
> > Yes, I have been working on an article that explains how we got to
> > this point from my perspective. It is quite long, but only because
> > I want it to be readable for people who weren't following the
> > debate.
> >
> > Anyway, I think I've laid out the gist of it over and over again,
> > but to summarise:
> >
> > If Bitcoin runs out of capacity *it will break and many of our
> > users will leave*. That is not an acceptable outcome for myself or
> > the many other wallet, service and merchant developers who have
> > worked for years to build an ecosystem around this protocol.
> >
> >
> >
> > - How do you propose to deal with the extra risks that come from
> > non-consensus hard-forks? Hard-forks themselves are quite risky,
> > but non-consensus ones are extremely dangerous for consensus.
> >
> >
> > The approach is the same for other forks. Voting via block versions
> > and then when there's been >X% for Y time units the 1mb limit is
> > lifted/replaced.
> >
> >
> >
> >
> > - If you're going it alone as it were, are you proposing that you
> > will personally maintain bitcoin-XT? Or do you have a plan to
> > later hand over maintenance to the bitcoin developers?
> >
> >
> > Good question! I have various thoughts on this, but let's wait and
> > see what happens first. Perhaps the new chain won't get the
> > majority on it.
> >
> > In the event that the >1mb chain does eventually win, I would
> > expect Core to apply the patch and rejoin the consensus rather than
> > lose all its users. That would take XT back to being a fairly small
> > patchset to improve the network protocol.
> >
> >
> >
> > - Do you have contingency plans for what to do if the
> > non-consensus hard-fork goes wrong and $3B is lost as a result?
> >
> >
> > Where did you get the $3B figure from? The fork either doesn't
> > happen, or it happens after quite a long period of people knowing
> > it's going to happen - for example because their full node is
> > printing "You need to upgrade" messages due to seeing the larger
> > block version, or because they read the news, or because they heard
> > about it via some other mechanisms.
> >
> > Let me flip the question around. Do you have a contingency plan if
> > Bitcoin runs out of capacity and significant user disruption occurs
> > that results in exodus, followed by fall in BTC price? The only one
> > I've seen is "we can perform an emergency hard fork in a few
> > weeks"!
> >
> >
> >
> > As you can probably tell I think a unilateral fork without
> > wide-scale consensus from the technical and business communities is
> > a deeply inadvisable.
> >
> >
> > Gavin and I have been polling many key players in the ecosystem.
> > The consensus you seek does exist. All wallet developers (except
> > Lawrence), all the major exchanges, all the major payment
> > processors and many of the major mining pools want to see the limit
> > lifted (I haven't been talking to pools, Gavin has).
> >
> > This notion that the change has no consensus is based on you
> > polling the people directly around you and people who like to spend
> > all day on this mailing list. It's not an accurate reflection of
> > the wider Bitcoin community and that is one of the leading reasons
> > there is going to be a fork. A small number of people have been
> > flatly ignoring LOTS of highly technical and passionate developers
> > who have written vast amounts of code, built up the Bitcoin user
> > base, designed hardware and software, and yes built companies.
> >
> > How do you think that makes Bitcoin Core look to the rest of the
> > Bitcoin world? How much confidence does that give people?
> >
> >
> >
> > Of the overall process, I think you can agree we should not be
> > making technical decisions with this level of complexity and
> > consensus risk with financial implications of this magnitude under
> > duress of haste?
> >
> >
> > This debate will never end until a fork makes it irrelevant. There
> > is no process for ending it, despite me begging Wladimir to make
> > one.
> >
> > And there is no haste. We have been debating the block size limit
> > for _years_. We have known it must be lifted for _years_. I kicked
> > off this current round of debates after realising that Wladimir's
> > release timeline wouldn't allow a block size limit to be released
> > before the end of the year. The reason we're talking about it now
> > and not next year is exactly to ensure there is plenty of time.
> >
> >
> >
> >
> > I can sincerely assure you everyone does want to scale bitcoin and
> > shares your long term objective on that
> >
> >
> > I really wish you were right, and I definitely feel you are one of
> > the more reasonable ones Adam. But the overwhelming impression I
> > get from a few others here is that no, they don't want to scale
> > Bitcoin. They already decided it's a technological dead end. They
> > want to kick end users out in order to "incentivise" (force) the
> > creation of some other alternative, claiming that it's still
> > Bitcoin whilst ignoring basic details ... like the fact that no
> > existing wallets or services would work.
> >
> > Scaling Bitcoin can only be achieved by letting it grow, and
> > letting people tackle each bottleneck as it arises at the right
> > times. Not by convincing ourselves that success is failure.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________ Bitcoin-development
> > mailing list Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150616/5f789e97/attachment.html>

2023-06-07 15:36:11

- reply

📅 Original date posted:2015-06-01
📝 Original message:> Let the block size limit be a function of the number of current transactions
in the mempool.
There is no single mempool which transactions could be counted and there is
no consensus about the average number of unconfirmed transactions.
2015-06-01 13:30 GMT+02:00 Ricardo Filipe <ricardojdfilipe at gmail.com>:
> I've been following the discussion of the block size limit and IMO it
> is clear that any constant block size limit is, as many have said
> before, just kicking the can down the road.
> My problem with the dynamic lower limit solution based on past blocks
> is that it doesn't account for usage spikes. I would like to propose
> another dynamic lower limit scheme:
> Let the block size limit be a function of the number of current
> transactions in the mempool. This way, bitcoin usage regulates the
> block size limit.
>
> I'm sorry i don't have the knowledge of the code base or time to make
> simulations on this kind of approach, but nevertheless I would like to
> leave it here for discussion or foster other ideas.
>
> cheers
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150601/7027163a/attachment.html>