[Bitcoin-development] Emergency List Move: Sunday, June 21st, 2015 at 9pm UTC

[Warren Togami Jr.]

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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Membership disabled due to bounces

[Warren Togami Jr.]

Was literally *everyone* unsubscribed?  Sigh.

As much as this is good reason to move the list ASAP, we need both the LF
sysadmin and an existing SF list admin to be online simultaneously to
effect an orderly transition.  We have a scheduled time for this on Tuesday
at 8pm UTC.  I can ask if they are both available now...

Please talk in #bitcoin-dev if you have any opinion on moving the list
sooner.

Warren



On Sun, Jun 21, 2015 at 5:14 AM, Laszlo Hanyecz  wrote:

> I got ~500 uncaught bounce notifications, so it seems like something broke.
>
> On Jun 21, 2015, at 11:00 AM, Matt Whitlock  wrote:
>
> > I too got this message and had to re-enable my membership on the list.
> There's no reason why messages sent by the list to my address would be
> bouncing.
> >
> >
> > On Sunday, 21 June 2015, at 9:06 am, Braun Brelin wrote:
> >> Hi all,
> >>
> >> I got a message saying that my membership in the list was disabled due
> to
> >> excessive bounces.  As far as I can remember,  I've only ever sent out
> one
> >> e-mail on the list (not including this one) and that was a few weeks
> ago.
> >> Has anyone else seen this problem?  Could this be related in some way to
> >> the issues regarding source forge and the mail list hosting issue?
> >>
> >> Braun Brelin
> >
> >
> --
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Membership disabled due to bounces

[Warren Togami Jr.]

I set that password back in 2013 ... shortly after a fun debate that was
largely responsible for my decision to fix up Litecoin.

Thanks Gavin!

On Sun, Jun 21, 2015 at 2:59 AM, Warren Togami Jr. 
wrote:

> I just got this mail ... unclear how mail with my gmail account would be
> causing bounces with this list.
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] confirm 1e595b258d48a8badd07523cbd8a8d74c150803c

[Warren Togami Jr.]

I just got this mail ... unclear how mail with my gmail account would be
causing bounces with this list.

On Sat, Jun 20, 2015 at 8:56 PM, <
bitcoin-development-requ...@lists.sourceforge.net> wrote:

> Your membership in the mailing list Bitcoin-development has been
> disabled due to excessive bounces The last bounce received from you
> was dated 21-Jun-2015.  You will not get any more messages from this
> list until you re-enable your membership.  You will receive 3 more
> reminders like this before your membership in the list is deleted.
>
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
>
>
> https://lists.sourceforge.net/lists/confirm/bitcoin-development/1e595b258d48a8badd07523cbd8a8d74c150803c
>
>
> You can also visit your membership page at
>
>
> https://lists.sourceforge.net/lists/options/bitcoin-development/wtogami%40gmail.com
>
>
> On your membership page, you can change various delivery options such
> as your email address and whether you get digests or not.  As a
> reminder, your membership password is
>
>  GavinIsGreat!
>
> If you have any questions or problems, you can contact the list owner
> at
>
> bitcoin-development-ow...@lists.sourceforge.net
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] IMPORTANT - Bitcoin Dev List Move Tuesday, June 23rd 8pm UTC

[Warren Togami Jr.]

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@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
 which will solve this problem.

Warren Togami
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Warren Togami Jr.]

On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn  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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Warren Togami Jr.]

On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn  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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Mailman incompatibility with DKIM ...

[Warren Togami Jr.]

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

> warren | bad_duck: try manually adding "[Bitcoin-dev] " to the beginning
> of the subject
>
> --
> Arthur
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] FYI - Mailing List Move Preparations

[Warren Togami Jr.]

BTW, if you are posting from a less popular mail server your initial post
to the new list may be delayed by 5+ minutes due to greylisting.  If your
sending SMTP server is behaving properly then posts after the first should
go through without delay.

Warren

On Thu, Jun 18, 2015 at 6:57 PM, Warren Togami Jr. 
wrote:

> After discussions in #bitcoin-dev in the past day we decided it would be a
> bad idea to link the old and new lists in some way during a transition
> period.  We decided we are better off announcing the switchover very soon,
> and after that point all posts to the old list will be rejected with a
> message telling them where to find the new list.
>
> The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
> an exact scheduled time for the move probably tomorrow.  At the time of the
> switchover, the old list will reject all messages, archives will be
> exported and imported into the new list server, then the new list will be
> opened.
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Please subscribe now and feel free to make test posts.  We are testing
> configuration options to fix some long standing spam filter-related
> issues.  Any posts to the new list prior to the final switchover will be
> wiped from the archives.
>
> If you have opinions on this, please join us in Freenode #bitcoin-dev and
> talk to warren.
>
> Warren Togami
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] FYI - Mailing List Move Preparations

