Warren Togami Jr. [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-08-16 to 2019-03-18
💬 Posted a total of 63 messages
📚 Participated in the following categories: Bitcoin-development, PATCH, try2, bitcoin-dev, xxxx
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1s5p2xnl52ksr3a4qfa8re5znmja46ugm3x3ayy0x2c2mqrsw6ewsmzxem8

Profile Code

nprofile1qqsg2q4rfl69tgpc76sy7n3u6pfaew6awydcng7jz8n9v9dspc8dvhgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsvulh8r

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1s5p2xnl52ksr3a4qfa8re5znmja46ugm3x3ayy0x2c2mqrsw6ewsmzxem8

Show more details

Last Notes

2023-06-07 19:48:12

- reply

📅 Original date posted:2016-01-27
📝 Original message:On Wed, Jan 27, 2016 at 2:12 AM, Luzius Meisser <luzius.meisser at gmail.com>
wrote:
> I agree that flex cap is promising. However, for it to be a viable
> long-term solution, it must not depend on significant block subsidies
> to work as the block subsidy will become less and less relevant over
> time
There is another variant of the Flex Cap approach that allows miners to pay
with a slightly higher difficulty target instead of deferring a portion of
subsidy to later blocks. I think the HK presentation was about the subsidy
deferral variant because of miner feedback that they preferred that
approach.
Myself and a few other developers think proposals like BIP100 where the
block size is subject to a vote by the miners is suboptimal because this
type of vote is costless. You were astute in recognizing in your post it's
a good thing to somehow align the global marginal cost with the miner's
incentive. I feel a costless vote is not great because it aligns only to
the miner's marginal cost, and not the marginal cost to the entire flood
network. Flex Cap is superior as "vote" mechanism as there is an actual
cost associated, allowing block size to grow with actual demand.
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160127/dfc770d0/attachment.html>

2023-06-07 19:48:11

- reply

📅 Original date posted:2016-01-27
📝 Original message:On Tue, Jan 26, 2016 at 9:42 AM, Luzius Meisser via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This post serves to convince you of the economic benefits of smoothing
> the payout of fees across blocks. It incentivizes decentralization and
> supports the establishment of a fee market.
>
> Idea: currently, the total amount of fees collected in a block is paid
> out in full to whoever mined that block. I propose to only pay out,
> say, 10% of the collected fees, and to add the remaining 90% to the
> collected fees of the next block. Thus, the payout to the miner
> constitutes a rolling average of collected fees from the current and
> past blocks. This
> *reduces the marginal benefit of including an additional transaction into
> a block* by an order of magnitude and thus
> aligns the incentives of individual miners better with those of the
> whole network. As a side-effect,
>
> *the disadvantage of mining with a slow connection is reduced.*
I do not believe your logic is correct. Reducing the marginal benefit of
including an additional transaction is problematic because it
simultaneously increases the orphan risk while it reduces the reward. 90%
of the fee going to the next block would also create new incentive problems
like mining an empty block to minimize the chance of losing 90% of the fees
from the previous block to an orphan. Another major issue with mandatory
sharing is if the miner doesn't want to share, nothing stops them from
taking payment out-of-band and confirming the transaction with little or no
fees visible in the block.
I had been thinking recently about fee deferral for a different reason. In
the future when the subsidy is much smaller in proportion to the fees,
there may be little incentive to confirm on top of someone else's block in
cases when the expected value of replacing the current tip is higher. I
think smoothing fees between the current and subsequent 5 blocks (for
example) might reduce the incentive of this type of behavior. The main
risk here might be in weakening too far the incentive of adding more
transactions to the current block, as I believe your 10% current and 90%
subsequent reward split would do. I think my idea of a mandatory split
between six blocks might also be a failure because of the high incentive to
conduct out-of-band payments.
> Benefits:
>
2. This is a step towards a free fee market. In an ideal market,
> prices form where supply and demand meet, with the fees asymptotically
> approaching the marginal costs of a transaction. Currently, supply is
> capped and only demand can adjust. Should we ever consider to let
> miners decide about supply, it is
>
> *essential that their marginal benefit of including an additional
> transaction is aligned with the global marginal cost incurred by that
> additional transaction.* Fee
> smoothing is a step in this direction.
>
While I don't agree with the rest of your logic, it is agreeable that you
care about aligning the miner's supply incentives with the global marginal
cost. If you believe that is an important goal, you might like the Flex
Cap approach as presented by Mark Friedenbach at Scaling Bitcoin Hong Kong.
Under the general idea of the Flex Cap approach block size is no longer
fixed, it can be bursted higher on a per-block basis if the miner is
willing to defer a tiny portion of the current block subsidy to pay out to
the miner of later blocks. If conditions are such that there is genuine
demand then some are willing to pay higher fees for time preference. Some
formula would balance the cost and reward in some manner like: add the
value of newly included fees, subtract the expected marginal cost of orphan
risk, then subtract the portion of subsidy deferred. Flex cap has periodic
block size retargets to allow for a temporary limit to rise or fall to
something resembling actual market demand. This temporary limit is never a
"wall" that can be hit as miners can choose to burst past it if the cost is
worth the reward.
Flex Cap is an area of ongoing research that I strongly believe would
benefit Bitcoin in the long-term. For this reason it requires careful
study and simulations to figure out specifics.
3. The incentive to form mining pools is reduced. Currently,
> solo-mining yields a very volatile income stream due to the random
> nature of mining, leading to the formation of pools. This volatility
> will increase to even higher levels once the amount of Bitcoins earned
> per block is dominated by (volatile) collected fees and not by
> (constant) freshly minted coins, thus increasing the economic pressure
> to join a large pool. Fee smoothing reduces that volatility and
> pressure.
>
You seem to not recognize that orphan cost is a major reason why pools are
attractive.
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160126/c2d01aac/attachment-0001.html>

2023-06-07 19:39:52

- reply

📅 Original date posted:2015-09-09
📝 Original message:Does it really change the schedule when the next difficulty retarget
readjusts to an average of 10 minutes again?
On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There is another concern regarding "flexcap" that was not discussed.
>
> A change to difficulty in response to anything BUT observed block
> production rate unavoidably changes the money supply schedule, unless
> you also change the reward, and in that case you've still changed the
> timing even if not the average rate.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150909/1641325f/attachment.html>

2023-06-07 19:39:06

- reply

📅 Original date posted:2015-09-02
📝 Original message:I am skeptical that any license for the blockchain itself is needed because
of the possibility that the blockchain is not entitled to copyright
protection. While I am not a lawyer, I have stared hard at the copyright
doctrine of the U.S. in multiple law school Intellectual Property courses
and during my previous career in Open Source Software where copyright
matters a great deal.
As each owner of a
> coin makes a transfer by digitally signing a hash of the previous
> transaction along with the
> new owner’s public key, the block chain is a perpetual compilation of
> unique data.
> *It is therefore compiled in a creative and non-obvious way.* In the USA,
> for example, these
> attributes confer legal protections for databases which have been ruled
> upon by the courts.
This portion of your paper I believe is not true and requires citations if
you want to be convincing. Is it truly "creative and non-obvious"? My
understanding under at least U.S. law, the blockchain may not be entitled
to copyright protection because a compilation created in a mechanical
manner is not a creative work of a human.
I suppose a transaction could contain a "creative" element if it contains
arbitrary bytes of a message or clever script. For the most part though
most of what you call "digitally signing a hash of the previous transaction
along with the new owner’s public key" is purely the result of a mechanical
process and really is not creative. Furthermore, even if that output were
"non-obvious", obviousness has nothing to do with copyrightability.
Your license is correct in intent in attempting to exclude from the royalty
free grant works within the blockchain that themselves may be subject to
copyright of third parties. The elements within the blockchain may be
entitled individually to copyright if they are in any way a creative work
of a human, but as a compilation I am doubtful the blockchain itself is
entitled to copyright.
I understand copyright with respect to databases can be different under
other jurisdictions. Your paper mentions the European database law that is
indeed different from the U.S. Your paper is incomplete in scholarly and
legal citations. I myself and we as a community don't know enough. I
suppose this topic merits further study.
Warren Togami
On Tue, Sep 1, 2015 at 6:30 AM, Ahmed Zsales via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.
>
> Replacing or amending the existing MIT Licence is beyond the scope of this
> draft BIP.
>
> Rationale and details of our draft BIP for discussion and evaluation are
> here:
>
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> _______________________________________________
> 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/20150902/f96f29e5/attachment.html>

2023-06-07 19:38:45

- reply

📅 Original date posted:2015-08-31
📝 Original message:Hi folks,
I think we should agree to disable the ability to subscribe with digests on
bitcoin-dev list. I think digests were from an earlier era of Internet
history. Digests are inconvenient for everyone because replies have the
problem of breaking threads. These days people should be setting mail
filters to separate list mail from other mail. I think digests are really
not a net-positive for the community so we should just turn off the ability
to do it.
Any objections?
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150831/63b16e0c/attachment.html>

2023-06-07 19:37:05

- reply

📅 Original date posted:2015-08-19
📝 Original message:FYI, a few developers including Wladimir, Greg, Peter Todd, Pieter, and
Alex Morcos have been discussing what to do about improving the signal
noise ratio on bitcoin-dev list. One proposal similar to this discussion
was to split it into multiple mailing lists. It was pointed out that the
less technical Bitcoin discussion list already existed in the past and
nobody used it. Generally the discussion went away from creating yet
another mailing list and toward instituting an on-topic guidelines for
bitcoin-dev. Gavin, Wladimir, and a few of the others agreed to a simple
few paragraphs written by Alex Morcos. IIRC Wladimir agreed to post it.
Has it been posted yet?
On Wed, Aug 19, 2015 at 11:47 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> > bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
> > discussion?
>
> Well -dev or both, I dont particularly see a difference at the moment,
> and establishing two lists isnt really going to make a difference so
> long as Bitcoin Core is the reference client, which it is by defacto.
> The risk of having too many lists is interested stakeholders will miss
> a discussions. Normal protocol and core discussions are usually pretty
> low volume in any case.
>
> > As Jorge notes, a general discussion list has existed for a long time
> with
> > little use.
>
> I would suggest it's only because there havent been any rules for -dev
> that would force general discussion over to the bitcoin list. On IRC
> we regularly tell people in #bitcoin-dev they are OT and ask them to
> move to #bitcoin and as a result, -dev remains quite clear of chit
> chat, #bitcoin has a steady stream of general chatter.
>
> We could reduce the OT/noise of bitcoin-dev list considerably by
> offloading the non-technical/academic debate to the bitcoin list. It
> just needs a bit of shepherding. I am more than happy to help out.
> Especially if the list already exists, we should consider making a
> decision now.
>
> Who are the moderators for that list? Do we really want to use
> sourceforge or are there alternatives, like another list on
> linuxfoundation?
>
> ping @Warren.
> _______________________________________________
> 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/20150819/913a23c2/attachment-0001.html>

2023-06-07 19:35:42

- reply

📅 Original date posted:2015-08-18
📝 Original message:I honestly don't understand your position, but I get the sense that you are
suggesting Satoshi wouldn't be welcome to return if he wanted to be active
in development again?
Warren
On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin at olivere.de> wrote:
> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
> > This bitcoin-dev list restarted with an empty subscriber list on June
> > 21st, 2015. So whoever posted from satoshi at vistomail.com
> > <mailto:satoshi at vistomail.com> subscribed and verified the address
> > recently. Do you propose that we manually approve new subscribers to
> > prevent these kind of "abuses" as you put it?
>
> I would simply block the creators old email addresses. Easy with
> Mailman. I thought that would be a good and easy approach, but maybe I'm
> wrong.
>
> Some believes it is possible that the email could be genuine. Some say
> that only the content is important. I have closely followed. An
> interesting discussion. Thank you all so far.
>
> But let's say the poster would be the real Satoshi. Would we discuss his
> posting if he would not claim to be Satoshi? There are a lot of smart
> people on this list, which publish occasionally quite useful ideas. But
> much of this is hardly the subject of greater discussion. Especially not
> when it comes to the blocksize. On this subject almost everything has
> been already said. But not yet by everyone. Especially not by Satoshi.
>
> Satoshi would have a decisive influence on the community. I'm sure. To
> say it does not matter who's talking is maybe genteelly but a little bit
> remote from everyday life. Or not? Satoshi is the creator. What he says
> is in the newspaper and is perceived by all. If he says it's okay to do
> nothing as long as we stand together, then people have the courage to do
> maybe something dangerous or something wrong. Then people only follow
> their hearts. Otherwise they follow their fear. It is a paradox of the
> human nature that some type of Dictatorship can make you free. I say
> some type, not any type. Enough said.
>
> - oliver
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/5961bb7c/attachment.html>

2023-06-07 19:35:41

- reply

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 4:40 AM, Oliver Egginger via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> That made it to the news and is now discussed in various places. Could
> you please delete Satoshis old email addresses from the list and block
> them? Sorry to post this to all members but I can't find an owner for
> this list.
>
> - oliver
This bitcoin-dev list restarted with an empty subscriber list on June 21st,
2015. So whoever posted from satoshi at vistomail.com subscribed and verified
the address recently. Do you propose that we manually approve new
subscribers to prevent these kind of "abuses" as you put it?
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/ba0fe5d6/attachment.html>

2023-06-07 17:47:25

- reply

2023-06-07 17:47:25

- reply

2023-06-07 17:41:03

- reply

📅 Original date posted:2015-06-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
June 28th, 2015
Mailman's obscure_addresses option is now disabled. It has been pretty
useless
as a spam mitigation measure anyway.
This is a test message to see if mailman continues to break --clearsign GPG
signatures for messages that contain an e-mail address like test at example.com
.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQQcBAEBCAAGBQJVkKy7AAoJELEXnrc0fcENmiIf/1Qgb/XFDmGl5RsZnMWh+kCX
EBjT/ouufgURTrOt6XPhwnxJAYMKPtobg4MvjosqKFNKzyz3Io9TxkWXFXFLajLt
uZ/RPck0b6qYPXW02m6on1Zj8VIKrREtm4CEH/2q7iHkjsWIHULo+K6emrJQtIOs
DzhUEniPPVDJVIq2pZJGKHq87ydmnFMYhXjzCu2e0N7CBFw/uxtUEsvkd0uuognm
YVjnrCjS8CLzNgEkx8z6R1WWz7psDQeLr+d8BP/6TVrgEOaeX4pAy9mhqdPjGutV
C6X3SyMlSA/PDJFqzT5Upe4UKwKWGq7AOBz7OpzpYIqJ69NKsIjCgh+t6qCisDZO
O3XFUIidmKZsWE422InFLhUtqzwZHq56J/eKKiYz53BSYtTOPIs4+RPlm1Gzs7gP
cEqoDYobdlT2H1vCvNficcbH5nWmooErUxT06tXjGqfPHlm+OVuOyVTwuin+gD5H
winqtNlkSCbG1MjhUoLEJVxLHP7t6i5e6EKPQrvP0XycKuO2PMlVkYYFBGMKEFF/
sL68wyV/0PzGRA7ggcBmcOGHC7ys2sOroLZCWNDnOrQnRFHvQgDCQpj3uMFMO7yf
8E+0CIKO0vB/Ljxse51+s/NZTX8uTZu525+hSG8cuLY1FTl5Zk3oRH1HGUJ9wbWh
Hjx6827uh543+AHWgBwEpQ/8LkSlc0UN6txNmYn4DJgEksqP80iaPkvXAEesSUJ8
OtAPrWOMZXcSsp7HZkDXuJyMUerGvZcdIVvVNsLOWLWa2c0kyDdxubGflhGN/Hkq
67pJ5J/aeraw7BdfRi78CUWYXpVBlMaQ60jT2LV9XQxsqSnZb3+VgN9vyvQi/gih
enr+l8r4esM7TOsGYHMWbQkHgnm/wOMiMc56xlqeIi/+cRuJF3Mg5LnbqIUU1Ox0
S+luGASWg1R2yU4n0EWQ5sx1dmslgvJe6lDKlQXEX4e4d5F0vhnyFiDVhChMCpGv
ALK8MiUZGD2y9fIPB+Yypq7mH9NiQwQIJtpbVgVd2pBEl0XWkbs6F5GNq90ChE7x
hWiyu2N/iug2r7zKt5KtZob9hIljQ6N/HAk+O1lLPUktX5HBt8X+KHyX22GMLIAu
g4tWk2P7R0Sh2rYSd43S3CMF01eaGI2oWU0rj2KtG1HqQMVOIVjdxYR3tpmC69Tb
MyCq7xe+zOcAiWkAeb1cJjgahrnDBR663zSsqZVnAyG9GQVvPY6fZKxYoY2B+xgP
tEi8FTL3ag0PbdUJF8SQugx+R3HNBS+r1AGgOUEBtrrH9IqBAaOf3N+rMFLUl/HW
ypTs5fj6A49CkncmQQGcyj3BwlEjhr4wF59Bpxn/KTwT5H2Sdu1QEuB2G+gwqYs=
=bOwk
-----END PGP SIGNATURE-----
On Sat, Jun 27, 2015 at 4:54 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> Generally agreed w/ all this.
>
> To preserve digital signatures now and in the future, and make mbox
> archives actually useful, a minimum modification policy is needed.
>
>
>
> On Sat, Jun 27, 2015 at 3:21 PM, grarpamp <grarpamp at gmail.com> wrote:
>
>> On Sun, Jun 21, 2015 at 9:14 PM, Frank Flores <frankf44 at gmail.com> wrote:
>> > If you're going to go through the trouble of signing your public emails
>> ...
>>
>> ... then you should also demand that the official archives of your
>> favorite lists preserve them and their verifiability in the supposedly
>> canonical reference "mbox" format that they distribute.
>>
>> On Wed, Jun 24, 2015 at 7:47 AM, Wladimir J. van der Laan
>> <laanwj at gmail.com> wrote:
>> > Subject: [bitcoin-dev] New GPG signing key for Bitcoin Core binary
>> releases
>>
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
>>
>> As you can clearly see, both the HTML archives and the "mbox"
>> archives have corrupted this message, it will not verify. Do not
>> try to say this case is trivial, the problem itself is not trivial,
>> it's gratuitous, and it applies to all matching messages... text,
>> code, binary inline... that's dangerous.
>>
>> Do not try to say this corruption prevents spam, it does not.
>> Spammers simply subscribe to the list and harvest everything
>> efficiently in realtime... no webcrawling overhead, no stale
>> addresses. Obfuscation is futile.
>>
>> This misfeature needs to be disabled.
>>
>>
>>
>> On Fri, Jun 19, 2015 at 12:57 AM, Warren Togami Jr. <wtogami at gmail.com>
>> wrote:
>> > archives will be exported
>> > and imported into the new list server
>>
>> On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com>
>> wrote:
>> > I'm not sure if anyone has submitted a request for gmane
>>
>> On Sun, Jun 21, 2015 at 5:35 PM, s7r <s7r at sky-ip.org> wrote:
>> > Do we have all the archives imported? I run several full nodes and
>> > mirrors for open source projects, if you think it's useful, I can
>> > provide a mirror for the mail list archives.
>>
>> Yes... these other mirrors, archives, analysis, journalism, and
>> interfaces are useful. However, as it is now, there are no useful
>> authoritative sources for them to seed from... they're all corrupt.
>> And any subscribed realtime sources, though nice, are subject to
>> downtime, administrative and other unrecoverable gaps. Your mirror
>> project is a fine idea, you should demand that the pristine historical
>> sources be made publicly available. Not just for you, but for everyone.
>>
>>
>>
>> On Wed, Jun 17, 2015, grarpamp wrote:
>> > ...
>>
>> As before, the current "mbox" archives are broken and not useful...
>>
>> a) They corrupt message data, messages are unverifiable, another
>> example...
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009132.html
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June.txt.gz
>> b) They are missing the minimum set of original headers necessary
>> for fully replyable, threadable, sortable, searchable, context
>> preserving and direct use by users MUA's in their local environment:
>> (Date, From, To, Cc, Subject, Message-ID, In-Reply-To, References)
>> c) They do not include attachments (patches, signatures, images, crypto,
>> data) that are absolutely necessary to the context and archives
>> of all lists. Instead they stupidly throw them away to "web links"
>> which results not only in uselessness of the so called "mbox"
>> version, but in many thousands of needless fetches by archive
>> users and indexers. And hours of wasted work attempting to
>> postprocess them into usable form.
>> Valuable content lost from the "mbox" files this June alone:
>> 418 attachment.html
>> 106 attachment.sig
>> 6 attachment.jpe
>> 4 attachment.png
>> 2 attachment.bin
>> d) There appear to be at least 15 instances of unescaped '^From '
>> in the "mbox". Regeneration with current mailman may fix. One such
>> case is here:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/004245.html
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January.txt.gz
>>
>>
>>
>> Please fix all the above mentioned issues by providing the full raw
>> archives in regularly updated [gzip/7z] mbox format. The internet
>> thanks you :)
>>
>> Example, compare the "Downloadable version"s here:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
>> https://cpunks.org/pipermail/cypherpunks/
>> https://cpunks.org/pipermail/cypherpunks/2015-February/006820.html
>>
>>
>>
>> On Tue, Jun 23, 2015 at 2:45 PM, Andy Schroder <info at andyschroder.com>
>> wrote:
>> > Regarding message footers and the subject prefix
>>
>> Yes, they're also corruptive and space wasting clutter, for and by
>> the clueless :( Both of them should be turned off.
>> _______________________________________________
>> 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/20150628/4cc5cd58/attachment-0001.html>

2023-06-07 17:40:08

- reply

📅 Original date posted:2015-06-25
📝 Original message:https://github.com/pstratem/bitcoin/commits/testnet4
See these two commits for an example of changing all the testnet chain
parameters to create an entirely separate testnet network. This example
"testnet4" changed to different port numbers, pchMessageStart magic, and
with stupid large block sizes.
http://rusty.ozlabs.org/?p=509
Rusty used this to test block propagation latency.
On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong at gmail.com> wrote:
> In the process of 'mining consensus', perhaps before voting there should
> be robust system testing and telemetry.
>
> May I ask a questions w.r.t. Process BIPs, what is the process for
> establishing a new testnet (e.g. for testing with 8MB blocks)?
>
> p.
>
>
> On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> These are the kind of silly responses you often get when this subject
>> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
>> no need for him to use the list to attack people he doesn't agree with
>> and/or try to interfere with discussions of others on the list.
>> He turns it into a personality discussion rather than a discussion of
>> Systems Engineering. He also tries to intimate anyone who brings up the
>> discussion and "punish" them as a lesson to anyone else who may raise the
>> issue.
>>
>> It is interesting that people like that are attracted to a decentralized
>> system. The reply is simply an attempt at protecting turf which is why
>> Mr. Garzik's vague replies are never taken seriously on the subject of
>> decision-making process for the software.
>>
>> Russ
>>
>>
>>
>> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>>
>> Ladies & gents, please do not feed the troll. This has been explained to
>> Milly multiple times in the past, on previous mailing list & github with no
>> impact.
>>
>>
>> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
>> wrote:
>>
>>> I'm sorry but that is the kind of defensive, cultish response everyone
>>> gets when they ask that question. If you had a well constructed documented
>>> process then you would be able to point to it ... but you can't. While
>>> there are a few bits and pieces scattered about in different places there
>>> is no coherent plan or process.
>>>
>>> It is easy to make statements like "consensus must be unanimous" but the
>>> issue is that you never have true 100% consensus yet you have to move
>>> forward in some fashion and everyone has to run software with the same
>>> consensus rules. The issue is how you move forward is the question that
>>> nobody wants to answer because (a) it is a hard question to answer and (b)
>>> developers see it as a threat to their authority/position. If people just
>>> keep shutting down the discussion with a bunch of cultish stock answers
>>> then you are never going to move forward with developing some kind of
>>> process.
>>>
>>> From what I can see much of the discussion is personality-driven and not
>>> based on Computer Science or and defined process. The issue is that a
>>> personality has changed so the process is perceived to be different and
>>> some people want to hard fork. Previously, the cultish answer is that
>>> Bitcoin development is decentralized because people can fork the code. Now
>>> that some developers want to fork the code suddenly it is a big problem.
>>> Is forking the code part of the consensus process or is it the work of the
>>> devil? The fact that there is so much diverse opinion on this shows a
>>> defined process has never been fully vetted or understood.
>>>
>>> I have worked on these processes for many years for projects orders of
>>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>>> mishmash does not scale and huge amounts of time are wasted. That should
>>> be readily apparent from the recent discussions and the recent concern it
>>> has caused from people outside the developer's inner circle.
>>>
>>> Lack of defined process = high risk and wasted effort.
>>>
>>> Russ
>>>
>>>
>>>
>>>
>>>
>>> On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
>>>
>>> I'm sorry but this is absolutely not the case, Milly. The reason that
>>> people get defensive is that we have a carefully constructed process that
>>> does work (thank you very much!) and is well documented. We talk about it
>>> quite often in fact as it is a defining characteristic of how bitcoin is
>>> developed which differs in some ways from how other open source software is
>>> developed -- although it remains the same in most other ways.
>>>
>>> Changes to the non-consensus sections of Bitcoin Core tend to get
>>> merged when there are a few reviews, tests, and ACKs from recognized
>>> developers, there are no outstanding objections, and the maintainer doing
>>> the merge makes a subjective judgement that the code is ready.
>>>
>>> Consensus-changes, on the other hand, get merged into Bitcoin Core only
>>> after the above criteria are met AND an extremely long discussion period
>>> that has given all the relevant stakeholders a chance to comment, and no
>>> significant objections remain. Consensus-code changes are unanimous. They
>>> must be.
>>>
>>> The sort of process that exists in standards bodies for example, with
>>> working groups and formal voting procedures, has no place where changes
>>> define the nature and validity of other people's money. Who has the right
>>> to reach into your pocket and define how you can or cannot spend your
>>> coins? The premise of bitcoin is that no one has that right, yet that is
>>> very much what we do when consensus code changes are made. That is why when
>>> we make a change to the rules governing the nature of bitcoin, we must make
>>> sure that everyone is made aware of the change and consents to it.
>>>
>>> Everyone. Does this work? Does this scale? So far, it does.
>>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
>>> indication is that BIP 66 will complete deployment in the very near future,
>>> and we intend to repeat this process for more interesting changes such as
>>> BIP65: CHECKLOCKTIMEVERIFY.
>>>
>>> This isn't about no one stepping forward to be the "decider." This is
>>> about no one having the right to decide these things on the behalf of
>>> others. If a contentious change is proposed and not accepted by the process
>>> of consensus, that is because the process is doing its job at rejecting
>>> controversial changes. It has nothing to do with personality, and
>>> everything to do with the nature of bitcoin itself.
>>>
>>>
>>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly at bitcoins.info>
>>> milly at bitcoins.info> wrote:
>>>
>>>> I have seen this question asked many times. Most developers become
>>>> defensive and they usually give a very vague 1-sentence answer when this
>>>> question is asked. It seems to be it is based on personalities rather than
>>>> any kind of definable process. To have that discussion the personalities
>>>> must be separated out and answers like "such-and-such wouldn't do that"
>>>> don't really do much to advance the discussion. Also, the incentive for
>>>> new developers to come in is that they will be paid by companies who want
>>>> to influence the code and this should be considered (some developers take
>>>> this statement as an insult when it is just a statement of the incentive
>>>> process).
>>>>
>>>> The other problem you are having is the lead developer does not want to
>>>> be a "decider" when, in fact, he is a very significant decider. While the
>>>> users have the ultimate choice in a practical sense the chief developer is
>>>> the "decider." Now people don't want to get him upset so nobody wants to
>>>> push the issue or fully define the process. Now you are left with a
>>>> broken, unwritten/unspoken process. While this type of thing may work with
>>>> a small group of developers businesses/investors looking in from the
>>>> outside will see this as a risk.
>>>>
>>>> Until you get passed all the personality-based arguments you are going
>>>> to have a tough time defining a real process.
>>>>
>>>> Russ
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>>
>>>>> I would like to start a civil discussion on an undefined, or at least
>>>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>>>> these voters sufficient for approval? If not, then what is?
>>>>>
>>>>> Raystonn
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://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/20150624/1482dee3/attachment-0001.html>

2023-06-07 17:39:36

- reply

📅 Original date posted:2015-06-21
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/22f4a02c/attachment.html>

2023-06-07 17:39:34

- reply

📅 Original date posted:2015-06-21
📝 Original message:This post from wtogami at apache.org is 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/9af25dcf/attachment-0001.html>

2023-06-07 17:39:32

- reply

📅 Original date posted:2015-06-21
📝 Original message:Hi folks,
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
The move is now complete. The previous archive has been fully imported and
new posts here will now be saved.
*Greylisting Notice*
Your first post to this list may be delayed by 5+ minutes due to Greylisting
<https://en.wikipedia.org/wiki/Greylisting>. Subsequent posts should go
through without delay. Contact Freenode #bitcoin-dev if you have any
questions or concerns.
*TODO*
- LF will be upgrading Mailman soon to better handle posts from DKIM
enforced domains.
- There will be a few more config tweaks like auto-rejecting
non-subscribed posts. Nobody has time to moderate this list, and mail
silently disappearing into the moderation hold blackhole is worse than an
instant reject message telling people to subscribe. Unfortunately, it is
too dangerous to auto-reject spam ... those messages need to go into a
blackhole to prevent bounce abuse.
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/719ef682/attachment.html>

2023-06-07 17:39:31

- reply

📅 Original date posted:2015-06-21
📝 Original message:Given the Sourceforge list server exploded and unsubscribed the majority of
the old list, we decided to move forward with the planned list move in
roughly 50 minutes from now. 9pm UTC or 2pm PDT this list will be
permanently shut down with auto-reject on all posts.
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Please subscribe to the new list. It will be opened for posts shortly
after 9pm UTC after the final archive import.
https://en.wikipedia.org/wiki/Greylisting
Do not panic if your post does not immediately reach the new list. Your
first post to the new list may be delayed by 5+ minutes due to greylisting.
Please chat in Freenode #bitcoin-dev if you have any questions or concerns.
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/0d3528dc/attachment.html>

2023-06-07 17:39:24

- reply

📅 Original date posted:2015-06-20
📝 Original message:This is an important notice to all members of the Bitcoin Dev List.
*Tuesday, June 23rd 8pm UTC (1pm PDT) the following will happen.*
- The current list at bitcoin-development at lists.sourceforge.net will
reject all posts.
- The current archives at
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/ will be
exported.
- The test archives at the new list will be wiped and replaced with an
import from the old list.
- The new list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev will be
open to posts after the archive import is complete.
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Everyone may to subscribe at the new list now. Feel free to make test
posts. Anything posted prior to the switchover on Tuesday will be wiped
from the archives.
*DMARC Status*
A current issue with this list is posts from domains that require DKIM
signature verification will end up in the spam folder at popular providers
like gmail. Initially the new list will have that exact same problem as we
will continue to have the subject tag and footer. Within a few weeks LF
will upgrade Mailman to do automatic Munge From
<http://wiki.list.org/DEV/DMARC> which will solve this problem.
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/01b23a5a/attachment.html>

2023-06-07 17:38:52

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn <mike at plan99.net> wrote:
> The new list currently has footers removed during testing. I am not
>> pleased with the need to remove the subject tag and footer to be more
>> compatible with DKIM users.
>>
>
> Lists can do what are effectively MITM attacks on people's messages in any
> way they like, if they resign for the messages themselves. That seems fair
> to me! :)
>
Mailman isn't resigning it. Should it be? Does other mailing list
software?
>
>
>> I'm guessing DKIM enforcement is not very common because of issues like
>> this?
>>
>
> DKIM is used by most mail on the internet. DMARC rules that publish in DNS
> statements like "All mail from bitpay.com is signed correctly so trash
> any that isn't" are used on some of the worlds most heavily phished domains
> like google.com, PayPal, eBay, and indeed BitPay.
>
> These rules are understood and enforced by all major webmail providers
> including Gmail. It's actually only rusty geek infrastructure that has
> problems with this, I've never heard of DKIM/DMARC users having issues
> outside of dealing with mailman. The vast majority of email users who never
> post to technical mailing lists benefit from it significantly.
>
> Really everyone should use them. Adding cryptographic integrity to email
> is hardly a crazy idea :)
>
I understand the reason to protect the "heavily phished" domains. I heard
that LKML does not modify the subject or add a footer, perhaps because it
would make it incompatible with DKIM of the several big corporate domains
who participate.
I suppose it is somewhat acceptable for us to remove subject tags and
footers if we have no choice...
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/bce0b675/attachment.html>

