Ivan Brightly [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:46:58

- reply

📅 Original date posted:2015-12-28
📝 Original message:>
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> Far more concerning is network propagation effects between large and
> small miners. For that class of issues, if you are in an environemnt
> where selfish mining is possible - a fairly flat, easily DoS/sybil
> attacked network topology - the profitability difference between small
> and large miners even *without* attacks going on is a hugely worrying
> problem. OTOH, if you're blocksize is small enough that propagation time
> is negligable to profitability, then selfish mining attacks with <30%
> hashing power aren't much of a concern - they'll be naturally defeated
> by anti-DoS/anti-sybil measures.
>
Let's agree that one factor in mining profitability is bandwidth/network
reliability/stability. Why focus on that vs electricity contracts or
vertically integrated chip manufacturers? Surely, sufficient network
bandwidth is a more broadly available commodity than <$0.02/kwh
electricity, for example. I'm not sure that your stranded hydroelectric
miner is any more desirable than thousands of dorm room miners with access
to 10gbit university connections and free electricity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151228/abe958d6/attachment.html>

2023-06-07 17:39:49

- reply

📅 Original date posted:2015-09-08
📝 Original message:Agreed. For this reason, the scaling BIPs which don't allow for easy gaming
such as BIP101, your proposal or Pieter's are preferable for their
predictability and simplicity. Changing the fundamental rules for Bitcoin
is supposed to be hard - why give this power up to a subsection of the
ecosystem in order to make it easier to change or game?
On Tue, Sep 8, 2015 at 9:13 AM, Adam Back <adam at cypherspace.org> wrote:
> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks.
>
> Adam
>
>
> On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > This is true, but miners already control block size through soft caps.
> > Miners are fully capable of producing smaller blocks regardless of the
> max
> > block limit, with or without collusion. Arguably, there is no need to
> ever
> > reduce the max block size unless technology advances for some reason
> reverse
> > course - aka, WW3 takes a toll on the internet and the average bandwidth
> > available halves. The likelihood of significant technology contraction in
> > the near future seems rather unlikely and is more broadly problematic for
> > society than bitcoin specifically.
> >
> > The only reason for reducing the max block limit other than technology
> > availability is if you think that this is what will produce the fee
> market,
> > which is back to an economic discussion - not a technology scaling
> > discussion.
> >
> > On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> > but allow meaningful relief to transaction volume pressure in response
> >> > to true market demand
> >>
> >> If blocksize can only increase then it's like a market that only goes
> >> up which is unrealistic. Transaction will volume ebb and flow
> >> significantly. Some people have been looking at transaction volume
> >> charts over time and all they can see is an exponential curve which
> >> they think will go on forever, yet nothing goes up forever and it will
> >> go through significant trend cycles (like everything does). If you
> >> dont want to hurt the fee market, the blocksize has to be elastic and
> >> allow contraction as well as expansion.
> >
> >
> > _______________________________________________
> > 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/20150908/8c49c772/attachment-0001.html>

2023-06-07 17:39:48

- reply

📅 Original date posted:2015-09-08
📝 Original message:This is true, but miners already control block size through soft caps.
Miners are fully capable of producing smaller blocks regardless of the max
block limit, with or without collusion. Arguably, there is no need to ever
reduce the max block size unless technology advances for some reason
reverse course - aka, WW3 takes a toll on the internet and the average
bandwidth available halves. The likelihood of significant technology
contraction in the near future seems rather unlikely and is more broadly
problematic for society than bitcoin specifically.
The only reason for reducing the max block limit other than technology
availability is if you think that this is what will produce the fee market,
which is back to an economic discussion - not a technology scaling
discussion.
On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > but allow meaningful relief to transaction volume pressure in response
> to true market demand
>
> If blocksize can only increase then it's like a market that only goes
> up which is unrealistic. Transaction will volume ebb and flow
> significantly. Some people have been looking at transaction volume
> charts over time and all they can see is an exponential curve which
> they think will go on forever, yet nothing goes up forever and it will
> go through significant trend cycles (like everything does). If you
> dont want to hurt the fee market, the blocksize has to be elastic and
> allow contraction as well as expansion.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150908/a1ce797b/attachment.html>

2023-06-07 15:44:27

- reply

📅 Original date posted:2015-07-31
📝 Original message:1. Data centers are not some uniform group of businesses with identical
policies nor firms with identical laws applied. The ability to get a search
warrant at a Swedish hosting provider will be dramatically different than a
Singaporean business. Similar to the decentralized nature of bitcoin, these
businesses are independent and varied - it would be difficult for
authorities to conduct a widescale attack on nodes worldwide, especially
given current laws. It would also be ineffective since any hacked/seized
host can be replaced quickly with a competitor service in a different
jurisdiction.
2. Personal residences and non-data center businesses are not immune to
theft, blackmail, seizure, hacking, etc. Depending upon the adversary and
method of attack, many users would be no worse off with their nodes not
located on premise. As alluded to above, it's a lot easier and less costly
to spin up a new 3rd party host than it is to replace a stolen laptop.
There is nothing inherently wrong with data centers/hosting providers
playing a significant (but not central) role in decentralized services.
Users who choose to use a VPS are not contributing to bitcoin in some sort
of inferior capacity. I'll posit that 3rd party providers are not an ideal
place to hold private keys, but that is off topic.
On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think trust the data-center logic obviously fails, and I was talking
> about this scenario in the post you are replying to. You are trusting the
> data-center operator period. If one could trust data-centers to run
> verified code, to not get hacked, filter traffic, respond to court orders
> without notifying you etc that would be great but that's unfortunately not
> what happens.
>
> Data-center operators are bound to follow laws, including NSLs and gag
> orders. They also get hacked, employ humans who can be corrupt,
> blackmailed, and themselves centralisation points for policy attack.
> Snowden related disclosures and keeping aware of security show this is very
> real.
>
> This isn't much about bitcoin even, its just security reality for hosting
> anything intended to be secure via decentralisation, or just hosting in
> general while at risk of political or policy attack.
>
> Adam
> On Jul 31, 2015 10:39, "jl2012 via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> There is a summary of the proposals in my previous mail at
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
>>
>> I think there could be a compromise between Gavin's BIP101 and Pieter's
>> proposal (called "BIP103" here). Below I'm trying to play with the
>> parameters, which reasons:
>>
>> 1. Initiation: BIP34 style voting, with support of 750 out of the last
>> 1000 blocks. The "hardfork bit" mechanism might be used:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>>
>> Rationale: This follows BIP101, to make sure the new chain is secure.
>> Also, no miner would like to be the first one to mine a large block if they
>> don't know how many others would accept it.
>>
>> 2. Starting date: 30 days after 75% miner support, but not before
>> 2016-01-12 00:00 UTC
>>
>> Rationale: A 30-day grace period is given to make sure everyone has
>> enough time to follow. This is a compromise between 14 day in BIP101 and 1
>> year in BIP103. I tend to agree with BIP101. Even 1 year is given, people
>> will just do it on the 364th day if they opt to procrastinate.
>>
>> 2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in
>> China. Most pool operators and devs should be back from new year holiday
>> and not sleeping. (If the initiation is delayed, we may require that it
>> must be UTC Tuesday midnight)
>>
>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied
>> by 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on
>> 2017-05-11.
>>
>> Rationale: Instead of jumping to 8MB, I suggest to increase it gradually
>> to 8MB in 16 months. 8MB should not be particularly painful to run even
>> with current equipment (you may see my earlier post on bitctointalk:
>> https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed
>> by Chinese miners, who control >60% of the network.
>>
>> 4. After 8MB is reached, the block size will be increased by 6.714% every
>> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
>> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
>> 2042-11-17.
>>
>> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
>> p.a. of BIP101. This will take us almost 8 years from now just to go back
>> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>>
>> SSD price is expected to drop by >50%/year in the coming years. In 2020,
>> we will only need to pay 2% of current price for SSD. 98% price reduction
>> is enough for 40 years of 27.67% growth.
>> Source:
>> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>>
>> Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
>> should be safe at least for the coming 10 years.
>> Source:
>> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>>
>> The final cap is a compromise between 8192MB at 2036 of BIP101 and
>> 2048MB at 2063 of BIP103
>>
>>
>> -----------------------------------
>>
>> Generally speaking, I think we need to have a faster growth in the
>> beginning, just to normalize the block size to a more reasonable one. After
>> all, the 1MB cap was introduced when Bitcoin was practically worthless and
>> with inefficient design. We need to decide a new "optimal" size based on
>> current adoption and technology.
>>
>> About "fee market": I do agree we need a fee market, but the fee pressure
>> must not be too high at this moment when block reward is still miner's main
>> income source. We already have a fee market: miners will avoid building big
>> blocks with low fee because that will increase the orphan risk for nothing.
>>
>> About "secondary layer": I respect everyone building secondary layer over
>> the blockchain. However, while the SWIFT settlement network is processing
>> 300tps, Bitcoin's current 7tps is just nothing more than an experiment. If
>> the underlying settlement system does not have enough capacity, any
>> secondary layer built on it will also fall apart. For example, people may
>> DoS attack a Lightening network by provoking a huge amount of settlement
>> request which some may not be confirmed on time. Ultimately, this will
>> increase the risk of running a LN service and increase the tx fee inside
>> LN. After all, the value of secondary layer primarily comes from instant
>> confirmation, not scarcity of the block space.
>>
>> _______________________________________________
>> 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/20150731/faab5248/attachment.html>

2023-06-07 15:44:11

- reply

📅 Original date posted:2015-07-30
📝 Original message:One thing that the below assumption doesn't appear to take into account is
user demand for quick confirmations. I haven't fully thought out the game
theory on this but here goes:
Example: if 75% of hashing power accepts 'medium' fee transactions while
25% is willing to accept low (or any) fee transactions, then a user paying
a lower fee wishing to get their transaction included in the next block
runs a ~75% chance that their transaction won't be included.
Users desiring the most reliably fast confirmations are better off by
paying the minimum fee that a majority of miners will accept. Miners
breaking ranks and accepting lower fees only affects users who aren't
sufficiently interested in quicker confirmations. As long as a majority of
miners 'collude', they will likely be able to keep the average fees higher
than miners with the lower costs of operations might be willing to accept.
On Thu, Jul 30, 2015 at 12:00 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Does an unlimited blocksize imply the lack of a fee market? Isn't every
> > miner able to set their minimum accepted fee or transaction acceptance
> > algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam
> _______________________________________________
> 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/78d19cbb/attachment.html>

2023-06-07 15:40:41

- reply

📅 Original date posted:2015-06-28
📝 Original message:I don't think that rights are a pillar of how bitcoin works - rather I
would say it's a matter of aligned incentives. The fact is that the
majority technically *can* dictate through PoW and acceptance. The only
reason that the majority would not chose this path is because there is
greater economic value in consensus, whether perceived or realized.
If bitcoin were about "doing the right thing" there wouldn't be a need for
PoW since no individual would be incentivized to double spend.
On Sun, Jun 28, 2015 at 11:05 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Sun, Jun 28, 2015 at 3:51 PM, Ivan Brightly <ibrightly at gmail.com>
> wrote:
> > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >>
> >>
> >> No, this is very important. The majority has no right to dictate on
> >> the minority.
> >
> >
> > While an interesting philosophical question, I don't think that this is
> > accurate. First off, bitcoin doesn't imbue any 'rights' on individuals
> - it
> > provides the choice of participating or not, nothing more.
>
> I think you're not contradicting me: ff there's not rights built into
> the system, the majority has no "right to dictate" anything.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/a57d5395/attachment.html>

2023-06-07 15:40:41

- reply

📅 Original date posted:2015-06-28
📝 Original message:Agreed on both accounts. The main point is that there are no inherent
rights built into bitcoin - just aligned economic interests enforced by
agreed upon technical rules. The technical rules allow for a majority to
dictate, while the economic interests may or may not support such a change.
On Sun, Jun 28, 2015 at 10:16 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Furthermore, the actual way in which the conflict is resolved sets a
> precedent for how such disagreements are to be “resolved” in the future.
>
> So the means are also important to consider.
>
> - Eric
>
> On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly at gmail.com> wrote:
>
> On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> No, this is very important. The majority has no right to dictate on
>> the minority.
>>
>
> While an interesting philosophical question, I don't think that this is
> accurate. First off, bitcoin doesn't imbue any 'rights' on individuals -
> it provides the choice of participating or not, nothing more.
>
> Secondly, from a technical perspective, how is it that the majority (or
> super-majority) are prevented from imposing their will? The best answer is
> that they are incentivized to not override a minority group since that
> reduces the inherent value in the system. However, presuming that the
> majority calculate that the reward for imposing a change is greater than
> the value lost in such disruption, I don't see how there would be any
> stopping this change. The longest chain with the greatest number of users
> valuing the token on that chain "wins".
>
> _______________________________________________
> 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/20150628/c4445eb6/attachment-0001.html>

2023-06-07 15:40:40

- reply

📅 Original date posted:2015-06-28
📝 Original message:On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> No, this is very important. The majority has no right to dictate on
> the minority.
>
While an interesting philosophical question, I don't think that this is
accurate. First off, bitcoin doesn't imbue any 'rights' on individuals -
it provides the choice of participating or not, nothing more.
Secondly, from a technical perspective, how is it that the majority (or
super-majority) are prevented from imposing their will? The best answer is
that they are incentivized to not override a minority group since that
reduces the inherent value in the system. However, presuming that the
majority calculate that the reward for imposing a change is greater than
the value lost in such disruption, I don't see how there would be any
stopping this change. The longest chain with the greatest number of users
valuing the token on that chain "wins".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/0d76c58a/attachment.html>

2023-06-07 15:39:46

- reply

📅 Original date posted:2015-06-26
📝 Original message:On Fri, Jun 26, 2015 at 3:08 PM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> > On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> > > Pieter Wuille showed with simulations that miners with bad connectivity
> > > are negatively affected by other miners creating larger blocks.
> > >
> >
> > ... but the effect is only significant if they have an absurdly
> > low-bandwidth connection and do NOTHING to work around it (like rent a
> > server on the other side of the bandwidth bottleneck and write some code
> to
> > make sure you're creating blocks that will propagate quickly on both
> sides
> > of the bottleneck).
>
> "Just rent a server" forces miners into deploying insecure hosted
> infrastructure that's vulnerable to hacking and seizure; that we
> encourage this already is worrying; requiring it for miners to be
> profitable isn't acceptable.
>
There are a number of factors that contribute to mining vulnerabilities.
For example, presuming a miner is a meaningful contributor to the network,
they'll be using more electricity than their neighbors and will be easily
identifiable in the same way illegal grow-houses are identified by the
local power company working with authorities. A hacked or seized hosted
server is far easier to recover from than seized equipment. Its hard to see
how requiring a reasonably reliable internet connection is a particularly
high barrier to entry when compared to the other mining requirements, such
as funds to purchase ASICs, competitive electricity costs, reasonable
belief that equipment won't be stolen or seized, the technical knowledge
for setting up a p2pool node, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/abe98de7/attachment-0001.html>

2023-06-07 15:39:36

- reply

📅 Original date posted:2015-06-21
📝 Original message:Received as any other message from the mailing list.
On Sun, Jun 21, 2015 at 6:25 PM, Warren Togami Jr. <wtogami at apache.org>
wrote:
> This post from wtogami at apache.org is again from an address not subscribed
> to the list. It should be auto-rejected by the server. If this goes through
> to the list then something is wrong with the configuration.
>
> _______________________________________________
> 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/20150621/10e53413/attachment.html>

2023-06-07 15:39:00

- reply

📅 Original date posted:2015-06-20
📝 Original message:Yep - similarly: you live in a neighborhood with a local coffee store. Sure
you could use a stolen credit card or a fake $5 bill, but it's not worth
the risk of being caught for a $3 coffee. And on the other side, the store
can deal with 1% of transactions getting reversed or having a fake bill so
they don't change their procedures.
Perfection is not necessary in all situations.
On Sat, Jun 20, 2015 at 12:02 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> > On Jun 19, 2015, at 8:48 PM, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
> >> They don't need to be made cryptographically safe, they just have to be
> >> safer than, for instance, credit card payments that can be charged
> back. As
> >> long as it's reasonably good in practice, that's fine.
> >
> > They never will be. You can get a decent rate of success merely by
> making one
> > transaction propagate fast (eg, 1 input, 1 output) and the other slow
> (eg,
> > 1000 inputs, 1000 outputs) and choosing your peers carefully. The only
> reason
> > unconfirmed transactions aren't double spent today is because nobody is
> > seriously *trying*.
> >
> > Luke
> >
>
>
> Newspapers are often sold in vending machines that make it possible for
> anyone to just pay the price of one and take them all…and most of the time
> they are not that carefully monitored. Why? Because most people have better
> things to do than try to steal a few newspapers. They probably were much
> more closely monitored earlier in their history…but once it became clear
> that despite the obvious attack vector very few people actually try to game
> it, vendors figured it wasn’t really that big a risk. Same thing applies to
> people trying to steal a piece of bubble gum at the cash register at a
> convenience store by double-spending.
>
> - Eric Lombrozo
>
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/5b12e445/attachment.html>

2023-06-07 15:37:12

- reply

📅 Original date posted:2015-06-10
📝 Original message:"My opinion is the most sustainable solution would be to identify a
team of admins and use something like Digital Ocean's new team accounts
feature and have someone like SolidX contribute funds for the servers
and a few hours a week from one of their sysadmins to the team."
This is a perfectly fine option. Alternatively, if the paid mailing list
option is preferred, I'd suggest Intermedia:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/fb0ba912/attachment.html>

2023-06-07 15:37:11

- reply

📅 Original date posted:2015-06-10
📝 Original message:I like elegant solutions and while eventually I can see a "pay to
contribute" service, I don't imagine you'll get consensus in short order.
List provider costs are pretty reasonable, so if that's the hurdle to
overcome I'm happy to offer sponsorship.
Ivan Brightly
SolidX Partners
On Wed, Jun 10, 2015 at 12:46 PM, Andy Schroder <info at andyschroder.com>
wrote:
> Regarding changing the e-mail list provider. Is anyone interested in
> sponsoring it? There are non-free options, but it may be difficult to
> always ensure the fee is being paid to the provider. I think finding an
> agreeable free solution may have been the issue before? I've also
> thought of trying to make a pay per message or byte solution (and this
> cost could be dynamic based upon the number of current mailing list
> subscribers). This could solve the who pays problem (the sender pays),
> as well as motivate people to be more concise and clear with their
> messages, and at the same time limit spam.
>
>
>
> Any thoughts?
>
> Andy Schroder
>
> On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
> > On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
> >>
> http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
> > All our downloads (even old ones) have recently been deleted from
> sourceforge, for this reason. They haven't been mentioned in Bitcon Core
> release announcements for a long time.
> >
> > No opinion on the mailing list. Though I think it's less urgent. The
> issue of moving the mailinglist has come up before a few times and people
> can't agree where to move to.
> >
> > Wladimir
> >
> >
> >
> ------------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150610/8f93b6ab/attachment.html>