[Warren Togami Jr.]

After discussions in #bitcoin-dev in the past day we decided it would be a
bad idea to link the old and new lists in some way during a transition
period.  We decided we are better off announcing the switchover very soon,
and after that point all posts to the old list will be rejected with a
message telling them where to find the new list.

The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
an exact scheduled time for the move probably tomorrow.  At the time of the
switchover, the old list will reject all messages, archives will be
exported and imported into the new list server, then the new list will be
opened.

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Please subscribe now and feel free to make test posts.  We are testing
configuration options to fix some long standing spam filter-related
issues.  Any posts to the new list prior to the final switchover will be
wiped from the archives.

If you have opinions on this, please join us in Freenode #bitcoin-dev and
talk to warren.

Warren Togami
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[Warren Togami Jr.]

On Sun, Jun 14, 2015 at 5:19 PM, Warren Togami Jr. 
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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[Warren Togami Jr.]

On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik  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.

 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
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[Warren Togami Jr.]

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Warren Togami Jr.]

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  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. 
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev 
> 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  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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Warren Togami Jr.]

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Warren Togami Jr.]

On Mon, May 25, 2015 at 1:29 PM, Andreas Schildbach
 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

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] About watch-only addresses

[Warren Togami Jr.]

https://bitcointalk.org/index.php?topic=320695
I made a branch of Bitcoin 0.9.3 plus backports including watch-only and a
huge pile of patches cleaning it up from the master branch.  It seems to
work fine although it is not heavily tested.  I suppose if you use ONLY for
watch-only it can't be harmful?  Dunno.

Warren

On Sat, Oct 18, 2014 at 12:13 AM, Wladimir  wrote:

> On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon
>  wrote:
> > Hi,
> >
> > What is the status of watch-only addresses in Bitcoin Core? Is it merged
> in
> > master and usable? Is there documentation on how to add a watch-only
> address
> > through RPC.
>
> It has been merged. There is the "importaddress" RPC call, which works
> the same as "importprivkey" except that you a pass it an address.
>
> > Also, I believe that is going towards the 0.10 release, is there a rough
> ETA
> > for a release candidate?
>
> Yes - aim is in a few months, probably by the end of the year.
>
> AFAIK there are no nightly builds at this moment. Warren Togami was
> building them for a while (at http://nightly.bitcoin.it/) but he
> stopped some time around June.
>
> It's not recommended to use master without at least a little bit of
> development/debugging experience of yourself (to trace down problems
> when they appear), so it's best to build it yourself if you're going
> to test day-to-day development versions.
>
> Wladimir
>
>
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core Nightly Builds

[Warren Togami Jr.]

https://bitcointalk.org/index.php?topic=571414.0
Thanks to the efforts of Cory Fields, Bitcoin Core now has deterministic
builds for MacOS X.  The nightly builder now has Windows, Linux and MacOS X
test builds available for download.

Warren


On Wed, Apr 16, 2014 at 3:43 PM, Warren Togami Jr. wrote:

> The Bitcoin Core developers have a desire to do a mostly bug-fix, cleanup
> and translation update release in v0.9.2 a few weeks from now.  You do not
> need to be a developer to help!  With these unofficial nightly builds,
> power users can more easily aid in testing of the master branch which will
> help to find bugs and polish things up faster.  Additionally translators
> can more easily run the latest code and see what strings need to be
> translated as we rapidly approach the next stable release.
>
> https://bitcointalk.org/index.php?topic=571414.0
> Read more details here.
>
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] 0.9.2 RC postponed for 7 days

[Warren Togami Jr.]

The release candidate for 0.9.2 was previously scheduled for May 13th.
 Yesterday it was decided to postpone this for 7 days due to the Bitcoin
2014 Amsterdam conference.  The string freeze is now in effect and it is a
very good time to contribute
translationsduring
these next 7 days.

In Related News ...
http://nightly.bitcoin.it now has separate builds for the master and 0.9.2
branch.  0.9.2 is what will soon become the release while master is
accepting changes that may not be safe for a near-term release.  Read
details  about
deterministic reproducibility of the unofficial nightly builds.

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Regtest Address Version Change Proposal