2023-06-07 17:38:51

- reply

📅 Original date posted:2015-06-19
📝 Original message:Both you and jgarzik experienced mail getting tossed into gmail's spam
folder thanks to DKIM... I am concerned that DKIM is too fragile and not
very compatible with mailing lists.
We already removed the footer because it was incompatible with DKIM
signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
with DKIM header signing only if the poster manually prepends it in their
subject header.
I am already concerned that the lack of the Mailman footer will make it
hard to identify where exactly subscribers need to go to unsubscribe or
look at archives. Removing the subject tag might make DKIM enforcement
work a lot better, but I can easily see our obtuse subscribers as being
extra confused by this.
Opinions?
Warren
On Thu, Jun 18, 2015 at 11:38 PM, Arthur <arthur at powaaa.com> wrote:
> warren | bad_duck: try manually adding "[Bitcoin-dev] " to the beginning
> of the subject
>
> --
> Arthur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/3878c132/attachment.html>

2023-06-07 17:38:51

- reply

📅 Original date posted:2015-06-19
📝 Original message:On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn <mike at plan99.net> wrote:
> We already removed the footer because it was incompatible with DKIM
>> signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
>> with DKIM header signing only if the poster manually prepends it in their
>> subject header.
>>
>
> I still see footers being added to this list by SourceForge?
>
The new list currently has footers removed during testing. I am not
pleased with the need to remove the subject tag and footer to be more
compatible with DKIM users.
>
>
>> Opinions?
>>
>
> I've asked Jeff to not use his @bitpay.com account for now.
>
>
I'm guessing DKIM enforcement is not very common because of issues like
this?
It seems that Sourceforge silently drops DKIM enforced mail like
jgarzik's. LF seems to pass along their mail but mangles the header/body
and makes DKIM verification fail, which causes gmail to toss it into the
spam folder. I think this behavior is slightly worse than Sourceforge
because it makes the poster think their message was successfully sent (it
is in the archive), but many subscribers never see it due to the spam
binning.
I don't see any good solution to this except an auto-reject for DKIM
enforced domain postings. Yes this is rather terrible, but the instant
rejection is vastly better than Sourceforge silently dropping the post or
LF getting stuck in spam filters.
We should also auto-reject any other reason for mail getting stuck in the
moderation queue like including non-subscribers. I considered
auto-rejecting spam too, but that could go horribly wrong as a false From
address could make the Mailman server into a spammer itself. We may have
no choice but to silently drop spam for that reason.
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f9fad649/attachment.html>

