<unnamed>

Public Key

npub1s5p2xnl52ksr3a4qfa8re5znmja46ugm3x3ayy0x2c2mqrsw6ewsmzxem8

Profile Code

nprofile1qqsg2q4rfl69tgpc76sy7n3u6pfaew6awydcng7jz8n9v9dspc8dvhgpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qe2kdc0

Publishing to

relay.nostr.net

Last Notes

2023-06-07 17:35:42 UTC

- 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 17:35:41 UTC

- 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 15:47:25 UTC

- reply

2023-06-07 15:47:25 UTC

- reply

2023-06-07 15:40:08 UTC

- 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 15:39:32 UTC

- 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 15:37:49 UTC

- 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 15:19:18 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas <kristovatlas at gmail.com>wrote:
> I see that the latest nightly build (thanks for that, Warren) is still not
> compatible with Tails/Debian Squeeze. Is there still an intention to
> address this issue? Might it be fixed by 0.9.2?
>
If I understand the situation, bitcoind does work but not bitcoin-qt due to
qt-4.6? If that is so, then the official Bitcoin 0.8.6 binaries didn't
work on Squeeze either this is not a regression.
The priority is for bitcoind to work on as many distributions as reasonably
possible as older stable distributions are most often headless. If you are
a rare user who needs Bitcoin-Qt on an incompatible system you can at least
build it from source.
Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/b39f21e4/attachment.html>

2023-06-07 15:19:17 UTC

- 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 15:12:14 UTC

- 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 15:10:20 UTC

- reply

📅 Original date posted:2013-12-09
📝 Original message:Our testing of the macos leveldb parts for the past 6 days has had zero
complaints of new corruption from OMG and LTC users. I agree it is time to
release 0.8.6.
On Sun, Dec 8, 2013 at 8:14 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> On Mon, Dec 9, 2013 at 9:07 AM, Warren Togami Jr. <wtogami at gmail.com>wrote:
>
>> I found a tiny error in 0.8.6rc1. The leveldb subtree merge was done
>> incorrectly leaving an errant db/ directory in the base of bitcoin instead
>> of src/leveldb.
>>
>
> I see:
> db/autocompact_test.cc
>
> ... which I assume is a leveldb unit test file that should be in
> src/leveldb/db/
>
> Not a showstopper bug.
>
> Given we've had hundreds of downloads and no reports of insanity, I think
> we should tag v0.8.6 today (same commit as v0.8.6rc1) and ship it.
>
> --
> --
> Gavin Andresen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/3d50bab6/attachment.html>

2023-06-07 15:10:19 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:I found a tiny error in 0.8.6rc1. The leveldb subtree merge was done
incorrectly leaving an errant db/ directory in the base of bitcoin instead
of src/leveldb. See my earlier mail on 0.8.6 for suggested subtree squash
and merge syntax. (On plane now...)
Warren
On Dec 5, 2013 10:53 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> 0.8.6 release candidate 1 is available from:
>
> https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.6/test/
>
> Please help sanity-test, especially if you are running OSX or Windows.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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/20131208/7645b3bc/attachment.html>

2023-06-07 15:08:12 UTC

- reply

📅 Original date posted:2013-10-29
📝 Original message:How about rejection codes to notify you that you have been rate limited?
Warren
On Mon, Oct 28, 2013 at 7:37 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
>
> Thanks for the feedback, everybody, gist updated:
> https://gist.github.com/gavinandresen/7079034
>
> Categories are:
>
> 0x01-0x0f Protocol syntax errors0x10-0x1f Protocol semantic errors0x40-0x4fServer
> policy rule
> <https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types>
>
> RE: why not a varint: because we're never ever going to run out of reject
> codes. Eight are defined right now, if we ever defined eight more I'd be
> surprised.
>
> RE: why not use HTTP codes directly: because we'd be fitting round pegs
> into square holes.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&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/20131028/edd87851/attachment.html>

2023-06-07 15:06:05 UTC

- 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 15:06:04 UTC

- reply

📅 Original date posted:2013-08-16
📝 Original message:I might agree this would be helpful for the many phones plugged into power
and on wifi for large portions of the day. However that doesn't really
help much when phone IP addresses change often as you move onto different
networks, and currently IP address is the only thing that peers can keep
track of for the goodness of a peer as there is no roaming pseudo-identity
cookie due to separate goal of anonymity? I haven't studied the issue if
would be even possible to have both privacy protection and unique node
identifiers for anti-DoS authentication at the same time.
On Fri, Aug 16, 2013 at 4:59 AM, Peter Todd <pete at petertodd.org> wrote:
> The user interface for this stuff is very simple: "How much bandwidth
> will you contribute back? If you contribute more bandwidth back, other
> peers will prioritize you and your wallet will be more reliable."
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000003cfc051263917373a1cab2655994b97c54a625021f52c84658
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/1ad7034c/attachment.html>

2023-06-07 15:06:03 UTC

- 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 15:06:01 UTC

- 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>

2023-06-07 15:06:00 UTC

- reply

📅 Original date posted:2013-08-16
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/c9fbdf46/attachment.html>