[Warren Togami Jr.]

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  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. 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--
"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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Regtest Address Version Change Proposal

[Warren Togami Jr.]

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Translators Needed for Bitcoin Core

[Warren Togami Jr.]

https://www.transifex.com/projects/p/bitcoin/
This is a reminder that many languages still require translation coverage.
 See this page to see the percentage of strings translated into a given
language.  The 0.9.2 release candidate is currently scheduled for May 13th
with translations accepted for the release for at least a week after that.

Even if you do not speak other languages, you can help by pointing other
people who do at this page.

Warren


On Wed, Apr 23, 2014 at 7:47 PM, Warren Togami Jr. wrote:

> 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).
>
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

[Warren Togami Jr.]

On Wed, Apr 23, 2014 at 10:02 PM, Wladimir  wrote:

> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell 
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. 
> 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
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Translators Needed for Bitcoin Core

[Warren Togami Jr.]

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).
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

[Warren Togami Jr.]

On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas 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
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

[Warren Togami Jr.]

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

Warren Togami
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bit

[Bitcoin-development] Bitcoin Core Nightly Builds

[Warren Togami Jr.]

The Bitcoin Core developers have a desire to do a mostly bug-fix, cleanup
and translation update release in v0.9.2 a few weeks from now.  You do not
need to be a developer to help!  With these unofficial nightly builds,
power users can more easily aid in testing of the master branch which will
help to find bugs and polish things up faster.  Additionally translators
can more easily run the latest code and see what strings need to be
translated as we rapidly approach the next stable release.

https://bitcointalk.org/index.php?topic=571414.0
Read more details here.

Warren Togami
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Warren Togami Jr.]

On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes  wrote:

>
> Either the transaction fees are sufficient to pay the cost for whatever
> random junk anyone wants to put there, or they are not, and if they are
> not, then I suggest you re-think the fee structure rather than trying
> to pre-regulate me putting 80 character pithy quotes in the blockhain.
>
>
https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d

In one way in particular, the transaction fees per kilobyte completely
failed to account for the actual cost to the network.  If Bitcoin had
adopted a common-sense rule like this, I would have had no reason to join
Litecoin development last year.  This is one of the few economic design
flaws that Satoshi overlooked in the original design.

As much as I personally hate the idea of data storage in the blockchain,
this at least discourages the creation of permanent UTXO.

Warren Togami
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Warren Togami Jr.]

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Peer Discovery and Overlay

[Warren Togami Jr.]

I was concerned about this issue so we sponsored BlueMatt to implement an
address database for bitcoinj.  In the future it won't be entirely reliant
on what DNS tells it.

Warren

On Tue, Dec 24, 2013 at 6:02 AM, Peter Todd  wrote:

> As for node addresses being a service, that's what the DNS seeds are!
> bitcoinj clients, for instance, depend very heavily on those seeds and
> can be easily compromised in a variety of ways by them.
>
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 0.8.6 release candidate 1

[Warren Togami Jr.]

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

> On Mon, Dec 9, 2013 at 9:07 AM, Warren Togami Jr. 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
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 0.8.6 release candidate 1

[Warren Togami Jr.]

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"  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coin Control, Send crash on MacOS X

[Warren Togami Jr.]

On Sun, Dec 1, 2013 at 1:19 AM, Wladimir  wrote:

> On Sun, Dec 1, 2013 at 12:05 PM, Warren Togami Jr. wrote:
>
>> https://github.com/litecoin-project/bitcoinomg/commits/0.8.5-OMG6
>> http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6/
>> I've been backporting patches from master and Litecoin to make a Bitcoin
>> 0.8 client with more features.  It works quite well on Linux and Win32.
>>
>> http://pastebin.com/g8QqheGc
>> Today we discovered a rare crash that can happen on MacOS X. toffoo and
>> coblee reproduced it on MacOS X 10.9 and I reproduced it on 10.6.8. It
>> seems to be some kind of race condition involving SendCoinsEntry::clear().
>>
>>
>>1. 11  QtGui   0x00e28141
>>QWidget::setFocus(Qt::FocusReason) + 289
>>2. 12  org.bitcoinfoundation.Bitcoin-Qt0x002ca665
>>SendCoinsEntry::clear() + 101
>>
>>
> I don't think the setFocus should be in clear() in the first place. It
> conflates clearing the widgets and changing the focus.
>
> If the automatic focus change is desirable at all it could be moved to a
> seperate function "focusPayTo".
>
> In any case it's just a nicety and should just be removed if it causes
> problems.
>
> Wladimir
>
>
Did as you suggested, removed both setFocus() calls that happen after Send
is clicked