2023-06-07 17:37:51

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Sun, Jun 14, 2015 at 5:19 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
>
> *List Name?* Would people prefer "bitcoin-development" for he new list
> name instead of a shorter name like "bitcoin-dev"? I personally like the
> shorter name, but either is fine.
> https://lists.linuxfoundation.org/mailman/listinfo currently has
> "sidechains-dev", and "lightning-dev" is moving there sometime soon.
>
We're going ahead with "bitcoin-dev". A request for creation is now
pending.
>
> *Proposed Cut-Off Date?* Then we also need to agree on a date to cut off
> the old list. Their sysadmin said we could have the new list auto-post
> from the old list for a short while. I wonder how well that works ... if
> that will result in double posting if people write to the new and CC the
> old list. Needs a little research how well it would behave to have both
> lists operating during a transition period. I think we should announce a
> cut-off date when posts to the old list is shut off, July 15th, one month
> from now. Thoughts?
>
Off-list I heard a suggestion to make the cut-off date as short as one week
after the new list is announced and people are given the option to
subscribe. Could people please post feelings about this?
It seems most everyone agreed not to auto-subscribe everyone onto the new
list as that tends to be upsetting.
There is clarity if subscribing the old list to the new list is a good
idea. Is anyone familiar with Mailman, is it smart enough to somehow
prevent double-posts if someone writes to both the old and new address?
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/541319f9/attachment.html>

