Jameson Lopp [ARCHIVE]

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

Public Key

npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmn

Profile Code

nprofile1qqsyt5y3c77dhwr8fhytj8rq7uerq5atzsevfjyzl5ke39l72qhwhmgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgdwaehxw309ahx7uewd3hkcf8kq7n

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Author Public Key

npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmn

Show more details

Last Notes

2023-06-07 18:10:46 UTC

- reply

📅 Original date posted:2018-02-13
📝 Original message:If I'm understanding the problem being stated correctly:
"Bitcoin is under a branding attack by fork coins."
The proposed solution is to disincentivize fork coins from using the word
Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me
that the words of the license are basically useless unless there is an
entity that intends to make use of court systems to threaten noncompliant
projects into submission.
In my opinion, the perceived attack on Bitcoin here is social /
marketing-based, thus it makes sense that any defense against said attack
should also be social / marketing-based. I don't think that Bitcoin should
be reliant upon courts or governments to defend itself against attacks of
any form.
On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES
> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS
> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
> (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the trademark
> holder - Satoshi?)
>
> This would also prohibit any reimplementation that's not formally verified
> to be perfectly compatible from using the name.
>
> It also adds legal uncertainty.
>
> Another major problem is that it neither affects anybody forking older
> versions of Bitcoin, not people using existing independent blockchain
> implementations and renaming them Bitcoin-Whatsoever.
>
> And what happens when an old version is technically incompatible with a
> future version by the Core team due to not understanding various new
> softforks? Which version wins the right to the name?
>
> Also, being unable to even mention Bitcoin is overkill.
>
> The software license also don't affect the blockchain data.
>
>
> _______________________________________________
> 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/20180213/6b606fdf/attachment.html>

2023-06-07 17:57:56 UTC

- reply

📅 Original date posted:2017-03-27
📝 Original message:Bitcoin chooses the "best chain" based upon the one that has the most
cumulative proof of work behind it. Are you proposing that the cumulative
proof of work be ignored if two blocks are within a certain threshold of
each others' work and if so, the number of transactions in the block / the
size of the block should be used as a "tie breaker?"
I think this idea needs more fleshing out of exactly how it would work,
with careful consideration that adding complexity to the best chain logic
could introduce exploitable flaws.
On Mon, Mar 27, 2017 at 12:12 PM, Btc Ideas via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The first
> good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
>
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.
>
> I read some miners could attack a chain by mining small or empty blocks.
> This makes that a little more difficult, but they can still attack the
> chain many ways.
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
> _______________________________________________
> 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/20170327/70b5a851/attachment.html>

2023-06-07 17:54:18 UTC

- reply

📅 Original date posted:2016-11-16
📝 Original message:Since "buried deployments" are specifically in reference to historical
consensus changes, I think the question is more one of human consensus than
machine consensus. Is there any disagreement amongst Bitcoin users that
BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66
activated at block 363725? Somehow I doubt it.
It seems to me that this change is merely cementing into place a few
attributes of the blockchain's history that are not in dispute.
- Jameson
On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Actually this does nothing to provide justification for this consensus
> rule change. It is just an attempt to deflect criticism from the fact that
> it is such a change.
>
> e
>
> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com> wrote:
> >
> > I think this is already covered in the BIP text:-
> >
> > "As of November 2016, the most recent of these changes (BIP 65,
> > enforced since December 2015) has nearly 50,000 blocks built on top of
> > it. The occurrence of such a reorg that would cause the activating
> > block to be disconnected would raise fundamental concerns about the
> > security assumptions of Bitcoin, a far bigger issue than any
> > non-backwards compatible change.
> >
> > So while this proposal could theoretically result in a consensus
> > split, it is extremely unlikely, and in particular any such
> > circumstances would be sufficiently damaging to the Bitcoin network to
> > dwarf any concerns about the effects of this proposed change."
> >
> >
> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> NACK
> >>
> >> Horrible precedent (hardcoding rule changes based on the assumption that
> >> large forks indicate a catastrophic failure), extremely poor process
> >> (already shipped, now the discussion), and not even a material
> performance
> >> optimization (the checks are avoidable once activated until a
> sufficiently
> >> deep reorg deactivates them).
> >>
> >> e
> >>
> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Hi,
> >>
> >> Recently Bitcoin Core merged a simplification to the consensus rules
> >> surrounding deployment of BIPs 34, 66, and 65
> >> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change
> is a
> >> minor one, I thought it was worth documenting the rationale in a BIP for
> >> posterity.
> >>
> >> Here's the abstract:
> >>
> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> >> signaling in block version numbers. Now that the chain has long since
> passed
> >> the blocks at which those consensus rules have triggered, we can (as a
> >> simplification and optimization) replace the trigger mechanism by
> caching
> >> the block heights at which those consensus rules became enforced.
> >>
> >> The full draft can be found here:
> >>
> >> https://github.com/sdaftuar/bips/blob/buried-deployments/
> bip-buried-deployments.mediawiki
> >>
> >> _______________________________________________
> >> 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/20161116/fbdc0efa/attachment.html>