http://pastebin.com/j4adDpsM
Now it crashes in something else within qt.

I'm trying other things...

Warren
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Coin Control, Send crash on MacOS X

[Warren Togami Jr.]

https://github.com/litecoin-project/bitcoinomg/commits/0.8.5-OMG6
http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6/
I've been backporting patches from master and Litecoin to make a Bitcoin
0.8 client with more features.  It works quite well on Linux and Win32.

http://pastebin.com/g8QqheGc
Today we discovered a rare crash that can happen on MacOS X. toffoo and
coblee reproduced it on MacOS X 10.9 and I reproduced it on 10.6.8. It
seems to be some kind of race condition involving SendCoinsEntry::clear().


   1. 11  QtGui   0x00e28141
   QWidget::setFocus(Qt::FocusReason) + 289
   2. 12  org.bitcoinfoundation.Bitcoin-Qt0x002ca665
   SendCoinsEntry::clear() + 101


This build was made with Xcode 3.2.6 on MacOS X with MacPorts qt4-mac
qt-4.8.4, roughly meant to approximate Gavin's build environment for the
0.8.x releases.

With this unfamiliar build environment I have been unsuccessful at building
master so I am unable to confirm if this crash exists there.  I am trying
qt-4.8.5 next ... but even if I manage to build it, it is exceedingly
difficult to reproduce...

Warren
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [PATCH, try2] bitcoind: whitelist nodes against banning

[Warren Togami Jr.]

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

> On Fri, Nov 22, 2013 at 3:56 PM, Gregory Maxwell 
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bounty: MacOS X Bitcoin Corruption Issue

[Warren Togami Jr.]

https://bitcointalk.org/index.php?topic=337294
Since 0.8.x many MacOS X users have been experiencing periodic leveldb data
corruption issues.  While not fatal, it is very time consuming to recover
from this corruption and upsetting that it happens often for some users.
 There have been three commits in Bitcoin that attempted to fix this, one
fsync fix in leveldb, one in util.h, and a leveldb version upgrade to 1.13.
 My guess is that one of these commits fixed other corruption, but there
remains at least one mysterious corruption issue on Mac where leveldb is
corrupted after a clean shutdown of Bitcoin-Qt.  After 5+ months we still
do not know why some users never see corruption while it happens often for
others.

Gavin has pledged 5 BTC, and Litecoin Dev pledges 200 LTC to start this
bounty.  This thread has public addresses for Mac users to donate to
increase the incentive to fix this issue sooner.

To help please contribute detailed bug reports or links to more relevant
background information pertaining to this corruption issue.

https://bitcointalk.org/index.php?topic=320695.0
For testing purposes, please use either Bitcoin git master or Bitcoin 0.8.5
OMG3, both of which contain all of the relevant leveldb fixes.  Testing
without those fixes will not be helpful at this point.

Warren
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

[Warren Togami Jr.]

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 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
> 
>
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] 0.8.5 with libsecp256k1

[Warren Togami Jr.]

https://github.com/sipa/secp256k1
sipa's secp256k1, optimized ecdsa, significantly faster than openssl

Today someone in #bitcoin-dev asked for Bitcoin 0.8.5 with sipa's
secp256k1.  Litecoin has been shipping test builds with secp256k1 for
several months now so it was a simple matter to throw together a branch of
Bitcoin 0.8.5 with secp256k1.

https://github.com/wtogami/bitcoin/commits/btc-0.8.5-secp256k1
This branch should theoretically work for Linux, win32 gitian and mac
builds.  These commits are rather ugly because it was thrown together just
to make it build with the old 0.8 makefiles without intent for production
code merge. cfields is working on autotoolizing it as one of the
prerequisites prior to inclusion into bitcoin master where it will be an
option disabled by default.

http://193.28.235.60/~warren/bitcoin-0.8.5-secp256k1/
Untested win32 gitian build.  Build your own Linux or Mac builds if you
want to test it.  Not recommended for production wallet or mining uses.

Warren
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Code review

[Warren Togami Jr.]

https://www.kernel.org/doc/Documentation/SubmittingPatches
Read the section under "14) Using Reported-by:, Tested-by:, Reviewed-by:
and Suggested-by:". That might be helpful in our process too?

Warren