2023-06-07 17:37:50

- reply

📅 Original date posted:2015-06-15
📝 Original message:On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> * ACK on moving away from SourceForge mailing lists - though only once a
> community-welcomed replacement is up and running
>
> * ACK on using LF as a mailing infrastructure provider
>
> * Research secure mailing list models, for bitcoin-security. The list is
> not ultra high security - we all use PGP for that - but it would perhaps be
> nice to find some spiffy cryptosystem where mailing list participants
> individually hold keys & therefore access.
>
>
While I agree this is a good idea, this should not be a precondition for
moving the public bitcoin-dev list. The security team needs to separately
research/write tools needed for this.
<jgarzik> warren, wanna just go ahead and create bitcoin-development @ LF?
*More Feedback?* As for going ahead, perhaps we should wait to hear from
more of the other technical leaders?
*More Questions*
*List Name?* Would people prefer "bitcoin-development" for he new list
name instead of a shorter name like "bitcoin-dev"? I personally like the
shorter name, but either is fine.
https://lists.linuxfoundation.org/mailman/listinfo currently has
"sidechains-dev", and "lightning-dev" is moving there sometime soon.
*Proposed Cut-Off Date?* Then we also need to agree on a date to cut off
the old list. Their sysadmin said we could have the new list auto-post
from the old list for a short while. I wonder how well that works ... if
that will result in double posting if people write to the new and CC the
old list. Needs a little research how well it would behave to have both
lists operating during a transition period. I think we should announce a
cut-off date when posts to the old list is shut off, July 15th, one month
from now. Thoughts?
*Moderators?* Mailman on the new server allows having separate logins for
admins and moderators. I think the admins of the old SF project are gavin,
jgarzik and sipa... they are kind of busy. Perhaps we should identify
known trusted community members who can help with moderation. Usually this
is dealing with "held" messages that are flagged by the spam filter
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/2768e0e1/attachment.html>