2023-06-07 17:46:31 UTC

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
>
>
Over a year seems to be an extraordinarily long time frame is for deploying
a hard fork. It looks like <https://bitnodes.21.co/dashboard/?days=365> 75%
of reachable nodes have upgraded in the past 6 months while as much as 25%
may not have been upgraded in over a year. However, viewing historical
stats of version upgrades doesn't seem to be an appropriate comparison
because node operators have never been faced with the same incentive to
upgrade. We can point to unintentional forks in the past that have been
resolved fairly quickly by reaching out to miners, but it's also a poor
comparison. Unfortunately, we have no way of knowing what percentage of
nodes are economically important - a great deal of them may be running and
not even be used by the operators.
Perhaps it would be better if we were to formalize the expectations for
full node operators, but it seems to me that node operators have a
responsibility to keep themselves informed and decide when it is
appropriate to update their software. I'm not so sure that it's the rest of
the ecosystem's responsibility to wait around for laggards.
- Jameson
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/20151216/3bfa78f6/attachment-0001.html>

2023-06-07 17:46:20 UTC

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1: Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3: If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>
Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.
I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.
A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.
> --
> Pieter
> _______________________________________________
> 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/20151216/ba83fcba/attachment.html>

2023-06-07 17:33:27 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message:Anecdotally I've seen two primary reasons posed for not running a node:
1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
configuration option in bitcoind and a slider / selector in the QT client
to throttle the total bandwidth usage. This issue has been open for years:
https://github.com/bitcoin/bitcoin/issues/273 - if you want to make it
easier for enthusiasts to run nodes, I'd start there.
2) For businesses, it's not so much an issue with the resources of
installing / running / maintaining a node, it's an issue with the lack of
indexing options offered by bitcoind. Thus the business will also need to
run their own indexing solution - an out-of-the-box solution such as
Insight or Toshi might work, but for more custom indexing you have to roll
your own software - this is where it actually becomes expensive.
Depending upon the query volume / latency needs of the business, it may not
make sense to bother administering bitcoind instances, the indexing
software, and its databases - using a third party API will probably be more
efficient.
- Jameson
On Fri, Aug 7, 2015 at 1:50 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> If the incentives for running a node don't weight up against the
>> cost/difficulty using a full node yourself for a majority of people in the
>> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
>> improvement over other systems is the lack of need for trust, I believe
>> that with increased adoption should also come an increased (in absolute
>> terms) incentive for people to use a full node. I'm seeing the opposite
>> trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
> to trust nothing but the genesis block hash (decide to run a full node)
> there is a problem?
>
> If so, then we do have a fundamental difference of opinion, but I've
> misunderstood how you think about trust/centralization/convenience
> tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeoffs,
> and I believe that is OK-- people should be free to make those tradeoffs.
>
> And given that the majority of people in the ecosystem were deciding that
> using a centralized service or an SPV-level-security wallet was better even
> two or three years ago when blocks were tiny (I'd have to go back and dig
> up number-of-full-nodes and number-of-active-wallets at the big web-wallet
> providers, but I bet there were an order of magnitude more people using
> centralized services than running full nodes even back then), I firmly
> believe that block size has very little to do with the decision to run a
> full node or not.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150807/312ab280/attachment-0001.html>