On Fri, Oct 4, 2013 at 4:31 PM, Gavin Andresen wrote:

> On Fri, Oct 4, 2013 at 8:30 PM, Mike Hearn  wrote:
>
>> I'd like to make a small request - when submitting large, complex pieces
>> of work for review, please either submit it as one giant squashed change,
>> or be an absolute fascist about keeping commits logically clean and
>> separated.
>>
>
> I'll try harder to be a fascist (it doesn't come naturally to me). HUGE
> thanks for taking the time to review the fee changes in detail.
>
> RE: using Review Board:
>
> I'm all for using better tools, if they will actually get used. If a
> potential reviewer has to sign up to create a Review Board account or learn
> Yet Another Tool, then I think it would be counter-productive:  we'd just
> make the pool of reviewers even smaller than it already is.
>
> Are there good examples of other open source software projects
> successfully incentivizing review that we can copy?
>
> For example, I'm wondering if maybe for the 0.9 release and onwards the
> "Thank you" section should thank only people who have significantly helped
> test or review other people's code.
>
> --
> --
> Gavin Andresen
>
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] bitcoind stops responding

[Warren Togami Jr.]

https://github.com/litecoin-project/litecoin/issues/67
0.8.2 apparently was the first Bitcoin version to support RPC keepalive.
 With the 4 RPC thread limit, four keepalive connections will exhaust all
four and prevent further connections.  This issue describes a workaround
where you build with more RPC threads.


On Mon, Sep 30, 2013 at 10:44 AM, slush  wrote:

> Hi,
>
> during several weeks I'm observing more and more frequent issues with
> bitcoind. The problem is that bitcoind stops responding to RPC calls, but
> there's no other suspicious activity in bitcoind log, CPU usage is low,
> disk I/O is standard etc.
>
> I observed this problem with version 0.8.2, but it is still happening with
> 0.8.5. Originally this happen just one or twice per day. Today my
> monitoring scripts restarted bitcoind more than 30x, which sounds alarming.
> This happen on various backends, so it isn't a problem of one specific
> node. Is there anybody else who's observing similar problem?
>
> Thanks,
> slush
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind

[Warren Togami Jr.]

Hence ship a miner that automatically reads the bitcoin.conf to find the
RPC authentication info.  It would be faster and more efficient than the
unoptimized miner while simplifying the bitcoind code.  Win for everyone.

Warren


On Mon, Aug 19, 2013 at 1:02 PM, Andreas Schildbach
wrote:

> On 08/19/2013 10:34 PM, Jeff Garzik wrote:
>
> >> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
> >> people that getwork will be removed in the next major version.
>  Pooler's CPU
> >> minerd which supports both sha256d and scrypt recently grew stratum
> support.
> >> Perhaps he could be convinced to add GBT support too, which would help
> this
> >> goal of completely removing the internal miner and getwork.
> >
> > The internal miner is still actively used for testnet, here.
>
> Here, too. If I'm too impatient to wait for the next block that is.
>
> I think it'd be a pity if the easy way to mine blocks would be removed.
>
>
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind

[Warren Togami Jr.]

FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
people that getwork will be removed in the next major version.  Pooler's
CPU minerd which supports both sha256d and scrypt recently grew stratum
support.  Perhaps he could be convinced to add GBT support too, which would
help this goal of completely removing the internal miner and getwork.

Warren


On Mon, Aug 19, 2013 at 10:23 AM, Gregory Maxwell wrote:

> On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell 
> wrote:
> > I think removing the ability to mine in the stock package would be
> > regrettable,
>
> I am naughty and should clarify.  I had ass.u.me.d that Jeff's patch
> also removed the internal CPU miner, because doing so is necessary for
> actually getting rid of most of the getwork code. It doesn't actually.
>
> Though this doesn't change the fact that the internal miner is mostly
> a pretext for integrated mining.  Since it only really works on
> testnet it also means our testnet testing using it is not a good test
> of the actual production software.  I'd rather remove the internal
> miner too, getting rid of the extra code and complexity, and package
> up a GBT miner which would actually be usable on the mainnet.
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

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  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. 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  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
>>> 0018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>
>>>
>>> --
>>> 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@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 minute

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

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  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
> 003cfc051263917373a1cab2655994b97c54a625021f52c84658
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

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  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
> 0018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>
>
> --
> 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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

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  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. 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  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  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 <
>>>> gavinandre...@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 10

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

[Warren Togami Jr.]

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  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  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 
>> 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*
>>>
>>>
>>> 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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development