2023-06-07 17:37:49

- reply

📅 Original date posted:2015-06-14
📝 Original message:Discomfort with Sourceforge
For a while now people have been expressing concern about Sourceforge's
continued hosting of the bitcoin-dev mailing list. Downloads were moved
completely to bitcoin.org after the Sept 2014 hacking incident of the SF
project account. The company's behavior and perceived stability have been
growing to be increasingly questionable.
http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer
November 2013: GIMP flees SourceForge over dodgy ads and installer
https://lwn.net/Articles/646118/
May 28th, 2015: SourceForge replacing GIMP Windows downloads
http://seclists.org/nmap-dev/2015/q2/194
June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads.
When this topic came up over the past two years, it seemed that most people
agreed it would be a good idea to move. Someone always suggests Google
Groups as the replacement host. Google is quickly shot down as too
controversial in this community, and it becomes an even more difficult
question as to who else should host it. Realizing this is not so simple,
discussion then dies off until the next time somebody brings it up.
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607
Somebody brought it up again this past week.
It seems logical that an open discussion list is not a big deal to continue
to be hosted on Sourceforge, as there isn’t much they could do to screw it
up. I personally think moving it away now would be seen as a gesture that
we do not consider their behavior to be acceptable. There are also some
benefits in being hosted elsewhere, at an entity able to professionally
maintain their infrastructure while also being neutral to the content.
Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Bitcoin is a global infrastructure development project where it would be
politically awkward for any of the existing Bitcoin companies or orgs to
host due to questions it would raise about perceived political control.
For example, consider a bizarro parallel universe where MtGox was the
inventor of Bitcoin, where they hosted its development infrastructure and
dev list under their own name. Even if what they published was 100%
technically and ideologically equivalent to the Bitcoin we know in our
dimension, most people wouldn't have trusted it merely due to appearances
and it would have easily gone nowhere.
I had a similar thought process last week when sidechains code was
approaching release. Sidechains, like Bitcoin itself, are intended to be a
generic piece of infrastructure (like ethernet?) that anyone can build upon
and use. We thought about Google Groups or existing orgs that already host
various open source infrastructure discussion lists like the IETF or the
Linux Foundation. Google is too controversial in this community, and the
IETF is seen as possibly too politically fractured. The Linux Foundation
hosts a bunch of infrastructure lists
<https://lists.linuxfoundation.org/mailman/listinfo> and it seems that
nobody in the Open Source industry considers them to be particularly
objectionable. I talked with LF about the idea of hosting generic
Bitcoin-related infrastructure development lists. They agreed as OSS
infrastructure dev is already within their charter, so early this week
sidechains-dev list began hosting there.
>From the perspective of our community, for bitcoin-dev it seems like a
great fit. Why? While they are interested in supporting general open
source development, the LF has literally zero stake in this. In addition
to neutrality, they seem to be suitable as a competent host. They have
full-time sysadmins maintaining their infrastructure including the Mailman
server. They are soon upgrading to Mailman 3 <http://wiki.list.org/Mailman3>,
which means mailing lists would benefit from the improved archive browser.
I am not personally familiar with HyperKitty, but the point here is they
are a stable non-profit entity who will competently maintain and improve
things like their Mailman deployment (a huge improvement over the stagnant
Sourceforge). It seems that LF would be competent, neutral place to host
dev lists for the long-term.
To be clear, this proposal is only about hosting the discussion list. The
LF would have no control over the Bitcoin Project, as no single entity
should.
Proposed Action Plan
-
Discuss this openly within this community. Above is one example of a
great neutral and competent host. If the technical leaders here can agree
to move to a particular neutral host then we do it.
-
Migration: The current list admins become the new list admins. We
import the entire list archive into the new host's archives for user
convenience.
-
http://sourceforge.net/p/bitcoin/mailman/ Kill bitcoin-list and
bitcoin-test. Very few people actually use it. Actually, let's delete the
entire Bitcoin Sourceforge project as its continued existence serves no
purpose and it only confuses people who find it. By deletion, nobody has
to monitor it for a repeat of the Sept 2014 hacking incident
<https://www.phoronix.com/scan.php?page=news_item&px=MTc4Mzg> or GIMP-type
hijacking <https://lwn.net/Articles/646118/>?
-
The toughest question would be the appropriateness of auto-importing the
subscriber list to another list server, as mass imports have a tendency to
upset people.
Thoughts?
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/e399d028/attachment.html>