2023-06-07 15:45:35 UTC

- reply

2023-06-07 15:44:15 UTC

- reply

📅 Original date posted:2015-07-30
📝 Original message:I fully expect that new layers will someday allow us to facilitate higher
transaction volumes, though I'm concerned about the current state of the
network and the fact that there are no concrete timelines for the rollout
of aforementioned high volume networks.
As for reasoning behind why users will still need to settle on-chain even
with the existence of high volume networks, see these posts:
http://sourceforge.net/p/bitcoin/mailman/message/34119233/
http://sourceforge.net/p/bitcoin/mailman/message/34113067/
Point being, the scalability proposals that are currently being developed
are not magic bullets and still require the occasional on-chain settlement.
Larger blocks will be necessary with or without the actual scalability
enhancements.
- Jameson
On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Stated differently, if the cost or contention of using the network rises
>> to the point of excluding the average user from making transactions, then
>> they probably aren't going to care that they can run a node at trivial cost.
>
>
> That's an interesting claim; so suppose you're living in a future where
> transactions are summarizing millions or billions of other daily
> transactions, possibly with merkle hashes. You think that because a user
> can't individually broadcast his own personal transaction, that the user
> would not be interested in verifying the presence of a summarizing
> transaction in the blockchain? I'm just curious if you could elaborate on
> this effect. Why would I need to see my individual transactions on the
> network, but not see aggregate transactions that include my own?
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/b38ccb0a/attachment.html>

2023-06-07 15:44:14 UTC

- reply

