Andrew LeCody [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-08 to 2017-03-13
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:56:55

- reply

📅 Original date posted:2017-03-13
📝 Original message:This formatting of JSON isn't unheard of though, it's typically called JSON
Streaming[1]. As long as exchanges implementing the API actually follow the
BIP and keep one JSON object per line, it shouldn't be a problem to decode.
1. https://en.wikipedia.org/wiki/JSON_Streaming
On Tue, Mar 7, 2017 at 8:07 AM Marcel Jamin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 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
> _______________________________________________
> 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/20170313/b8f95ee6/attachment.html>

2023-06-07 17:36:47

- reply

📅 Original date posted:2015-08-18
📝 Original message:This should probably be posted on the BitcoinXT mailing-list, as Bitcoin
Core does not currently include this feature.
On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin XT contains an unmentioned addition which periodically downloads
> lists of Tor IP addresses for blacklisting, this has considerable privacy
> implications for hapless users which are being prompted to use the
> software. The feature is not clearly described, is enabled by default, and
> has a switch name which intentionally downplays what it is doing
> (disableipprio). Furthermore these claimed anti-DoS measures are trivially
> bypassed and so offer absolutely no protection whatsoever.
>
> Connections are made over clearnet even when using a proxy or onlynet=tor,
> which leaks connections on the P2P network with the real location of the
> node. Knowledge of this traffic along with uptime metrics from
> bitnodes.io can allow observers to easily correlate the location and
> identity of persons running Bitcoin nodes. Denial of service can also be
> used to crash and force a restart of an interesting node, which will cause
> them to make a new request to the blacklist endpoint via the clearnet on
> relaunch at the same time their P2P connections are made through a proxy.
> Requests to the blacklisting URL also use a custom Bitcoin XT user agent
> which makes users distinct from other internet traffic if you have access
> to the endpoints logs.
>
>
>
> https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/8f65ba17/attachment.html>

2023-06-07 17:35:30

- reply

📅 Original date posted:2015-08-17
📝 Original message:Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon, Aug 17, 2015, 01:43 Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >There are a few ways: here is my favorite (for the moment).
> >
> >1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
> >'BitcoinXT'
>
> Even more direct: use coinbase outputs of XT blocks to create those
> outputs, as they can't by definition be on the Bitcoin chain.
>
> If you can't get those, using coinbase outputs of Bitcoin blocks to create
> "definitely Bitcoin-only" outputs, and then spend the inputs to those
> transactions again on the XT chain. This isn't quite as good, as a big
> reorg on the XT chain could in theory spend them, but it's a close second.
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS
> AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq
> qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03
> cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq
> 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT
> EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z
> kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90=
> =OD56
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/a89ac35b/attachment.html>

2023-06-07 17:35:28

- reply

📅 Original date posted:2015-08-16
📝 Original message:> PS: I consider this attempt at takeover about as foul as it gets. The
equivalent of repeating a referendum until a yes is obtained: the
reasonable reaction to this is actively blocking said "referendum". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
Once a majority is obtained in this way, devs have to react or if they
don't then this sort of foul play would be justified. But this wasn't the
case.
I fail to see how voting with version numbers is different than voting with
coinbase scriptSig. Other than the fact that the voting XT is doing is
formally defined instead of ad-hoc.
On Sat, Aug 15, 2015 at 5:40 PM muyuubyou via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I posted this to /r/BitcoinMarkets but I thought I might post it here as
> well.
>
> ---
> Currently 0 mined blocks have voted for XT.
>
> If it ever gets close to even 50%, many things can happen that would
> reshape the game completely.
>
> For instance:
>
> - Core could start boycotting XT by not relying to them and/or not relying
> from them.
>
> - Core could appropriate the version string of XT, making it impossible to
> know how much they are progressing and a losing bet to actually execute the
> fork.
>
> This kind of node war if the factions were sizeable would make it very
> risky to transact at all - balances in new addresses could end up
> vanishing. Usability of the system would plummet.
>
> Note that any disagreement between the network and the biggest economic
> actors - mainly the exchanges at this point, "wallet services" maybe -
> would mean BTC plummets. Hard. And so would confidence.
>
> It's a risky game to play.
> ---
>
> PS: I consider this attempt at takeover about as foul as it gets. The
> equivalent of repeating a referendum until a yes is obtained: the
> reasonable reaction to this is actively blocking said "referendum". There
> was a fair play alternative which is voting through coinbase scriptSig like
> plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
> Once a majority is obtained in this way, devs have to react or if they
> don't then this sort of foul play would be justified. But this wasn't the
> case.
>
> -----
> 為せば成る
> _______________________________________________
> 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/20150816/b28441d8/attachment-0001.html>

2023-06-07 17:35:28

- reply

📅 Original date posted:2015-08-16
📝 Original message:Cam, your scenario makes no sense.
> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
> 2. Encourage all miners to false vote for the Bitcoin XT fork.
This would obliterate any confidence in Bitcoin Core. I seriously doubt
anyone would actually be ok with a pull request implementing this.
> 3. Setup good Atomic Swap markets.
Who would bother writing this code, let alone trading on these markets?
> 4. Setup a fork of Bitcoin XT that allows people to easily make a
transaction only on the XT fork (while leaving the original BTC coins
untouched).
I doubt this is even possible.
On Sun, Aug 16, 2015 at 6:02 PM Cameron Garnham via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think that it is important to note that Bitcoin XT faces a natural
> uphill battle.
>
> Since it is possible to setup atomic inter-fork coin trades. I do not
> see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
> XTBTC for BTC everyday for the first 100 days after the fork.
>
> In many ways Satoshi gets to decide the winning fork just by his huge
> economic investment in Bitcoin.
>
>
> Here is some simple game-theory for non-consensus forks:
>
> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
> string.
>
> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>
> - Now people have no-idea what % of the economy Bitcoin XT holds. -
> Making it impossible for people to put economic faith behind Bitcoin XT.
>
> 3. Setup good Atomic Swap markets.
>
> 4. Setup a fork of Bitcoin XT that allows people to easily make a
> transaction only on the XT fork (while leaving the original BTC coins
> untouched).
>
>
> This means that the Bitcoin XT fork will be born per-mature. Probably
> with only a small % of hashing power behind it (contrary to the almost
> 100% that falsely claim to support it). It will be embarrassing that for
> the goal of larger blocks, XT instead has blocks (before re-adjustment)
> every 2h.
>
>
> The price for XTBTC coins will plummet, Satoshi progressively dumping
> his 1M stash over a year or so will make sure that it doesn't recover
> either.
>
>
> I cannot see how Bitcoin XT is but-not in a extremely weak position from
> game theory.
>
> I'm sure smarter people than I could come up with even more ways to
> disrupt non-consensus forks.
>
> Cam.
>
>
>
> On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote:
> > I posted this to /r/BitcoinMarkets but I thought I might post it here as
> > well.
> >
> > ---
> > Currently 0 mined blocks have voted for XT.
> >
> > If it ever gets close to even 50%, many things can happen that would
> > reshape the game completely.
> >
> > For instance:
> >
> > - Core could start boycotting XT by not relying to them and/or not
> relying
> > from them.
> >
> > - Core could appropriate the version string of XT, making it impossible
> to
> > know how much they are progressing and a losing bet to actually execute
> the
> > fork.
> >
> > This kind of node war if the factions were sizeable would make it very
> > risky to transact at all - balances in new addresses could end up
> > vanishing. Usability of the system would plummet.
> >
> > Note that any disagreement between the network and the biggest economic
> > actors - mainly the exchanges at this point, "wallet services" maybe -
> > would mean BTC plummets. Hard. And so would confidence.
> >
> > It's a risky game to play.
> > ---
> >
> > PS: I consider this attempt at takeover about as foul as it gets. The
> > equivalent of repeating a referendum until a yes is obtained: the
> > reasonable reaction to this is actively blocking said "referendum". There
> > was a fair play alternative which is voting through coinbase scriptSig
> like
> > plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
> > Once a majority is obtained in this way, devs have to react or if they
> > don't then this sort of foul play would be justified. But this wasn't the
> > case.
> >
> > -----
> > 為せば成る
> >
> >
> >
> > _______________________________________________
> > 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/20150816/85c8ae7b/attachment-0001.html>

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-30
📝 Original message:tl;dr
$100 worth of hardware and $1/mo of expenses, should be able to run a full
Bitcoin node until 2020 with BIP101-size blocks.
----
I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until
recently my profession has been as a server administrator or systems
engineer.
I'd like to take a second to address the concern that larger blocks would
make it harder to run a full node on limited hardware and would therefore
hurt decentralization. I run two nodes today, one on server-grade hardware
at a datacenter and another on a mini-ITX Atom (dual core) system at my
home.
I detailed the operational costs of my home node today on reddit:
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr
If I was a new user, wanting to run a full node. The most cost effective
way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total
cost about $100, including charger, microSD card, etc. That is less than
the cost of a TREZOR hardware wallet. As far as home projects go, not
terribly expensive.
Next, it will need power. According to the Wikipedia article, the rpi 2
model B uses 3.5 watts of power max. The 2TB external drive will draw about
5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my
area (North Texas) power is about $0.10/Kwh, which means my little node
costs $0.62 per month in power.
Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in
the same way because this is a home connection, mainly because I don't know
how to price in the loss of enjoyment if the system impacts my Internet
usage to a noticeable degree. Luckily, I have some real world data from my
existing home node. Here is the last month:
http://imgur.com/YmJwQpN
This system averages 120 Kbps in and 544 Kbps out. Note, this data is
somewhat skewed, because the system is also used for seeding torrents of
various open source projects. The Bitcoin node itself is typically
connected to about 20 peers at any given time (maxconnections=20).
Subjectively, my wife and I have never noticed any degradation of
performance due to my home server using too much bandwidth. I think it's
safe to say that I can treat the bandwidth is uses as effectively free,
since it's piggybacking on a connection I would be paying for even if I was
not running a Bitcoin node. The bandwidth usage of this Bitcoin node could
increase significantly, without any noticeable impact. If it did, I could
always lower maxconnections back to 8.
The only real constraint seems to be hard drive space, as the full
blockchain and indexes take up about 50GB of space currently. If BIP101 is
implemented, 2TB of storage should be enough for me to continue running my
hypothetical $100 node until about 2020.
It seems to me that at least for the next 5 years, the "small devices" of
today can easily run Bitcoin nodes with BIP101-size blocks, with very
little operational cost.
If anyone would like more detailed data on my existing nodes, please let me
know and I'll attempt to provide it (so long as it doesn't impact my
privacy of course).
On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I dont think people consider other blockchains as a competitive
> threat. A PoW-blockchain is a largely singleton data structure for
> security reasons (single highest hashrate), it is hard for an
> alternative chain to bootstrap or provide meaningful security.
> Secondly the world largely lacks expertise to maintain a blockchain to
> bitcoin's security level, perhaps you can see a hint of this in the
> recently disclosed security vulnerability by Pieter Wuille and Gregory
> Maxwell. Calls to this as an argument are not resonating and probably
> not helping your argument. Bitcoin has security properties, and a
> competing system cant achieve better properties by bypassing security,
> any blockchain faces the same fundamental security / decentralisation
> limitations.
>
> Secondly Bitcoin can obviously compete with itself with different
> parameters and defacto *does* today. I think it is a safe estimate
> that > 99% of Bitcoin transactions right now are happening in Bitcoin
> related systems with various degrees of audit, reconciliation,
> provable reserves etc. I think we can expect this to continue and
> become more secure via more reconciliation, and longer term via
> lightning or Bitcoin sidechains with different parameters. It is a
> different story to have a single central system (Bitcoin with
> parameters changed to the point of centralisation failure) vs having
> multiple choices, because some transactions can more easily use
> relatively centralised systems (eg micropayments), and more
> interestingly the combination of a secure and decentralised layer 1
> plus choices of less decentralised layer 2 options, can be interesting
> because the layer 2 is provided cover from attack. There is less to
> be gained by attacking relatively centralised layer 2 because any
> payments at risk of policy abuse (which is typically a small subset)
> can easily switch to layer 1. That in itself makes layer 2
> transactions also less susceptible to policy abuse. Further lightning
> it appears from work so far should add significant scale while
> retaining trustlessness and a good degree of decentralisation.
>
> Finally you seem to be focusing on "artificial" limits where that is
> not the issue under consideration. The limits are technical and
> relating to decentralisation and security. I wont go over them again
> as this topic has been covered many times in recent months. Any chain
> that tried to go to extreme parameters (very low block intervals, or
> very large blocksizes) would have the same decentralisation problems
> as Bitcoin would if it did the same thing. There are a number of alt
> coins that have failed as a result of poor parameter choices, there
> are inherent security limits.
>
> Adam
>
> ps Etiquette note for yourself and others: please dont be repetitive
> or attempt to be forceful. Many people have spent many years
> understanding this very complex system, from my own experience it is
> rare indeed to think of an entirely new concept or analysis, that
> hasnt' been long considered and put to bed 3 or 4 years ago.
> Thoughtful polite and constructive comments are welcome but I
> recommend to not start from an assumption that you have a clear and
> better insight than the entire technical community, because I have to
> say from my own experience that is very rarely the case. It can be
> useful to test theories on #bitcoin IRC channel to find out what has
> been already concluded, find the references and avoid having to have
> that hashed out on this list which is trying to be focussed on
> technical solutions.
>
>
> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Cheapest way to send value? Is this what Bitcoin is trying to do? So
> >> all of the smart contract, programmable money, consensus coding and
> >> tremendous developer effort is bent to the consumer demand for cheaper
> >> fees. Surely thou jests!
> >
> >
> > These other features can be replicated into any alternative blockchain,
> > including those with lower fees. In the open-source world of
> > cryptocurrency, no feature will remain a value-add for very long after it
> > has been identified to be such. Anything adding value will quickly be
> > absorbed into competing alternative blockchains. That will leave
> economic
> > policy as the distinguishing factor.
> >
> >> ... it is not the case ... that reluctance to concede
> >> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
> >> explained in this thread that the protocol's current state of
> >> development relies on blocksize for security and, ultimately, as a
> >> means of protecting its degree of decentralization.
> >
> >
> > A slow or lack of increase to maximum transaction rate will cause
> pressure
> > on fees. Whether this is the desired goal is not relevant. Everyone has
> > agreed this will be the outcome. As to a smaller block size being needed
> > for additional decentralization, one must simply ask how much we are all
> > willing to pay for that additional decentralization. It is likely that
> the
> > benefit thereto will have to be demonstrated by some power attacking and
> > destroying a less decentralized currency before the benefit of this
> feature
> > is given monetary value by the market. Until then, value will bleed to
> the
> > network with the least friction, because it will have the greatest
> ability
> > to grow its network effect. That means the blockchain with adequate
> > features and cheapest fees will eventually have the largest market share.
> >
> >
> > -----Original Message----- From: Venzen Khaosan
> > Sent: Wednesday, July 29, 2015 3:11 PM
> > To: Raystonn .
> > Cc: bitcoin-dev at lists.linuxfoundation.org
> > Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
> > isn'ttemporary
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Raystonn, I'm aware that you're addressing your question to Greg
> > Maxwell, however a point you keep stating as fact calls for reference:
> >
> > On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
> > [snip]
> >>
> >> How do you plan to address the bleeding of value from Bitcoin to
> >> alternative lower-fee blockchains created by the artificially-high
> >> bitcoin transaction fees when users begin looking for the cheapest
> >> way to send value?
> >
> > Cheapest way to send value? Is this what Bitcoin is trying to do? So
> > all of the smart contract, programmable money, consensus coding and
> > tremendous developer effort is bent to the consumer demand for cheaper
> > fees. Surely thou jests!
> >
> >> Modern economic study has shown that liquidity moves to the
> >> location of least friction.
> >
> > Modern economic study? Can you please provide a link or reference to
> > the study you are referring to.
> >
> > "liquidity moves to the location of least friction"
> >
> > This sounds like "econo-speak" and makes no sense. The definition of
> > Liquidity is the degree to which an asset/security can be bought or
> > sold in the market without affecting the price.
> >
> > That is why bitcoin is said to have low liquidity: buying or selling
> > only 100 BTC visibly affects the exchange price. You probably mean
> > "people like cheap fees", which is true, but as others have said,
> > because of Bitcoin's powerful features, they are willing to pay higher
> > fees and wait longer for transactions to execute.
> >
> > As for your public cross-examination of Greg Maxwell, your case seems
> > to be made on the assumption that limiting the size of the blockchain
> > is an attempt to artificially raise tx fees, but it is not the case
> > (as you and others repeatedly argue) that reluctance to concede
> > blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
> > explained in this thread that the protocol's current state of
> > development relies on blocksize for security and, ultimately, as a
> > means of protecting its degree of decentralization.
> >
> > Surely, this is an obvious concern even for those who are campaigning
> > for the hare-brained ideal of making Bitcoin a "faster, cheaper
> > alternative" to visa or paypal? If we lose decentralization, we lose
> > the whole thing, right? Incorrect or correct?
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
> > RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
> > h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
> > Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
> > YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
> > BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
> > =lQvy
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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/54c3c041/attachment-0001.html>

2023-06-07 15:43:58

- reply

2023-06-07 15:17:44

- reply

📅 Original date posted:2014-04-08
📝 Original message:My node (based in Dallas, TX) has about 240 connections and is using a
little under 4 Mbps in bandwidth right now.
According the hosting provider I'm at 11.85 Mbps for this week, using 95th
percentile billing. The report from my provider includes my other servers
though.
On Mon, Apr 7, 2014 at 12:39 PM, Chris Williams <chris at icloudtools.net>wrote:
> I’m afraid this is a highly simplistic view of the costs of running a full
> node.
>
> My node consumes fantastic amounts of data traffic, which is a real cost.
>
> In the 30 days ending Apri 6, my node:
>
> * Received 36.8 gb of data
> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last
> month for bandwidth alone. It would be slightly cheaper if I was hosted in
> the US of course.
>
> But anyone can understand that moving a half-terrabyte of data around in a
> month will not be cheap.
>
>
> On Apr 7, 2014, at 8:53 AM, Gregory Maxwell <gmaxwell at gmail.com> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> 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/20140408/d50a040e/attachment.html>