2023-06-07 17:36:09

- reply

📅 Original date posted:2015-06-01
📝 Original message:By reversing Mike's language to the reality of the situation I had hoped
people would realize how abjectly ignorant and insensitive his statement
was. I am sorry to those in the community if they misunderstood my post. I
thought it was obvious that it was sarcasm where I do not seriously believe
particular participants should be excluded.
On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle <thyshizzle at outlook.com> wrote:
> Doesn't mean you should build something that says "fuck you" to the
> companies that have invested in farms of ASICS. To say "Oh yea if they
> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
> don't dis incentivise mining. If miners are telling you that you're going
> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
> you say too bad so sad? Why not just start stripping bitcoin out of
> adopters wallets? Same thing.
> ------------------------------
> From: Warren Togami Jr. <wtogami at gmail.com>
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
> Whilst it would be nice if miners in *outside* China can carry on
> forever regardless of their internet situation, nobody has any inherent
> "right" to mine if they can't do the job - if miners in *outside* China
> can't get the trivial amounts of bandwidth required through their firewall *TO
> THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too
> bad, we'll have to carry on without them.
>
>
> On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn <mike at plan99.net> wrote:
>
> Whilst it would be nice if miners in China can carry on forever
> regardless of their internet situation, nobody has any inherent "right" to
> mine if they can't do the job - if miners in China can't get the trivial
> amounts of bandwidth required through their firewall and end up being
> outcompeted then OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/4604b753/attachment.html>

2023-06-07 17:36:08

- reply

📅 Original date posted:2015-06-01
📝 Original message:Whilst it would be nice if miners in *outside* China can carry on forever
regardless of their internet situation, nobody has any inherent "right" to
mine if they can't do the job - if miners in *outside* China can't get the
trivial amounts of bandwidth required through their firewall *TO THE
MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad,
we'll have to carry on without them.
On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn <mike at plan99.net> wrote:
> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if
> they can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/a156e424/attachment.html>

2023-06-07 17:34:25

- reply

📅 Original date posted:2015-05-25
📝 Original message:On Mon, May 25, 2015 at 1:29 PM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> Yes, that's the issue. Because you're connecting only to one node, you
> don't get any instant confirmations -- due to a Bitcoin protocol
> limitation you can only get them from nodes you don't post the tx to.
Is it really wise to call this a "confirmation"? All this is really
telling you is one seemingly random peer has relayed the transaction
back to you that you sent to a presumably different seemingly random
peer.
Warren

2023-06-07 17:21:19

- reply

📅 Original date posted:2014-05-13
📝 Original message:bitcore guesses the network from the address version in several places in
its code. They don't want to change that. Perhaps it wasn't the wisest
approach for them to use. I thought it might be simple to change the
address version since its still relatively new and it isn't a real network.
Would it be too much work to change?
On Tue, May 13, 2014 at 12:30 AM, Mike Hearn <mike at plan99.net> wrote:
> Yes, bitcoinj supports and uses regtest mode. It would also have to be
> changed.
>
> You didn't provide a rationale for this. What's the cost of having them be
> the same?
>
>
> On Tue, May 13, 2014 at 11:45 AM, Warren Togami Jr. <wtogami at gmail.com>wrote:
>
>> Hi folks,
>>
>> I propose changing all of the address versions in -regtest mode to be
>> unique so they are no longer identical to testnet.
>>
>> https://en.bitcoin.it/wiki/List_of_address_prefixes
>> For example, regtest pubkey hash addresses could begin with r or R.
>>
>> We need to know if any existing tools would need to be modified to
>> support this change to regtest. Do existing tools outside of pull tester
>> expect regtest to have testnet addresses? If the quantity of tools that
>> currently handle regtest is small then we can modify them to the new
>> address versions.
>>
>> Warren Togami
>>
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> 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/20140513/bb49c804/attachment.html>