📅 Original date posted:2015-07-30
📝 Original message:I find it to be an admirable goal to try to keep node operation costs low
and accessible to the average user. On the other hand, if we are able to
keep the resource requirements of nodes at the level of, say, whatever the
latest Raspberry Pi model on a residential Internet connection can handle,
I'm not sure how helpful it will be if the demand for inclusion in blocks
results in transaction fees prices out more users. Stated differently, if
the cost or contention of using the network rises to the point of excluding
the average user from making transactions, then they probably aren't going
to care that they can run a node at trivial cost.
If we're approaching the block size from a resource usage standpoint, it
seems to me that someone is going to be excluded one way or another. Not
raising the block size will exclude some users from sending transactions
while raising the block size will exclude some users from running nodes.
The latter seems preferable to me because more users will grow the
ecosystem, which should increase the value of the ecosystem, which should
increase the cost that entities are willing to pay to run nodes.
I see two primary points of view / objectives clashing in this debate:
1) Decentralization and stability even if it retards growth of the ecosystem
2) Push the system's load as far as we are comfortable in order to
accommodate the growth it is experiencing
It's clear to me that Core developers have a responsibility to maintain a
stable platform for the ecosystem. I think it's less clear that they have a
responsibility to grow it or ask node operators to expend more resources in
order to support more users. As an operator of several nodes, I can
anecdotally state that I find their resource usage to be trivial and I
welcome more load.
- Jameson
On Thu, Jul 30, 2015 at 11:12 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 1) Unlike previous blocksize hardfork proposals, this uses median time
> instead of block.nTime for activation. I like that more but my
> preference is still using height for everything. But that discussion
> is not specific to this proposal, so it's better if we discuss that
> for all of them here:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
> 2) I think uncontroversial hardforks should also take miner
> confirmation into account, just like uncontroversial softforks do. We
> cannot make sure other users have upgraded before activating the
> chain, but we can know whether miners have upgraded or not. Having
> that tool available, why not use it. Of course other hardforks may not
> care about miners' upgrade state. For example "anti-miner hardforks,
> see
> https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#asic-reset-hardfork
> But again, this is common to all uncontroversial hardforks, so it
> would probably better to discussed it in
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
> (gmaxwell assigned to bip99 to my bip draft).
>
> 3) As commented to you privately, I don't like to make any assumptions
> about technological advancements (much less on economical growth). I
> don't expect many people to agree with me here (I guess I've seen too
> many "peak oil" [or more generally, peak energy production] plus I've
> read Nietzsche's "On the utility and liability of history for life"
> [1]; so considering morals, technology or economics as "monotonic
> functions" in history is simply a ridiculous notion to me), but it's
> undeniable that internet connections have improved overall around the
> world in the last 6 years. I think we should wait for the
> technological improvements to happen and then adapt the blocksize
> accordingly. I know, that's not a "definitive solution", we will need
> to change it from time to time and this is somewhat ugly.
> But even if I'm the only one that considers a "technological
> de-growth" possible, I don't think is wise to rely on pseudo-laws like
> Moore's or Nielsen’s so-called "laws".
> Stealing a quote from another thread:
>
> "Prediction is difficult, especially about the future." - Niels Bohr
>
> So I would prefer a more limited solution like bip102 (even though I
> would prefer to have some simulations leading to a concrete value
> (even if it's bigger) rather than using 2MB's arbitrary number.
>
> Those are my 3 cents.
>
> [1]
> https://philohist.files.wordpress.com/2008/01/nietzsche-uses-history.pdf
>
> On Thu, Jul 30, 2015 at 4:25 PM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hello all,
> >
> > here is a proposal for long-term scalability I've been working on:
> > https://gist.github.com/sipa/c65665fc360ca7a176a6
> >
> > Some things are not included yet, such as a testnet whose size runs
> ahead of
> > the main chain, and the inclusion of Gavin's more accurate sigop checking
> > after the hard fork.
> >
> > Comments?
> >
> > --
> > Pieter
> >
> >
> > _______________________________________________
> > 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/20150730/f352666f/attachment.html>

2023-06-07 15:42:54 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>
Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run their own node (as opposed to
Satoshi's vision of beefy servers in data centers.) My impression is that
even most of these advocates agree that it will be acceptable to eventually
increase block sizes as resources become faster and cheaper because it
won't be 'pricing out' the average user from running their own node. If
this is the case, it seems to me that we have a problem given that there is
no established baseline for the acceptable performance / hardware cost
requirements to run a node. I'd really like to see further clarification
from these advocates around the acceptable cost of running a node and how
we can measure the global reduction in hardware and bandwidth costs in
order to establish a baseline that we can use to justify additional
resource usage by nodes.
- Jameson
>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/9407b8c4/attachment.html>

2023-06-07 15:42:53 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked? (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
>
> Let’s be absolutely clear about one thing - block size increases are *not*
> about scaling the network. Can we please stop promoting this falsehood? It
> doesn’t matter by what number we multiply the block size…we can NEVER
> satisfy the full demand if we insist on every single transaction from every
> single person everywhere in the world being on the blockchain…it’s just
> absurd.
>
>
Increasing block size only temporarily addresses one significant issue -
> how to postpone having to deal with transaction fees, which by design, are
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we’ve all known about from the beginning…so
> please stop claiming otherwise.
>
>
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear. On the flip side, the scalability
proposals will still require larger blocks if we are ever to support
anything close to resembling "mainstream" usage. This is not an either/or
proposition - we clearly need both.
- Jameson
> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There’s been tremendous progress here in addressing scalability,
> yet I don’t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you’re saying, Jorge…but It’s even worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people to
> rely on others to validate for them…and increasing block size only makes
> the problem worse.
>
> - Eric Lombrozo
>
> _______________________________________________
> 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/a658ea27/attachment-0001.html>

2023-06-07 15:40:53 UTC

- reply

📅 Original date posted:2015-06-27
📝 Original message:On Sat, Jun 27, 2015 at 1:34 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 01:25:14PM -0400, Michael Naber wrote:
> > Global network consensus means that there is global network recognition
> > that a particular transaction has occurred and is irreversible. The
> > off-chain solutions you describe, while probably useful for other
> purposes,
> > do not exhibit this characteristic and so they are not global network
> > consensus networks.
>
> Hub-and-spoke payment channels and the Lightning network are not
> off-chain solutions, they are ways to more efficiently use on-chain
> transactions to achive the goal of moving assets from point a to point
> b, resulting in more economic transactions being done with fewer - but
> not zero! - blockchain transactions.
>
> Off-chain transaction systems such as Changetip allow economic
> transactions to happen with no blockchain transactions at all.
>
> > Bitcoin Core scales as O(N), where N is the number of transactions. Can
> we
> > do better than this while still achieving global consensus?
>
> No, Bitcoin the network scales with O(n^2) with your above criteria, as
> each node creates k transactions, thus each node has to verify k*n
> transactions, resulting in O(n^2) total work.
>
> For Bitcoin to have O(n) scaling you have to assume that the number of
> validation nodes doesn't scale with the number of users, thus resulting
> in a system where users trust others to do validation for them. That is
> not a global consensus system; that's a trust-based system.
>
>
Why does it matter what the "total work" of the network is? Anyone who is
participating as a node on the network only cares about the resources
required to run their own node, not the resources everyone else needs to
run their nodes.
Also, no assumption needed, it is quite clear that the number of nodes is
not scaling along with the number of users. If anything it appears to be
inversely proportional.
> There's nothing inherently wrong with that, but why change Bitcoin
> itself into a trust-based system, when you can preserve the global
> consensus functionality, and built a trust-based system on top of it?
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> 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/20150627/62915947/attachment.html>

2023-06-07 15:36:13 UTC

- reply

📅 Original date posted:2015-06-01
📝 Original message:The overlapping consensus mechanisms between the Core Developers, the
miners, the block chain based businesses, and the end users make it such
that the very definition of Bitcoin is not just what any single one of
those groups comes to a consensus about. We must ALL be in consensus about
just what Bitcoin actually is and what its goals should be. As such, the
onus is on the Core Developers to convince the other groups to either
accept or reject major changes to the protocol.
Greg made a great point regarding the difficulty in determining the
definition of Bitcoin:
https://twitter.com/lopp/status/596135982539395073/photo/1
My point being that Bitcoin is inherently a political phenomenon; we're
just trying to describe the human politics behind Bitcoin with computer
code that is reasonably secure against attack.
- Jameson
On Mon, Jun 1, 2015 at 8:55 AM, Mike Hearn <mike at plan99.net> wrote:
> It's surprising to see a core dev going to the public to defend a proposal
>> most other core devs disagree on, and then lobbying the Bitcoin ecosystem.
>>
>
> I agree that it is a waste of time. Many agree. The Bitcoin ecosystem
> doesn't really need lobbying - my experience from talking to businesses and
> wallet developers months ago is they virtually all see raising capacity as
> a no brainer ... and some of them see this "debate" as despair-inducing
> insanity.
>
> What's happened here is that a small number of people have come to believe
> they have veto power over changes to Bitcoin, and they have also become
> *wildly* out of step with what the wider community wants. That cannot
> last. So, short of some sudden change of heart that lets us kick the can
> down the road a bit longer, a fork is inevitable.
>
> Just be glad it's Gavin driving this and not me ... or a faceless
> coalition of startups.
>
>
>> Decentralization is the core of Bitcoin's security model and thus that's
>> what gives Bitcoin its value.
>>
>
> No. Usage is what gives Bitcoin value.
>
> It's kind of maddening that I have to point this out. Decentralisation is
> a means to an end. I first used Bitcoin in April 2009 and it was perfectly
> decentralised back then: every wallet was a full node and every computer
> was capable of mining.
>
> So if you believe what you just wrote, I guess Bitcoin's value has gone
> down every day since.
>
> On the other hand, if you believe the markets, Bitcoin's value has gone up.
>
> Apparently the question of what gives Bitcoin its value is a bit more
> complicated than that.
>
>
>
>
>> : to incentive layer 2 and offchain solutions to scale Bitcoin : there
>> are promising designs/solutions out there (LN, ChainDB, OtherCoin
>> protocole, ...), but most don't get much attention, because there is right
>> now no need for them. And, I am sure new solutions will be invented.
>>
>
> I have seen this notion a few times. I would like to dispose of it right
> now.
>
> I am one of the wallet developers you would be trying to "incentivise" by
> letting Bitcoin break, and I say: get real. Developers are not some
> bottomless fountain of work that will spit out whatever you like for free
> if you twist their arms badly enough.
>
> The problems that incentivised the creation of Bitcoin existed for decades
> before Bitcoin was actually invented. Incentives are not enough. Someone
> has to actually do the work, too. All proposals on the table would:
>
> - Involve enormous amounts of effort from many different people
> - Be technically risky (read: we don't know if they would even work)
> - Not be Bitcoin
>
> The last point is important: people who got interested in Bitcoin and
> decided to devote their time to it might not feel the same way about some
> network of payment hubs or whatever today's fashion is. Faced with their
> work being broken by armchair developers on some mailing list, they might
> just say screw it and walk away completely.
>
> After all, as the arguments for these systems are not particularly
> logical, they might slave over hot keyboards for a year to support the
> Lightning Network or whatever and then discover that it's no longer the
> fashionable thing ... and that suddenly an even more convoluted design is
> being "incentivised".
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/e4b3d878/attachment.html>

2023-06-07 15:21:07 UTC

- reply

📅 Original date posted:2014-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The charts are generated on-demand by Graphite, which is a Django app.
I will note that one reason I chose StatsD is because it sends the stats via UDP rather than TCP, which is a non-blocking operation. I didn't want the sending of stats to affect the node's performance.
- - Jameson
On 05/07/2014 04:18 PM, Wladimir wrote:
> On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I agree that it would be awesome to offer these types of stats with the installer; unfortunately the route I've taken has dependencies on several other other pieces of software to do all the heavy lifting of stats aggregation and chart rendering. I'm assuming that you would not want to build any of that processing into Bitcoin Core itself; would you be opposed to packaging other software along with the installer?
>
> Depends on just how much stuff it is. The idea is primarily to have an
> installer for running a (wallet-less) node as an OS background
> service.
>
> Having some statistics available would be worth some extra download
> size, otherwise it would be pretty much invisible.
>
> We'd already decided that we would need something like Python for the
> stats service. Implementing things like web services in C++ is just
> not realistic given the time constraints and the great already-written
> code that is out there. As an optional tool it should be external, not
> part of bitcoind itself.
>
> I suppose the chart rendering happens client-side? In that case the
> web service just has to collect and provide the data, and serve static
> html/js files.
>
> Wladimir
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTapj5AAoJEIch3FSFNiDcofAIALHi7XgQi8pf75btujaeBsX3
nniRD0yZIkoAvPlvFLiKQGE8TH+VR8Sb9fQACzmajYx1yjD0gN4xvkJXbI+pkeP5
L8ZryhqxL5qCh/OI4+fkWlsp5Nwx89QvUepdXXdc/AQGQJIEMceiZOLDcjbk29Yb
vCsyJL5yhzM9BM0cImuvrOBPtF3/L6DbgHP8OLD2LHRl4paJ1UDtfYCx3HVO9wp8
ZWq1oCaFyoYmUyx8GTUzbLjh9sOgaq43GKYec/kQSLmFxhhMF0dGNDMiwD/xz1i7
LIswjlEKHZYOWWL3SMQg3pLlOTzGH4mHg++BAyrtzZ5CHlc1rjsPSk2d2Df/8Zc=
=GFu9
-----END PGP SIGNATURE-----

2023-06-07 15:21:04 UTC

- reply

📅 Original date posted:2014-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In order to gain more insight into what messages and requests a node is processing, I've created a Bitcoin Core fork that outputs statistics to StatsD. I hope that some of you will find this interesting and potentially useful.
http://coinchomp.com/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/
https://jlopp.github.io/statoshi/
Feedback is appreciated!
- - Jameson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTaoWSAAoJEIch3FSFNiDclLoH/0CXPTum6B2cfoNsacihHuS9
9wt50sOgghttS3J/kloP315ijY7p2HSmhvqL2G/DWYh5Vx0f6gTaUAokQ8H6x4EV
3/pdZG+9a6eegpCtgr+IgphgPSEufzct/Mp7pKTAbH0G61toOM5ZfIgdL2X/2tpx
4TjOmjhZRHuglzsM9934EjezIsR7l2vaRQB0r1LPGSgWmDSKTTb2uK7xvD1zg0tz
QXb0hl7A6rw1xZwmw3i+PujshJCbjVh8QrFT55GYi05yYdBsS6BAG46F5D8Uvn+M
FnCBLdRfWrTzQXIxoLrtBmM1JXOJKdMhmG0p2mwzwXEGR7MR2suS/+Bb7iHJTpA=
=iNNR
-----END PGP SIGNATURE-----

2023-06-07 15:21:04 UTC

- reply

📅 Original date posted:2014-05-07
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The next logical step may be for us to offer a public instance of these graphs; I'd be happy to work with you to set one up.
I agree that it would be awesome to offer these types of stats with the installer; unfortunately the route I've taken has dependencies on several other other pieces of software to do all the heavy lifting of stats aggregation and chart rendering. I'm assuming that you would not want to build any of that processing into Bitcoin Core itself; would you be opposed to packaging other software along with the installer?
- - Jameson
On 05/07/2014 03:46 PM, Wladimir wrote:
> On Wed, May 7, 2014 at 9:12 PM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> In order to gain more insight into what messages and requests a node is processing, I've created a Bitcoin Core fork that outputs statistics to StatsD. I hope that some of you will find this interesting and potentially useful.
>>
>> http://coinchomp.com/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/
>>
>> https://jlopp.github.io/statoshi/
>>
>> Feedback is appreciated!
>
> Ooh nice graphs!
>
> We were coincidentally talking about showing stats from a node on a
> local web site on the #bitcoin-dev IRC a few days ago.
>
> At some point, if we're going to offer Bitcoin Core node-only
> installers, it'd be nice to include something like this so the user
> can keep an eye on their node(s).
>
> Wladimir
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTapAsAAoJEIch3FSFNiDcyMEIAIds0yo9zeWcqNqGZ+UNltoH
hNt8NhYOgL/6WNeLVYdRmCrrdNn/KMSLcAZmOQ0U+W/qL3xh1RB59o3BcBnW05Yr
ZxY5ajKKq+oz70ShMNUkVnzFSStMhH9fKnolrF0mgSx4CU9e0YTx/LBc/u9ulypO
QNZydiiegwvTFjMxHItgU5xo/wzySazmyxN9x3Gls98vDfSjE3Rt/DTqAwHleD3t
SlIu4RU2iPpAW/6MgfWqAw+CrbZ2NNKp7a7+0gsUlbdDP1h6WEvoae5sUzRmvLB3
rHMmRoRvTl4Hl1bG7CKyM4D3piBkpDf/nMqnAAFNYkocS5xVpHM1WrTMDAmkSLk=
=/TPp
-----END PGP SIGNATURE-----

2023-06-07 15:19:42 UTC

- reply

📅 Original date posted:2014-04-30
📝 Original message:Perhaps I missed it somewhere, but I don't recall it ever being a goal of Bitcoin to act as a stable long-term store of value.
- Jameson
On 04/30/2014 01:06 PM, Troy Benjegerdes wrote:
> On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote:
>> On 30/04/14 00:13, Mike Hearn wrote:
>>> I do think we need to move beyond this idea of Bitcoin being some kind
>>> of elegant embodiment of natural mathematical law. It just ain't so.
>>
>> I haven't seen anybody arguing that it is.
>>
>> Bitcoin is the elegant embodiment of /artificially contrived/
>> mathematical rules, which just so happen to be very useful in their
>> current configuration :-P
>>
>> Nobody is saying those rules are immutable. Just that it isn't sensible
>> to undermine them by introducing imprecise and unpredictable elements
>> like human politics.
>
> As an end-user of Bitcoin, the whole possible value of a set of mathematical
> rules has become completely trashed by the imprecise and unpredictable behavior
> of buyers and sellers.
>
> If the rules are not responsive to real human needs, bitcoin is worthless
> as a long-term store of value because **my idea of value** changes over time.
> This implies, in my mind, an absolutely requirement to attempt to gather
> some useful signal from the human political noise.
>
> How do you determine what that signal is, so you can **change the rules**
> and the mathematics so it makes more sense?
>
> You've got to deal with politics, one way or another.
>
>

2023-06-07 15:17:37 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:I would point to bandwidth as the most important issue to the casual user who runs a node at home. Few casual users have the know-how to set up QoS rules and thus become quite annoyed when their Internet connection is discernibly slowed.
- Jameson
On 04/07/2014 11:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <justusranvier at gmail.com> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
>
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
>
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:36 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:On 04/07/2014 08:26 AM, Pieter Wuille wrote:
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).
I agree, but if we don't quantify "demand" then we are practically blind. What is the plan? To wait until SPV clients start lagging / timing out because their requests cannot be handled by the nodes?
For all I know, the network would run just fine on 100 nodes. But not knowing really irks me as an engineer.
- Jameson

2023-06-07 15:17:36 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:The Bitnodes project updated their counting algorithm a month or so ago. It used to be slower and less accurate - prior to their update, it was reporting in excess of 100,000 nodes.
- Jameson
On 04/07/2014 09:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> FWIW, A few months before that we had even less than 8500 by the bitnodes count.
>
> Gah, accidentally send.... I wanted to continue here that it was less
> than 8500 and had been falling pretty consistently for months,
> basically since the bitcoin.org change. Unfortunately it looks like
> the old bitnodes.io data isn't available anymore, so I'm going off my
> memory here.
>
> The Bitnodes counts have always been somewhat higher than my or sipa's
> node counts too, fwiw.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:35 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's difficult to say how concerned we should be without more information. I posted my thoughts last month: http://coinchomp.com/2014/03/19/bitcoin-nodes-many-enough/
I have begun working on my node monitoring project and will post updates if it results in me gaining any new insights about the network.
- Jameson
On 04/07/2014 07:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop running a node (uses too
> much disk space, bandwidth, lost interest etc). But does anyone have any
> idea how we might get more insight into what's really going on? It'd be
> convenient if the subVer contained the operating system, as then we could
> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
> would be expected, or from virtual servers (Linux), which would be more
> concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things
> you should know about. If we did the same, we could have a little exit
> survey: if your node disappears for long enough, we could email the
> operator and ask why they stopped.
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:13:35 UTC

- reply

📅 Original date posted:2014-02-10
📝 Original message:You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere.
--
Jameson Lopp
Software Engineer
Bronto Software, Inc
On 02/10/2014 01:25 PM, Troy Benjegerdes wrote:
> On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
>> On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes <hozer at hozed.org> wrote:
>>> Name me one single person with commit access to the bitcoin github repository
>>> who is *independent* of any venture capital or other 'investment' connections.
>>
>> I am, unless you count the fact that I own some Bitcoin and some
>> mining hardware as "'investment' connections" (and that case your
>> comments are worthless).
>>
>> (By not naming anyone else I don't mean to imply there are no others,
>> but I don't want to speak for anyone else. Nor would I necessarily
>> expect the other part(ies|y) to step forward, since this mostly
>> appears to be an invitation to step up and be attacked.)
>
> Thank you.
>
> I also appreciate your commentary[1], and willingness to list your investment
> position. What I'm concerned about are people who have signed non-disclosure
> agreements or who's salary/equity/whatever depend on people who are experts
> at manipulating markets to take naive investors money.
>
> Independent is also a state of mind as much as it is about financial connections.
>
> What pisses me off here is that a huge amount of wealth just changed hands based
> on MtGox's press release, and it stinks of insider trading. I still maintain the
> best outcome would be for MtGox to AGPLv3 release their code, and then those of
> us that understand it would be able to have a public technical discussion about
> how to fix it, and MtGox would still maintain their intellectual property
> ownership position.
>
> This, however, cuts off a significant revenue stream for people who take money
> making market bets 5 minutes before the information goes public, so I expect
> the likelyhood of such an outbreak of sanity is quite low.
>
> [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
>
>
> DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright
> development models, and I expect to take a lot of money charging people to write
> code I give away for free. I also occasionally make money from cryptocurrency
> mining, but only when I can sell it in functional and transparent markets.
>
> ------------------------------------------------------------------------------
> Android™ apps run on BlackBerry®10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>