2023-06-07 17:19:55

- reply

📅 Original date posted:2014-04-24
📝 Original message:You do not need to be a developer to help in the improvement of Bitcoin.
http://sourceforge.net/p/bitcoin/mailman/message/32255092/
Bitcoin Core 0.9.2 feature freeze is May 13th, 2014. Now is the time for
native non-English speakers to join Transifex to clean up the translations
in all languages. This is important for more than just Bitcoin because
Litecoin will use these same translations.
*What should volunteer translators do?*
https://bitcointalk.org/index.php?topic=571414
Try the nightly builds of Bitcoin Core as it heads toward 0.9.2. Not
recommended for your production wallet.
https://www.transifex.com/projects/p/bitcoin/
Join Transifex as a translator and add your account to your language.
https://groups.google.com/forum/#!forum/bitcoin-translators
Join the Translator mailing list to receive announcements when translations
are needed for Bitcoin. You will also receive notifications if other
Bitcoin Project things in Transifex need translations (likely bitcoin.org).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/b3edb6a0/attachment.html>

2023-06-07 17:19:20

- reply

📅 Original date posted:2014-04-24
📝 Original message:On Wed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj at gmail.com> wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami at gmail.com>
> wrote:
> >> If you are
> >> a rare user who needs Bitcoin-Qt on an incompatible system you can at
> least
> >> build it from source.
> >
> > Tails users usually can't really build it from source— talks is a live
> > boot mostly stateless linux distribution for privacy applications.
> > It's really good in general.
>
> Aside: But is Bitcoin Core a well-suited application for those uses? I
> cannot imagine someone running a full node on a stateless system.
>
> Anyhow: As this is only one symbol, we can probably get rid of it (as
> we didn't use it in 0.8.6?), or put it behind some #ifdef
> COMPATIBILITY_BUILD...
>
> Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.
>
> Wladimir
>
I now see how it worked with Bitcoin 0.8.6. Lucid has qt-4.6.2.
It is more than one symbol. It does not seem to be a wise thing to replace
functions beyond the trivial in glibc and libstdc++.
I personally think we need to decide upon a cut-off point beyond which it
makes no sense to add the risk of increased complexity. RHEL6 had qt-4.6.2
as well and I don't think I've heard a single complaint about bitcoin-qt
being broken there given almost nobody uses it as a desktop.
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/feeeee08/attachment.html>

2023-06-07 17:19:17

- reply

📅 Original date posted:2014-04-22
📝 Original message:Development Roadmap of Bitcoin Core 0.9.2
The Bitcoin Core developers have a desire to do a mostly bug-fix and
translation update release in v0.9.2. A feature and string freeze will
start about 3 weeks from now.
The purpose of this development roadmap is to communicate the project
intent and to better organize volunteers. Hopefully doing so will make
clear when particular types of contributions are most welcome and help to
push the release process forward in a more timely manner while also
improving the quality of the release. Missing a target goal is OK. The
developers may decide to delay particular goals if there are good reasons
on a case-by-case basis. While schedules may slip, it is generally a good
thing for a goal to have existed.
Schedule (subject to change)
13 May 2014: Feature freeze. Source string freeze. Release candidate.
20 May 2014: Testing of a release candidate is roughly a week. More time
can be added at the discretion of the developers to allow for testing if
further release candidates are deemed necessary due to subsequent changes.
Nightly Gitian Builds
https://bitcointalk.org/index.php?topic=571414.0
To make it easier for non-developers and translators to get involved in
testing unofficial deterministic nightly builds are now available.
Translation of Bitcoin Core
https://www.transifex.com/projects/p/bitcoin/
Transifex allows open source projects a convenient way to coordinate the
work of many translators. Periodically English language source strings
from Bitcoin Core are synchronized to the Transifex project. Those strings
are then translated in the convenient Transifex web interface where
contributors are able to join by creating a free account. Senior
contributors can be promoted to a Reviewer or Maintainer role for each
language. Developers pull from Transifex to merge translated strings back
into Bitcoin Core. As a matter of policy translations are NOT accepted via
Github pull requests as those changes would be overwritten by the next
Transifex pull and there is no clean way to keep them in sync when changes
are made in both places.
https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md
The latest version of the Translation process can be found here.
Bitcoin-Translators Announce-only List
https://groups.google.com/forum/#!forum/bitcoin-translators
Bitcoin-Translators mailing list is an announce-only mailing list for
developers to communicate to translators at particular times when new
translations are needed. Replies and discussion would go to the bitcoin
dev list. Subscriptions to this list would additionally be valuable to the
project as it allows for a convenient way to ask for translations of other
related projects like bitcoin.org that are hosted on theTransifex platform.
Whenever source strings of significance are changed or deadlines are
announced, translators will learn of work to be done in Transifex quickly
as they will all be subscribed to this announce list. Discussion of
translation issues should be on the Bitcoin-Development list.
Other Improvements to the Translation process
-
Prior to an intended release a String Freeze is declared on a particular
date. The string freeze exists to ensure that translators have a
reasonable amount of time to translate new or modified source strings so
their work can be included in a release.
-
A significant issue with our past translation process was the lack of
branch support in Transifex. This meant that since master and v0.8.2
diverged in May 2013, translation updates made in Transifex were not
included in the v0.8.x stable releases until the release of v0.9.0 in early
2014. v0.9.1 similarly was released from a branch outside from master.
v0.9.2 is planned to be released directly from the master branch so
translations for this upcoming release can be developed directly. laanwj
came up with a great idea for dealing with future releases where we will be
able to keep translations for both diverged stable and master branch
simultaneously in Transifex, with scripts automating the process of merging
strings and separating them back to the diverged branches.
Please post questions or comments about the release or translation process
here on Bitcoin-Development list. Bug reports should be posted a Github
Issues<https://github.com/bitcoin/bitcoin/issues?direction=desc&sort=updated&state=open>tickets.
Warren Togami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/2fec3522/attachment.html>

2023-06-07 17:12:14

- reply

📅 Original date posted:2014-01-16
📝 Original message:Just a small note of caution for those joining in testing.
https://github.com/bitcoin/bitcoin/issues/3529
Currently the master branch has this issue where leveldb renames all of
.sst files to .ldb. This makes running the 0.8.x version of Bitcoin think
the index is corrupt. Until a fix is included in Bitcoin master, a
workaround to allow 0.8.x to work again is to simply rename all the files
from .ldb back to .sst.
(This workaround worked for me today but failed yesterday. It's possible I
made an error yesterday. If it fails for you please report as we really
need to know if there are other leveldb incompatibilities.)
https://github.com/bitcoin/leveldb/pull/3
The fix for Bitcoin's leveldb is being discussed here.
Warren
On Wed, Jan 15, 2014 at 11:09 PM, Wladimir <laanwj at gmail.com> wrote:
> Hello all,
>
> It has been way to long since last major release. Many improvements and
> new features have been added to master since, so we'd like to do a 0.9rc1
> release soon.
>
> The current aim is next month, February 2014.
>
> Of course there are still some open issues that need to be resolved before
> release
> https://github.com/bitcoin/bitcoin/issues?milestone=12&state=open
>
> If there is something else that you're working on and needs to end up in
> 0.9, or know of some nasty bug in master that should absolutely be solved
> first, please tell.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20140116/592c2421/attachment.html>

2023-06-07 17:09:56

- reply

📅 Original date posted:2013-11-22
📝 Original message:https://github.com/bitcoin/bitcoin/pull/2906
There is already a bannode RPC PR. Last I tried it didn't work though.
On Fri, Nov 22, 2013 at 11:01 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Fri, Nov 22, 2013 at 3:56 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> > Is there a reason not to have a parallel get rpc to get the current list?
>
> Easy enough to add. There had also been requests for an IP blacklist,
> which would need associated RPC/config gadgetry.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131122/75e1a855/attachment.html>

2023-06-07 17:06:05

- reply

📅 Original date posted:2013-08-16
📝 Original message:A sane default that better protects users could be...
If (plugged into power) && (wifi) then non-bloom peers are OK. It would
protect those users more than reliance upon on the smaller subset of bloom
nodes. Scale back to the less secure behavior when battery and bandwidth
matters.
Warren
On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike at plan99.net> wrote:
> That change was made in response to user complaints. Heck we get
> complaints about battery life and bandwidth impact even with Bloom
> filtering. We can't just randomly start using peoples bandwidth for
> relaying blocks, especially as I guess most SPV nodes are behind NAT.
>
> If Gavin is right and the future is dominated by mobiles and tablets, then
> it will require a change of thinking in how P2P networks work. I think
> there are plenty of people with private servers who would be willing to run
> nodes though. I'm not too worried about this.
>
>
> On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami at gmail.com>wrote:
>
>> bitcoinj-0.10 release notes:
>>
>> - We now require Bloom-capable (0.8+) peers by default and will
>> disconnect from older nodes. This avoids accidental bandwidth saturation on
>> mobile devices.
>>
>> Given the user-security concern that Peter brings up, reconsideration of
>> this new default behavior in SPV clients may be warranted.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>>> > Doing this also makes it more difficult to sybil the network - for
>>> > instance right now you can create "SPV honeypots" that allow incoming
>>> > connections only from SPV nodes, thus attracting a disproportionate %
>>> of
>>> > the total SPV population given a relatively small number of nodes. You
>>> > can then use that to harm SPV nodes by, for instance, making a % of
>>> > transactions be dropped deterministicly, either by the bloom matching
>>> > code, or when sent. Users unlucky enough to be surrounded by sybil
>>> nodes
>>> > will have their transactions mysteriously fail to arrive in their
>>> > wallets, or have their transactions mysteriously never confirm. Given
>>> > how few full nodes there are, it probably won't take very many
>>> honeypots
>>> > to pull off this attack, especially if you combine it with a
>>> > simultaneous max connections or bloom io attack to degrade the capacity
>>> > of honest nodes.
>>>
>>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>>> a transaction, make a fake one that pays the same scriptPubKeys with the
>>> same amount, and send it to the SPV peer instead. They'll see the
>>> transaction go through and show up in their wallet, but it'll look like
>>> it got stuck and never confirmed. They'll soon wind up with a wallet
>>> full of useless transactions, effectively locking them out of their
>>> money.
>>>
>>> Here's another question for you Mike: So does bitcoinj have any
>>> protections against peers flooding you with useless garbage? It'd be
>>> easy to rack up a user's data bill for instance by just creating junk
>>> unconfirmed transactions matching the bloom filter.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> 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/20130816/11c9bb99/attachment.html>

2023-06-07 17:06:03

- reply

📅 Original date posted:2013-08-16
📝 Original message:bitcoinj-0.10 release notes:
- We now require Bloom-capable (0.8+) peers by default and will
disconnect from older nodes. This avoids accidental bandwidth saturation on
mobile devices.
Given the user-security concern that Peter brings up, reconsideration of
this new default behavior in SPV clients may be warranted.
On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
> > Doing this also makes it more difficult to sybil the network - for
> > instance right now you can create "SPV honeypots" that allow incoming
> > connections only from SPV nodes, thus attracting a disproportionate % of
> > the total SPV population given a relatively small number of nodes. You
> > can then use that to harm SPV nodes by, for instance, making a % of
> > transactions be dropped deterministicly, either by the bloom matching
> > code, or when sent. Users unlucky enough to be surrounded by sybil nodes
> > will have their transactions mysteriously fail to arrive in their
> > wallets, or have their transactions mysteriously never confirm. Given
> > how few full nodes there are, it probably won't take very many honeypots
> > to pull off this attack, especially if you combine it with a
> > simultaneous max connections or bloom io attack to degrade the capacity
> > of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.
>
> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20130816/6948a457/attachment.html>

2023-06-07 17:06:01

- reply

📅 Original date posted:2013-08-16
📝 Original message:Automatic heuristic driven prioritization, with sane defaults and some
configurable knobs, is exactly what I suggest.
In the short-term though, any connection limits added to the client by
default would be the simplest and easiest protection measure to audit. It
would improve things a lot over the current situation where there are no
limits, and it requires no manual intervention from node operators.
Warren
On Fri, Aug 16, 2013 at 3:46 AM, Mike Hearn <mike at plan99.net> wrote:
> A ban-subnet RPC would be a reasonable addition, but obviously DoS
> attackers that are IP or bandwidth constrained are really just script
> kiddies. Also anything that involves every node operator doing manual
> intervention rather works against decentralisation and having a big
> network. That's why I keep pushing for automated heuristic driven
> prioritisation.
>
>
> On Fri, Aug 16, 2013 at 3:41 PM, Warren Togami Jr. <wtogami at gmail.com>wrote:
>
>>
>> https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
>> *Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
>> If you disallow the same IP and/or subnet from establishing too many TCP
>> connections with your node, it becomes more expensive for attackers to use
>> a single host exhaust a target node's resources. This iptables firewall
>> based example has almost zero drawbacks, but it is too complicated for most
>> people to deploy. Yes, there is a small chance that you will block
>> legitimate connections, but there are plenty of other nodes for random
>> connections to choose from. Configurable per source IP and source subnet
>> limits with sane defaults enforced by bitcoind itself would be a big
>> improvement over the current situation where one host address can consume
>> limited resources of many target nodes.
>>
>> This doesn't remove the risk of a network-wide connection exhaustion
>> attack by a determined attacker, but it at least makes multiple types of
>> attacks a lot more expensive. This also doesn't do much against the io
>> vulnerability, which would require major redesigns to prevent in Bitcoin.
>>
>>
>> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
>> *Want to safely delay the block size limit increase for another year or
>> two?* This patch alone enables that.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> The only other thing I'd like to see there is the start of a new
>>> anti-DoS framework. I think once the outline is in place other people will
>>> be able to fill it in appropriately. But the current framework has to be
>>> left behind.
>>>
>>> If I had to choose one thing to evict to make time for that, it'd be the
>>> whitepapers. At the moment we still have plenty of headroom in block sizes,
>>> even post April. It can probably be safely delayed for a while.
>>>
>>>
>>> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>>> Cool. Maybe it's time for another development update on the foundation
>>>> blog?
>>>>
>>>>
>>>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <
>>>> gavinandresen at gmail.com> wrote:
>>>>
>>>>> Mike asked what non-0.9 code I'm working on; the three things on the
>>>>> top of my list are:
>>>>>
>>>>> 1) Smarter fee handling on the client side, instead of hard-coded
>>>>> fees. I was busy today generating scatter-plots and histograms of
>>>>> transaction fees versus priorities to get some insight into what miner
>>>>> policies look like right now.
>>>>>
>>>>> 2) "First double-spend" relaying and alerting, to better support
>>>>> low-value in-person transactions. Related:
>>>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>>>>>
>>>>>
>>>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the
>>>>> 1MB block size limit, how we can do it safely, and go through all of the
>>>>> arguments that have been made against it and explain why they're wrong.
>>>>>
>>>>> --
>>>>> --
>>>>> Gavin Andresen
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> 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/20130816/7abd0e31/attachment.html>