Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Wladimir J. van der Laan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


 This kind of thing always happens as projects become larger and more
 diverse.  Something that was once a small group turns into a big
 group of diverse stakeholders.  When it gets too big for the
 informal processes then some people get upset and defensive. Happens
 all the time but it is not really a good excuse to keep doing things
 in an inefficient manner.  The old ways just don't scale and if you
 ever worked on massive projects then you know these formal processes
 work better.

So then: make a proposal for a better process, post it to this list.

In practice there has been zero interest in improving the BIP process.

E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir 
Taaki (in 2009 or so?). It hasn't really changed since then, apart from some 
spelling and grammar corrections. It is not specifically adapted to Bitcoin, 
and doesn't make a distinction between for example, consensus changes and 
non-consensus changes.

So that's up to someone to do. You seem to be enthousiastic about it, so go 
ahead.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH
sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+
U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv
m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5
Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ
llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw=
=dMO9
-END PGP SIGNATURE-

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


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Wladimir J. van der Laan
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote:

 Once a draft BIP has been submitted to bitcoin-development for
 consideration, the Bitcoin Core maintainer will deliver a preliminary
 yes/no verdict within three weeks. This verdict may be informed by the
 debate that has taken part in the previous three weeks. If more time is
 required, the maintainer is required to request an extension from the BIP
 author, who may then elect to force an immediate decision (risking a no),
 or choosing to allow more time.

Again, for the last time: Bitcoin Core maintainer does not decide about 
protocol or consensus level changes.

This is not a role for me. Find someone else, if you think you need an arbiter. 
There was an idea about a Bitcoin Standards Body once, but as far as I know 
that's not actively being worked on.

BTW: for more exposure a proposal is better posted as a new thread, not as a 
deep reply to an existing topic.

Wladimir


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


Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

2015-06-11 Thread Wladimir J. van der Laan
On Wed, Jun 10, 2015 at 09:36:23PM +0300, s7r wrote:
 The mail list is public, so it's not like the data on it is somehow
 sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
 the message and sort/order them as you want, etc.
 
 Why would you want to move to a paid solution? And why would you want
 users to have to pay per message? This is the worst idea ever from my
 point of view. We want to encourage people to join the community, run
 full nodes, ask questions, come with solutions, ideas for improvements
 and so on. Everyone should read and write and contribute as much as
 possible with ideas in debates. You never know who can have bright ideas
 in some contexts.
 
 Bottom line is so far sourceforge handles the mail lists just fine. I
 don't see a single advantage another mail list provider / system could
 offer, except some headache and extra work for migration. The software
 distribution via sourcefoge was cancelled for obvious reasons which I
 fully understand and agree to, but it has nothing to do with the mail
 lists. We have way more important things to brainstorm about.

I completely agree here. I'm not against migration if a much better option 
comes along, but e.g. paying for another provider sounds like nonsense when 
sourceforge does this for free (with some minor annoyances - other providers 
will have their own).

Paying per message is far-fetched, something that could work in economic theory 
with perfectly spherical people in their perfectly efficient market. In 
practice the likely result would be a mailing list only used for advertisement 
and promotion, and technical discussion and release announcements would 
disappear.

BTW for people that *don't* like sourceforge's web archive UI there are some 
other options via gmane:

http://dir.gmane.org/gmane.comp.bitcoin.devel

Wladimir

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


Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

2015-06-10 Thread Wladimir J. van der Laan
On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
 http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

All our downloads (even old ones) have recently been deleted from sourceforge, 
for this reason. They haven't been mentioned in Bitcon Core release 
announcements for a long time.

No opinion on the mailing list. Though I think it's less urgent. The issue of 
moving the mailinglist has come up before a few times and people can't agree 
where to move to.

Wladimir


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


Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-06 Thread Wladimir J. van der Laan
On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
 Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
 assurance contracts among other things. Sometimes the ordering is set by
 the signing logic itself...

But in that case (unconstrained) randomization can't be used either. This is 
posed as an alternative to randomization. So in that regard, the proposal still 
makes sense.
I think this move to verifyable, deterministic methods where possible is good.

Wladimir

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


[Bitcoin-development] Bitcoin core 0.11.0 release candidate 1 available

2015-06-05 Thread Wladimir J. van der Laan
Hello,

I've just uploaded Bitcoin Core 0.11.0rc1 executables to:

https://bitcoin.org/bin/bitcoin-core-0.11.0/test/

The source code can be found in the source tarball or in git under the tag 
'v0.11.0rc1'

Preliminary release notes can be found here:

https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md

Thanks to everyone that participated in development or in the gitian build 
process,

Wladimir


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


[Bitcoin-development] Bitcoin Core 0.9.5 released

2015-05-24 Thread Wladimir J. van der Laan
Bitcoin Core version 0.9.5 is now available from:

  https://bitcoin.org/bin/0.9.5/

This is a new minor version release, with the goal of backporting BIP66. There
are also a few bug fixes and updated translations. Upgrading to this release is
recommended.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

How to Upgrade
===

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Notable changes


Mining and relay policy enhancements


Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its `getblocktemplate` must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.

0.9.5 changelog


- `74f29c2` Check pindexBestForkBase for null
- `9cd1dd9` Fix priority calculation in CreateTransaction
- `6b4163b` Sanitize command strings before logging them.
- `3230b32` Raise version of created blocks, and enforce DERSIG in mempool
- `989d499` Backport of some of BIP66's tests
- `ab03660` Implement BIP 66 validation rules and switchover logic
- `8438074` build: fix dynamic boost check when --with-boost= is used

Credits


Thanks to who contributed to this release, at least:

- 21E14
- Alex Morcos
- Cory Fields
- Gregory Maxwell
- Pieter Wuille
- Wladimir J. van der Laan

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


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


[Bitcoin-development] Bitcoin Core 0.9.5 release candidate 1 tagged

2015-05-19 Thread Wladimir J. van der Laan
Hello,

I've just tagged release candidate 1 for 0.9.5 (tag `v0.9.5rc1`).

The reason for this backport release is to make BIP66 available on the 0.9 
branch. This has been requested by a few users, mostly miners.

Full (preliminary) release notes can be found at: 
https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md

In contrast to 0.10.x releases it is unclear whether there will be enough 
gitian signatures for a binary release, any help with building is welcome.
See https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-process.md
(many steps have changed since then, so the release process for 0.10 or master 
will not work)

Wladimir

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


[Bitcoin-development] Bitcoin Core 0.10.2 released

2015-05-19 Thread Wladimir J. van der Laan


--
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] Bitcoin Core 0.10.2 released

2015-05-19 Thread Wladimir
Bitcoin Core version 0.10.2 is now available from:

  https://bitcoin.org/bin/bitcoin-core-0.10.2/

The distribution is also available as torrent:

   https://bitcoin.org/bin/bitcoin-core-0.10.2/bitcoin-0.10.2.torrent

   
magnet:?xt=urn:btih:746a616aa8de97856c207e7a899c7ee315e8c44ddn=bitcoin-core-0.10.2tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969tr=udp%3A%2F%2Fopen.demonii.com%3A1337ws=https%3A%2F%2Fbitcoin.org%2Fbin%2

The source code can be found in git under the tag `v0.10.2`, or in
`bitcoin-0.10.2.tar.gz` in the distribution.

This is a new minor version release, bringing minor bug fixes and translation
updates. It is only necessary to upgrade to this version when unable
to start the
application on Windows with 0.10.1.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
=

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
--

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes
===

This fixes a serious problem on Windows with data directories that
have non-ASCII
characters (https://github.com/bitcoin/bitcoin/issues/6078).

For other platforms there are no notable changes.

For the notable changes in 0.10, refer to the release notes
at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md

0.10.2 Change log
=

Detailed release notes follow. This overview includes changes that
affect external
behavior, not code moves, refactors or string updates.

Wallet:
- `824c011` fix boost::get usage with boost 1.58

Miscellaneous:
- `da65606` Avoid crash on start in TestBlockValidity with gen=1.
- `424ae66` don't imbue boost::filesystem::path with locale C on
windows (fixes #6078)

Credits
===

Thanks to everyone who directly contributed to this release:

- Cory Fields
- Gregory Maxwell
- Jonas Schnelli
- Wladimir J. van der Laan

And all those who contributed additional code review and/or security research:

- dexX7
- Pieter Wuille
- vayvanne

As well as everyone that helped translating on
[Transifex](https://www.transifex.com/projects/p/bitcoin/).

On Tue, May 19, 2015 at 1:44 PM, Wladimir J. van der Laan
laa...@gmail.com wrote:


--
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] Bitcoin Core 0.10.2 release candidate 1 available

2015-05-14 Thread Wladimir
The subject should obviously be Bitcoin Core 0.10.2 release candidate
1 available, not the other way around,

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


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 2 available

2015-05-14 Thread Wladimir J. van der Laan

Binaries for bitcoin Core version 0.10.2rc1 are now available from:

  https://bitcoin.org/bin/0.10.2/test

Source code can be found on github under the signed tag

  https://github.com/bitcoin/bitcoin/tree/v0.10.2rc1

This is a release candidate for a minor version release, with mainly a fix for
a bug that affected Windows users with non-ASCII characters in the data 
directory.
The release also contains translation updates. 

If you experienced no issues with 0.10.1, there is no need to upgrade.

Preliminary release notes for the 0.10.2 release can be found here:

  https://github.com/bitcoin/bitcoin/blob/v0.10.2rc1/doc/release-notes.md

Release candidates are test runs for releases, when no critical
problems are found this release candidate will be tagged as 0.10.2.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues


--
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] Bitcoin core 0.11 planning

2015-05-11 Thread Wladimir
A reminder - feature freeze and string freeze is coming up this Friday the 15th.

Let me know if your pull request is ready to be merged before then,

Wladimir

On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
laa...@gmail.com wrote:
 Hello all,

 The release window for 0.11 is nearing, I'd propose the following schedule:

 2015-05-01  Soft translation string freeze
 Open Transifex translations for 0.11
 Finalize and close translation for 0.9

 2015-05-15  Feature freeze, string freeze

 2015-06-01  Split off 0.11 branch
 Tag and release 0.11.0rc1
 Start merging for 0.12 on master branch

 2015-07-01  Release 0.11.0 final (aim)

 In contrast to former releases, which were protracted for months, let's try 
 to be more strict about the dates. Of course it is always possible for 
 last-minute critical issues to interfere with the planning. The release will 
 not be held up for features, though, and anything that will not make it to 
 0.11 will be postponed to next release scheduled for end of the year.

 Wladimir

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


[Bitcoin-development] Fwd: Bitcoin core 0.11 planning

2015-05-11 Thread Wladimir
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 As softforks almost certainly require backports to older releases and other
 software anyway, I don't think they should necessarily be bound to Bitcoin
 Core major releases. If they don't require large code changes, we can easily
 do them in minor releases too.

Agree here - there is no need to time consensus changes with a major
release, as they need to be ported back to older releases anyhow.
(I don't really classify them as software features, but properties of
the underlying system that we need to adopt to)

Wladimir

--
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] Block Size Increase

2015-05-07 Thread Wladimir J. van der Laan
 is guided by not only fee pressure, but 
also other reasons such as speed of confirmation, which is unreliable on-chain. 
This eases objection 3b. 

Whew, this grew longer than I expected. To conclude, I understand the 
advantages of scaling, I do not doubt a block size increase will *work* 
Although there may be unforseen issues, I'm confident they'll be resolved. 
However, it may well make Bitcoin less useful for what sets it apart from other 
systems in the first place: the possibility for people to run their own own 
bank without special investment in connectivity and computing hardware. 
Also the politics aspect (at some point it becomes a question of who decides 
for who? who is excluded? all those human decisions...) of this I don't like in 
the least. Possibly unavoidable at some point, but that's something *I*'d like 
to kick down the road.

Wladimir


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


[Bitcoin-development] Bitcoin core 0.11 planning

2015-04-28 Thread Wladimir J. van der Laan
Hello all,

The release window for 0.11 is nearing, I'd propose the following schedule:

2015-05-01  Soft translation string freeze
Open Transifex translations for 0.11
Finalize and close translation for 0.9

2015-05-15  Feature freeze, string freeze

2015-06-01  Split off 0.11 branch
Tag and release 0.11.0rc1
Start merging for 0.12 on master branch 

2015-07-01  Release 0.11.0 final (aim)

In contrast to former releases, which were protracted for months, let's try to 
be more strict about the dates. Of course it is always possible for last-minute 
critical issues to interfere with the planning. The release will not be held up 
for features, though, and anything that will not make it to 0.11 will be 
postponed to next release scheduled for end of the year.

Wladimir

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


[Bitcoin-development] Bitcoin Core 0.10.1 released

2015-04-27 Thread Wladimir J. van der Laan
` Initialization: set fallback locale as environment variable

Credits
===

Thanks to everyone who directly contributed to this release:

- Alex Morcos
- Cory Fields
- dexX7
- fsb4000
- Gavin Andresen
- Gregory Maxwell
- Ivan Pustogarov
- Jonas Schnelli
- Matt Corallo
- mrbandrews
- Pieter Wuille
- Ruben de Vries
- Suhas Daftuar
- Wladimir J. van der Laan

And all those who contributed additional code review and/or security research:
- 21E14
- Alison Kendler
- Aviv Zohar
- Ethan Heilman
- Evil-Knievel
- fanquake
- Jeff Garzik
- Jonas Nick
- Luke Dashjr
- Patrick Strateman
- Philip Kaufmann
- Sergio Demian Lerner
- Sharon Goldberg

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


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


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 3 available

2015-04-21 Thread Wladimir J. van der Laan

I've just uploaded Bitcoin Core 0.10.1rc3 executables to:

https://bitcoin.org/bin/bitcoin-core-0.10.1/test/

The source code can be found in git under the tag 'v0.10.1rc3' on the `0.10` 
branch.

New in this RC is another batch of bug fixes,

- `eae305f` Fix missing lock in submitblock
- `57d1f46` Fix CheckBlockIndex for reindex
- `bac6fca` Set nSequenceId when a block is fully linked
- `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division 
loop
- `323de27` `7494e09` `df45564` Various initialization setup environment locale 
fixes

Full (preliminary) release notes for 0.10.1 can be found at 
https://github.com/bitcoin/bitcoin/blob/v0.10.1rc3/doc/release-notes.md 

Thanks to everyone that participated in development or in the gitian build 
process. I sincerely hope that this can be the final release candidate for 
0.10.1,

Wladimir


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 1 available

2015-04-02 Thread Wladimir J. van der Laan
Binaries for bitcoin Core version 0.10.1rc1 are now available from:

  https://bitcoin.org/bin/0.10.1/test

Source code can be found in github under the tag

  https://github.com/bitcoin/bitcoin/tree/v0.10.1rc1

This is a release candidate for a minor version release, bringing bug fixes and
translation updates. Release candidates are test runs for releases, when no 
critical
problems are found the release candidate will be tagged as 0.10.1.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
=

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
--

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes
===

This is a minor release and hence there are no notable changes.
For the notable changes in 0.10 refer to the release notes for the
0.10.0 release at 
https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md

0.10.1 Change log
=

Detailed release notes follow. This overview includes changes that affect 
external
behavior, not code moves, refactors or string updates.

RPC:
- `7f502be` fix crash: createmultisig and addmultisigaddress

Block (database) and transaction handling:
- `1d2cdd2` Fix InvalidateBlock to add chainActive.Tip to 
setBlockIndexCandidates
- `c91c660` fix InvalidateBlock to repopulate setBlockIndexCandidates
- `002c8a2` fix possible block db breakage during re-index
- `a1f425b` Add (optional) consistency check for the block chain data structures

P2P protocol and network code:
- `78f64ef` don't trickle for whitelisted nodes
- `ca301bf` Reduce fingerprinting through timestamps in 'addr' messages.
- `200f293` Ignore getaddr messages on Outbound connections.
- `d5d8998` Limit message sizes before transfer
- `aeb9279` Better fingerprinting protection for non-main-chain getdatas.
- `cf0218f` Make addrman's bucket placement deterministic (countermeasure 1 
against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/)
- `0c6f334` Always use a 50% chance to choose between tried and new entries 
(countermeasure 2 against eclipse attacks)
- `214154e` Do not bias outgoing connections towards fresh addresses 
(countermeasure 2 against eclipse attacks)
- `aa587d4` Scale up addrman (countermeasure 6 against eclipse attacks)

Validation:
- `d148f62` Acquire CCheckQueue's lock to avoid race condition

Build system:
- `8752b5c` 0.10 fix for crashes on OSX 10.6

Wallet:
- N/A

GUI:
- `2c08406` some mac specifiy cleanup (memory handling, unnecessary code)
- `81145a6` fix OSX dock icon window reopening
- `786cf72` fix a issue where command line options-action overwrite 
Preference-action (on OSX)

Tests:
- `1117378` add RPC test for InvalidateBlock

Miscellaneous:
- `c9e022b` Initialization: set Boost path locale in main thread
- `23126a0` Sanitize command strings before logging them.

Credits
===

Thanks to everyone who contributed to this release:

- Alex Morcos
- Cory Fields
- dexX7
- fsb4000
- Gregory Maxwell
- Ivan Pustogarov
- Jonas Schnelli
- Pieter Wuille
- Ruben de Vries
- Suhas Daftuar
- Wladimir J. van der Laan

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Wladimir
Hello Adam,

On Fri, 20 Feb 2015, Adam Back wrote:

 So I was wondering what about changing to committing a bloom filter of
 the addresses in the block.  Its seems surprising no one thought of it
 that way before (as it seems obvious when you hear it) but that seems
 to address the privacy issues as the user can fetch the block bloom
 filters and then scan it in complete privacy.  (Someone appeared on
 bitcoin wizards IRC a while back and made this observation.)

I have heard this idea of inverting the bloom filter before (possibly in 
#bitcoin-wizards), and as I see it it would indeed improve the privacy. 
Apart from privacy it would also lower the burden for nodes. A block scan 
with bloom filter is effectively a cheap DoS on a node.

In addition to that it will also avoid the 'transaction withholding 
attack' that is possible with the current bloom filtering, at least if the 
filter is e.g. committed to in the block header.

The drawback would be overhead - the bloom filter per block will have a 
significant size (to avoid false positives), and the client would have to 
fetch entire blocks that have its transactions in it.

I don't think that is so bad in practice, after all the % of blocks that 
will have transactions for a given wallet will generally be low, so the 
block size is amortized in a way. Of course, if the block size would be 
increased this would become worse.

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.0 final was tagged

2015-02-13 Thread Wladimir
Hello,

I've just tagged 0.10.0rc4 as final (with a small packaging change to 
avoid tar nastiness). The tag is 'v0.10.0'.

Start your gitian builders!

For a guide on how to do gitian builds see 
https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md

Please wait with a release announcement until there are 3
builders and the binaries have been uploaded.

Cheers,
Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.10.0rc4 tagged

2015-02-06 Thread Wladimir
On Thu, Feb 5, 2015 at 12:33 PM, Wladimir laa...@gmail.com wrote:
 FYI, I've just tagged v0.10rc4, and pushed my signatures to the
 gitian.sigs repository.

 Please start your gitian builders!

Thanks to the extremely quick response (a whopping 9 gitian builders
already!), the executables and tarball for rc4 have been uploaded to
the usual place:

https://bitcoin.org/bin/0.10.0/test/

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-06 Thread Wladimir
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
cryptocurrenc...@quidecco.de wrote:

 A possible approach to handle this issue would be to add a randomized
 offset amount to the payment amount. This offset amount can be small
 in comparison to the payment amount.

 Any thoughts?

Adding/subtracting a randomized offset amount is one way, but there
have also been more sophisticated ideas to obfuscate the amount, e.g.
by adding multiple change outputs or even distributing over multiple
transactions (potentially coinjoined for further privacy).

Mike Hearn had some ideas regarding obfuscation of payment amounts,
which still make sense, and he wrote about them here:
https://medium.com/@octskyward/merge-avoidance-7f95a386692f

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.0rc4 tagged

2015-02-05 Thread Wladimir
FYI, I've just tagged v0.10rc4, and pushed my signatures to the
gitian.sigs repository.

Please start your gitian builders!

Changes relative to rc3:

- 1eb14af Increase block download timeout base from 10 to 20 minutes.
- 3916a81 Increase coverage of DERSIG edge cases
- 6da2028 Add RPC test for DERSIG BIP switchover logic
- 773c30d BIP66 changeover logic
- 18695f0 Example unit tests from BIP66
- abfbeaf Change IsDERSignature to BIP66 implementation
- b6347bf Fix priority calculation in CreateTransaction
- 2448d34 Avoid storing a reference passed to SignatureChecker constructors
- 1bbad80 Use separate SignatureChecker for CMutableTransaction
- 6a02ef8 [Qt] don't allow amount changes when AmountSpinBox is read-only
- b61940b Change Coin Control first column label
- c5044bc sleep-wait on genesis block during init with -reindex
- b24ff47 Make empty byte arrays pass CheckSignatureEncoding()
- ed4206a fix crash: CoinControl space bug
- 58259ad qt: fix broken unicode chars on osx 10.10
- aaf55d2 186a517 Add a -rpckeepalive option to disable RPC use of
HTTP persistent connections.

Hopefully this will be the last release candidate before the 0.10 final release.

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-03 Thread Wladimir
 One way to do that is to just - right now - add a patch to 0.10 to
 make those non-standard. This requires another validation flag, with a
 bunch of switching logic.

 The much simpler alternative is just adding this to BIP66's DERSIG
 right now, which is a one-line change that's obviously softforking. Is
 anyone opposed to doing so at this stage?

Not opposed, but is kind of late for 0.10, I had hoped to tag rc4 today.

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Wladimir


On Mon, 2 Feb 2015, Levin Keller wrote:


Hello everyone,
I think this is my first email to this mailinglist so I will shortly introduce 
myself:

I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin, 
mathematician. Bitcoiner since 2011.

And now the reason for this email: Andreas (Schildbach) just released a new 
update of his wallet. It now provides an export functionality for the m/0' key 
in order to run read only copies
on other devices. We already support the format on our website. Of course we 
would love for this to become standard. I also updated the Wiki article for 
Andreas'
Wallet: https://en.bitcoin.it/wiki/Bitcoin_Wallet


Yes, standardizing on a format could be useful.


How do you like it? How does this format get standard? Shall I try to get a 
pull request to BIP32 passed?


Just administrative trivia: this would be a new BIP, and not an 
amandment to BIP32. Excluding small language errors and 
clarifications in examples, BIPs are not changed after the fact.


Wladimir--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] var_int ambiguous serialization consequences

2015-02-01 Thread Wladimir

On Sun, 1 Feb 2015, Tamas Blummer wrote:

 I wonder of consequences if var_int is used in its longer than necessary 
 forms (e.g encoding 1 as 0xfd0100 instead of 0x01)

In serialize.h lingo you are talking about CompactSize, not VarInt.

CompactSizes indeed have redundancy in their representation, i.e. the same 
number can be represented as up to four different byte sequences.

VARINTs have a different format that (AFAIK) isn't used anywhere in 
the block chain. See WriteVarInt / ReadVarInt. These were designed to 
not have any redundancy in their representation.

 This is already of interest if applying size limit to a block, since 
 transaction count is var_int but is not part of the hashed header or the
 merkle tree.

Are you sure that this is a current concern? Non-canonical CompactSizes 
are forbidden - in serialize.h this is flagged in ReadCompactSize.

Wladimir


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Core 0.9.4 not on bitcoin.org?

2015-02-01 Thread Wladimir

On Sun, 1 Feb 2015, xor wrote:

 Why is that?

v0.9.4 is not really a release, just a tag in git.

It contains merely a workaround for a change in OpenSSL which caused 
problems - see Gregory Maxwell's post.
As the releases are statically built against OpenSSL, it is not
necessary to upgrade if you use releases from bitcoin.org. Hence no change 
on the site.

(but it can be used by people building from source, or distributions 
packages such as the Ubuntu PPA, which unwisely dynamically link OpenSSL)

 Also, is it correct that there wasn't a release candidate before the release?
 Sounds dangerous to me.

Again, there hasn't been any 0.9.4 release, neither a release candidate or 
anything else.
Testing and such should be focused on the 0.10 release candidates.

Wladimir


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?

2015-01-31 Thread Wladimir


On Fri, 30 Jan 2015, Nick Simpson wrote:


This has been discussed before. I believe most people don't expect Bitcoin to 
replace all of the various methods of payment.  Scalability is
always a concern, just not to the level of  Alipay this year (or the next or 
the next for that matter.)


Yes, that about summarizes it.

The block chain is a single channel broadcasted over the entire 
world, and I don't believe it will ever be possible nor desirable to broadcast all the 
world's transactions over one channel.


The everyone-validates-everything approach doesn't scale. It is however
useful to settle larger transactions in an irreversible, zero-trust way. 
That's what makes the bitcoin system, as it is now, valuable.


But it is absurd for the whole world to have to validate every purchase of 
a cup of coffee or a bus ticket by six billion others.


Naively scaling up the block size will get some leeway in the short term, 
but I believe a future scalable payment system based on bitcoin will be 
mostly based on off-blockchain transactions (in some form) or that there 
will be a hierarchical or subdivided system (e.g. temporary or per-locale 
sidechains).


Wladimir--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-01-28 Thread Wladimir

On Wed, 28 Jan 2015, Nicolas DORIER wrote:

 I agree that the use protocol buffer and x509 by BIP70 is a poor choice.

Well x509 is an international standard in common use, you can't do much 
better with regard to portability. Your suggestion about HTTPS makes 
little sense, you do know what TLS uses x509 internally as well?

Re: protocol buffers, I don't know if it's the best possible one, but one 
serialization method had to be picked. If it weren't, we could still have 
still been discussing which one to use by now. Just like for JSON there 
are bindings for many languages.

Though JSON parsers are much more diverse, which people using Bitcoin 
Core's RPC have bumped into e.g. some have some problems 
handling large numbers. Something you wouldn't expect using a 
straightforward binary format. There's no obvious best choice.

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-27 Thread Wladimir

On Mon, 26 Jan 2015, Gregory Maxwell wrote:

 On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com 
 wrote:
 On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com 
 wrote:
 I therefore propose a softfork to make non-DER signatures illegal
 (they've been non-standard since v0.8.0). A draft BIP text can be
 found on:

 https://gist.github.com/sipa/5d12c343746dad376c80

 I'd like to request a BIP number for this.

 Sure. BIP0066. There was also some feedback on Bitcointalk, which I
 think you've addressed

Progress information for the list: there is now a pull request
implementing the strict DER verification behavior, as well as the
deployment specified in BIP66 for Bitcoin Core. It needs
your review and testing:

https://github.com/bitcoin/bitcoin/pull/5713

Wladimir

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [ANN] 0.10.0rc3 has been tagged

2015-01-13 Thread Wladimir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On Mon, Jan 12, 2015 at 3:28 PM, Wladimir laa...@gmail.com wrote:
 On Mon, Jan 12, 2015 at 11:31 AM, Wladimir laa...@gmail.com wrote:

 If you build from source, and have already built rc2, there is no
 reason to build rc3.

0.10.0rc3 executables have been uploaded to https://bitcoin.org/bin/0.10.0/test

Wladimir

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJUtYo5AAoJEHSBCwEjRsmmGZkH/j51NRB/qJpIFuqz8fQo+ojI
3ZX3Njgcs8mwGcJrOqURJTuLYkj/FVCIsgvIrfCDAkWssxSh320vdktSj6vfBL4T
t0IlOHZI+vCXEB6OW+guIF9huae5OHMnuxzxcVye8dJEMrQ76Zm9CmubyOTsvZCn
eSDHIqjdu9ygbrPdGXiVQAZ1YVVV2KtHTU+AVGLPkw6EfclefXgVPm3Sp+78LJl7
ZBwgr+NpZQesOh+bIafeJLeEbMfqjOHGzZrh66dTgxhw7Eyd7QpnsRehmRozKGtg
g7FPepeDRC1tRElJlzaHn1+V61YHEj6dADCLrZ57gSXPljlnXCWo4YfAF5D6IfQ=
=yml9
-END PGP SIGNATURE-

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-12 Thread Wladimir
On Sat, Jan 10, 2015 at 12:18 PM, Ivan Jelincic para...@archlinux.info wrote:
 Is openssl1.0.1j unaffected?

Yes. It concerns CVE-2014-8275.

Which in https://www.openssl.org/news/openssl-1.0.1-notes.html is under:

Major changes between OpenSSL 1.0.1j and OpenSSL 1.0.1k [8 Jan 2015]

Wladimir

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [ANN] 0.10.0rc2 has been tagged

2015-01-12 Thread Wladimir
I've just tagged 0.10.0rc2 in git.

To fetch, build, and test (see also doc/build-*.md):
```
git clone -b v0.10.0rc2 https://github.com/bitcoin/bitcoin.git bitcoin-0.10
cd bitcoin-0.10
./autogen.sh
./configure
make
make check
```

Note: This includes the changes required for interoperability with
OpenSSL 1.0.1k.

Notable changes relative to v0.10.0rc1:

- 4e7c219 Catch UTXO set read errors and shutdown
- a3a7317 Introduce 10 minute block download timeout
- 12b7c44 Improve robustness of DER recoding code
- 76ce5c8 fail immediately on an empty signature
- 2d375fe depends: bump openssl to 1.0.1k
- ace39db consensus: guard against openssl's new strict DER checks
- 263b65e tests: run sanity checks in tests too
- e2677d7 Fix smartfees test for change to relay policy
- b7a4ecc Build: Only check for boost when building code that requires it
- 867c600 Catch LevelDB errors during flush
- 008138c Bugfix: only track UTXO modification after lookup
- 3022e7d Require sufficent priority for relay of free transactions
- 06fdf32 bitcoin-tx: Fix JSON validation of prevtxs
- 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data
- 94b362d On close of splashscreen interrupt verifyDB
- 1eadfd9 Bugfix: prioritisetransaction: Do some basic sanity checking on txid
- 18021d0 Remove bitnodes.io from dnsseeds.
- b790d13 English translation update
- 8543b0d Correct tooltip on address book page
- 87d43a3 rpcserver: attempt to fix uncaught exception.
- 06ca065 Fix CScriptID(const CScript in) in empty script case

Wladmir

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-10 Thread Wladimir
On Sat, Jan 10, 2015 at 4:26 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
 https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
 (versions of this will be backported to other stable branches soon)

For those that build from source, patches to cope with the new OpenSSL
versions are now available on stable branches 0.8, 0.9 and rc branch
0.10:

0.8 branch (on top of 0.8.6)

https://github.com/bitcoin/bitcoin/tree/0.8
https://github.com/bitcoin/bitcoin/commits/0.8

To fetch, build, and test:
```
git clone -b 0.8 https://github.com/bitcoin/bitcoin.git bitcoin-0.8
cd bitcoin-0.8/src
make -f makefile.unix
make -f makefile.unix check
```

0.9 branch (on top of 0.9.3+)

https://github.com/bitcoin/bitcoin/tree/0.9
https://github.com/bitcoin/bitcoin/commits/0.9

To fetch, build, and test:
```
git clone -b 0.9 https://github.com/bitcoin/bitcoin.git bitcoin-0.9
cd bitcoin-0.9/src
./autogen.sh
./configure
make
make check
```

0.10 branch (on top of 0.10.0rc1+)

https://github.com/bitcoin/bitcoin/tree/0.10
https://github.com/bitcoin/bitcoin/commits/0.10

```
git clone -b 0.10 https://github.com/bitcoin/bitcoin.git bitcoin-0.10
cd bitcoin-0.10/src
./autogen.sh
./configure
make
make check
```

Wladimir

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin 0.10.0c1 available for download

2014-12-27 Thread Wladimir
Signed executables are available for 0.10.0 release candidate 1, at

https://bitcoin.org/bin/0.10.0/test/

Preliminary release notes for the 0.10 release can be found here:
https://github.com/bitcoin/bitcoin/blob/0.10/doc/release-notes.md

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Cheers,
Wladimir

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] ACK NACK utACK Concept ACK

2014-12-17 Thread Wladimir
On Wed, Dec 10, 2014 at 3:45 PM, Austin Walne austin.wa...@gmail.com wrote:
 I've had these same questions myself. I'm happy to write up some 
 documentation this afternoon. I can draft something based on this thread. 
 What other key terminology should be included?

Fanquake already started on that (but didn't even mention it here!)
https://github.com/bitcoin/bitcoin/pull/5468

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Open development processes and reddit charms

2014-12-17 Thread Wladimir
 I don't care which tabbing style or column width you pick, but **pick one**,
 and enforce it across the entire codebase.

See https://github.com/bitcoin/bitcoin/pull/5387

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Wladimir
 While it would be nice to have a library encapsulating the consensus code, 
 this
 shouldn't come at the cost of safety, especially when the actual users of that
 library or their needs is still uncertain.

While I agree that it shouldn't come at unreasonable risk, my whole
reason for prioritizing the consensus library is that it is the first
step toward the goal of isolating the consensus code completely. As
soon as it exists in a repository by itself, it is easier to enforce a
different regime of change control there, or even freeze it completely
over time. To keep track of consensus changes one'd only have to
follow that repository, instead of filter it between tons of GUI, RPC
or utility commits.

IMO having the consensus isolated into a portable self-contained
library is the most important goal of Bitcoin Core project at this
point. I've tried to keep the amount of unnecessary refactoring down,
but some is unfortunately unavoidable.

I'm sure we can find a way to rebase CHECKLOCKTIMEVERIFY so that it
can land in 0.11.

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] ACK NACK utACK Concept ACK

2014-12-10 Thread Wladimir
On Wed, Dec 10, 2014 at 6:47 AM, Wladimir laa...@gmail.com wrote:
 Abbreviations:

 Concept ACK - agree with the idea and overall direction, but haven't
 reviewed the code changes nor tested it
 utACK - reviewed the code changes, but did not put it through any testing
 Tested ACK - reviewed the code changes and verified the functionality/bug fix

And there is also NACK, that's an aspecific 'I wouldn't like this
merged'. I always explain why in the text.

A document on this would be welcome, as it may look like Martian to
outsiders. That's been brought up many times before, but no one ever
created it.

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] ACK NACK utACK Concept ACK

2014-12-09 Thread Wladimir
Abbreviations:

Concept ACK - agree with the idea and overall direction, but haven't
reviewed the code changes nor tested it
utACK - reviewed the code changes, but did not put it through any testing
Tested ACK - reviewed the code changes and verified the functionality/bug fix

I tend to only use bare ACK if there is nothing to test in the first
place, for example for documentation changes.

Wladimir


On Tue, Dec 9, 2014 at 9:30 PM, Matt Corallo bitcoin-l...@bluematt.me wrote:
 Also utACK (untested ack) and tested ack when people are being explicit.

 On 12/09/14 21:14, Sergio Lerner wrote:
 Is that the full terminology or are there more acronyms?
 Is this documented somewhere?

 Best regards,
  Sergio.



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-27 Thread Wladimir
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
 Since this attack vector has been discussed, I started making some
 measurements on how effective it is to connect to Bitcoin using Tor,
 and I found that the number of connections dropping to near-zero is
 a situation which occurs rather frequently, which suggests that there
 is still room to improve on the DoS handling.

 I'm confused by this, I run quite a few nodes exclusively on tor and
 chart their connectivity and have seen no such connection dropping
 behaviour.

In my experience the problem has always been getting bootstrapped.
Most nodes hardly give any hidden service nodes in their getaddr.
(this has been improved in master by including a set of hidden service
seed nodes)
But this assumes -onlynet=tor. Tor with exit nodes should be less
problematic, unless someone managed to DoSban all the exit nodes as
described in the paper (but I've never seen such an attack myself).

 Can you tell me more about how you measured this?

 [As an aside I agree that there are lots of things to improve here,
 but the fact that users can in theory be forced off of tor via DOS
 attacks is not immediately concerning to me because its a conscious
 choice users would make to abandon their privacy (and the behaviour of
 the system here is known and intentional). There are other mechanisms
 available for people to relay their transactions than connecting
 directly to the bitcoin network; so their choice isn't just abandon
 privacy or don't use bitcoin at all.]

Right, there's something to be said for splitting your own transaction
submission from normal P2P networking and transaction relay.
(esp for non-SPV wallets which don't inherently leak any information
about their addresses)

There was a pull request about this for Bitcoin Core one, maybe I
closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 .

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoind as a library

2014-11-27 Thread Wladimir
On Thu, Nov 27, 2014 at 5:27 PM, Mem Wallet memwallet.i...@gmail.com wrote:

 Is there an intention that the various internal libraries could/should
 be strengthened and heirachicalized such that they would be suitable for
 3rd party development of bitcoin related services and tools, or is that not
 a goal, and some other project would have to fill such a role ?

The plan is to provide the consensus functionality as a library, the
essential parts that make bitcoin bitcoin.
0.10 will have a basic transaction/script verifier available.
In the version after that, I expect this will be extended to further
utxo set management, but no API has been worked out for that yet.
There are also plans to add a library for transaction signing.

However there is no goal to expose *everything* as a library.
Certainly not wallet- or user interface related functionality.
Specialized utility libraries would fill this purpose better.
See for example https://github.com/bitcoin/libbase58 for base58 processing.

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Wladimir
On Sun, Nov 16, 2014 at 5:21 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
 Hi,

 The data that can be embedded as part of an OP_RETURN output is currently
 limited to 40 bytes. It was initially supposed to be 80 bytes, but got
 reduced to 40 before the 0.9 release to err on the side of caution.

 After 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe,

Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
about the actual size.

(rationale: pruning is going to land soonish, and everything is better
than UTXO-polluting methods that encode everything into addresses such
as now used by cryptograffiti)

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [ann] Live Bitcoin Core commits on #bitcoin-commits

2014-11-13 Thread Wladimir
All,

As of now you can join #bitcoin-commits on freenode to be notified of
commits to the bitcoin/bitcoin repository. Thanks to Luke-Jr for
telling me how to set this up.

Regards,
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://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-07 Thread Wladimir
On Fri, Nov 7, 2014 at 12:30 PM, Clément Elbaz clem...@gmail.com wrote:
 Thinking out loud here : would it make sense to separate the consensus code
 into some kind of Bitcoin Kernel (similar to the Linux Kernel) project
 that could be used by anyone ?

Yes, we're moving in that direction. First with a script verification
library in 0.10, which will be extended to other parts of the
consensus by 0.11 and after that.

Wladimir

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


Re: [Bitcoin-development] Bug in genbuild.sh ?

2014-11-03 Thread Wladimir
On Mon, Nov 3, 2014 at 10:16 AM, Francis GASCHET f...@numlog.fr wrote:
 Hello,

 I just compiled bitCoin core on Debian 7.
 I got an error message too many arguments when executing genuid.sh
 I fixed it as shown hereafter and it worked fine.


 pcfg:~/bitcoinCore diff -u shareOLD/genbuild.sh share/genbuild.sh
 --- shareOLD/genbuild.sh2014-11-03 08:32:08.950708258 +0100
 +++ share/genbuild.sh   2014-11-03 08:38:44.626698114 +0100
 @@ -16,7 +16,7 @@
   DESC=
   SUFFIX=
   LAST_COMMIT_DATE=
 -if [ -e $(which git 2/dev/null) -a $(git rev-parse
 --is-inside-work-tree 2/dev/null) = true ]; then
 +if [ -e $(which git 2/dev/null) -a $(git rev-parse
 --is-inside-work-tree 2/dev/null) = true ]; then
   # clean 'dirty' status of touched files that haven't been modified
   git diff /dev/null 2/dev/null

ACK

FYI there's an issue for this on github:
https://github.com/bitcoin/bitcoin/pull/5141 , but Rebroad's solution
contains a new error. Will merge your patch.

Wladimir

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


Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Wladimir
On Sun, Oct 26, 2014 at 9:53 AM, Luke Dashjr l...@dashjr.org wrote:
 On Sunday, October 26, 2014 7:57:12 AM Wladimir wrote:
 Let me know if there is anything else you think is ready (and not too
 risky) to be in 0.10.

 At the very least, we need:
   #5106 Bugfix: submitblock: Use a temporary CValidationState to determine ...
   #5103 CreateNewBlock and miner_tests: Also check generated template is ...
   #5078 Bugfix: CreateNewBlock: Check that active chain has a valid tip ...
 (or at least some conclusion for the problem discussed therein)

OK

 Harmless/No reason not to have:
   #3727 RPC: submitblock: Support for returning specific rejection reasons
   #1816 Support for BIP 23 block proposal
   #5144 Qt: Elaborate on signverify message dialog warning
   #5071 Introduce CNodePolicy for putting isolated node policy code and ...
 (futher commits exist that should ideally get in after this is merged)

ACK on the UI change,

I think it would be best to let the full-blown miner policy class
wait for 0.11.

 Debatable (but harmless, and miners seem to want it):
   #5077 Enable customising node policy for datacarrier data size with a ...

OK, that's a low-risk change, it just makes what is now a constant configurable.

Wladimir

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


Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Wladimir
On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho
melvincarva...@gmail.com wrote:

 Firstly, apologies in coming in late to the conversation.  As I am also
 working on a REST API for electronic coins.  Some questions:

 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST output
 e.g. the response format and MIME types.  Or just compile from source?

See the opening post from @jgarzik, it has some documentation on how
to use the API.

It would be nice to have some write-up about the current functionality
in the release notes, but there currently is none.

It's a RPC-side change, not a P2P-side change so it doesn't require a BIP.

 2. How set in stone is v1 of the the going forward?  PS I support @maaku's
 comments re: /api/v1/ -- tho I guess it is too late for that now.
 3. Would there be any support to develop this interface into something that
 would be W3C standards compliant, or reviewed by the REST community.  So for
 example a context can be provided to self document the terms (something I've
 almost completed) and would allow standardization of block explorer and
 bitcoind outputs.  Right now every explorer seems to have a different JSON
 output.

It's not too late, it's not been merged yet.

Though a W3C standard takes a long time to pan out, and it may be more
useful to have this available rather than wait for the API to be
standardized (which means this will need to be postponed at least one
version). As you say, a new interface be added later under another
URI.

Note that we're only interested in exposing read-only, public data
which is already available in Bitcoin Core's internals.
We're not aiming to add a fully-fledged block explorer with (say)
address indexes. Although that could be part of the standard if it
allows implementations to support just a subset.

Anyhow - please coordinate this with Jeff Garzik, it's better to work
together here.

Wladimir

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


[Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-26 Thread Wladimir
Now that headers-first is merged it would be good to do a 0.10 release
soon. Not *too* soon as a major code change like that takes some time
to pan out, but I'd like to propose the following:

- November 18: split off 0.10 branch, translation message and feature freeze
- December 1: release 10.0rc1, start Release Candidate cycle

That leaves three weeks until the freeze. After the release and branch
split-off, the RC cycle will run until no critical problems are found.
For major releases this is usually more painful than for stable
releases, but if we can keep to these dates I'd expect the final
release no later than January 2015.

Let's aim to have any pending development for 0.10 merged before
November 18. Major work that I'm aware of is:

- BIP62 (#5134, #5065)
- Verification library (#5086, #5118, #5119)
- Gitian descriptors overhaul, so that Gitian depends = Travis depends (#4727)
- Autoprune (#4701)
- Add warmup mode for RPC server (#5007)
- Add unauthenticated HTTP REST interface (#2844)

Let me know if there is anything else you think is ready (and not too
risky) to be in 0.10. You can help along the development process by
participating in testing and reviewing of the mentioned pull requests,
or just by testing master and reporting bugs and regressions.

Note: I intended the 0.10 release to be much sooner. The reason that
this didn't pan out is that I insisted on including headers-first, and
this took longer than expected. There seems to be a preference to
switch to a fixed (instead of feature-based) 6-month major release
schedule, ie

- July 2015: 0.11.0 (or whatever N+1 release is called)
- January 2016: 0.12.0 (or whatever N+2 release is called)
- July 2016: 0.13.0 (or whatever N+3 release is called)

Wladimir

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


Re: [Bitcoin-development] BIP process

2014-10-19 Thread Wladimir
On Sun, Oct 19, 2014 at 9:17 AM, xor x...@freenetproject.org wrote:

 So as a random stranger to the project, I would vote against that if I was
 allowed to. There really should be *more* discussion here, and splitting the
 list up won't help with that.

The problem is not one of traffic, but of confusion of concerns, and of focus.

That specific questions about Bitcoin Core are being asked, for
example about watch-only functionality, in the same list where changes
to the entire system (BIPs) should be decided on doesn't make sense.

This has in practice caused some developers of alternative clients to
not subscribe to this list, even though they *should* follow BIP
discussion otherwise it makes no sense to have a process in the first
place.

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


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

2014-10-18 Thread Wladimir
On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon
flavien.char...@coinprism.com 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


Re: [Bitcoin-development] Proposed BIP status changes

2014-10-16 Thread Wladimir

 Shouldn't we be doing this in a GitHub PR rather than spamming up the ML?

Not really. BIP changes should be discussed on the mailing list,
that's the way to get community consensus (as specified in BIP1).

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


[Bitcoin-development] BIP process

2014-10-15 Thread Wladimir
Hello,

I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.

A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.

Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.

I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.

Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.

B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.

bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).

This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.

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


[Bitcoin-development] Proposed BIP status changes

2014-10-15 Thread Wladimir
These BIPs should go to Final state - they are implemented all over
the place, and are thus entirely fixed in place now. Any changes would
require a new BIP as amandment:

- BIP 14 (BIP Protocol Version and User Agent)

- BIP 21 (URI Scheme)

- BIP 22 (getblocktemplate - Fundamentals)

- BIP 31 (Pong Message)

- BIP 34 (Block v2, Height in coinbase)

- BIP 35 (mempool message)

- BIP 37 (Bloom filtering)

Let me know if you (don't) agree.

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


Re: [Bitcoin-development] BIP process

2014-10-15 Thread Wladimir
 This all makes a lot of sense to me, and would help a lot with the
 workflow.  Unfortunately github pulls and issues really have nothing
 to faciltate a multistage workflow... e.g. where something can go
 through several steps.

Indeed, pull requests don't have a status.
It would be possible to (ab)use labels for this.

The drawback of labels is that only the repository team can set these,
there is no way to delegate. But I suppose it'd be possible to build
something on top of the github API that handles this.

 We're also having problems with people failing to comment on things,
 not even I looked at this and have no opinion, which is really
 obstructing things.

Well - the only way to avoid that is to set a reasonable deadline,
after which there is a default decision. You'd hope this would
motivate people to get involved in time.

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


Re: [Bitcoin-development] Malleable booleans

2014-10-14 Thread Wladimir
On Tue, Oct 14, 2014 at 9:27 AM, Thomas Zander tho...@thomaszander.se wrote:
 On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote:
 This means that scripts that use booleans as inputs will be inherently
 malleable.

 I've ran into this issue in C++ often enough,
 a funny example is assigning 2 to a native c++ bool and then you can do a
  if (myBool == true)
  else if (myBool == false)
 and neither of them will hit.

Off topic nit: I think you're confused with custom BOOL typedefs in C?
C++ booleans are protected against this (C++ standard §4.7/4 according
to Google).:

```
#include stdio.h

int main()
{
bool myBool;
myBool = 2;
if (myBool == true)
printf(It is true!\n);
else if (myBool == false)
printf(It is false!\n);
else
printf(It is something else!\n);
}
```

Prints 'It is true'. You can also use bool(something) as equivalent of
`x != 0`; as in `assert(bool(2) == true);`.

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


Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-12 Thread Wladimir
On Sun, Oct 12, 2014 at 10:41 AM, Geir Harald Hansen
opera...@bitminter.com wrote:
 On 12.10.2014 01:34, Pieter Wuille wrote:
 * No orphan blocks stored in memory anymore (reducing memory usage during 
 sync).

 Will this slow down reorgs after a fork, compared to today?

Why would you think so? Orphan blocks are blocks whose parent is not
known. In the case of a reorganization the client 'jumps' to a new
best chain, for this to happen the original tip and the new best tip
and all their parents must be already known.

Wladimir

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
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] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-08 Thread Wladimir
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote:
 That is easy to change; I'll submit a pull request.


 That's certainly a useful improvement. It won't help the existing userbase
 though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.

The next minor release (0.9.4) could have Gavin's change already.

I don't think CHECKLOCKTIMEVERIFY will make it into the next major
release though. Once headers-first and pruning is merged (which is
expected to be a matter of weeks). I'd like to split off the 0.10
branch and give it some time to stabilize with a feature freeze, then
do a release before the end of the year.

So 0.11, in say 6 months, would be soonest.

Wladimir

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoinj 0.12

2014-10-03 Thread Wladimir
On Fri, Oct 3, 2014 at 2:49 PM, Mike Hearn m...@plan99.net wrote:
 I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most
 popular Bitcoin libraries. It is used by at least four Android wallets,
 three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp,
 Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets,
 for academic research projects and much more.

Congrats on the release!

Wladimir

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [ann] Bitcoin Core 0.9.3 has been released

2014-09-27 Thread Wladimir
Bitcoin Core version 0.9.3 is now available from:

  https://bitcoin.org/bin/0.9.3/

This is a new minor version release, bringing only bug fixes and updated
translations. Upgrading to this release is recommended.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
==

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings


The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

0.9.3 Release notes
===

RPC:
- Avoid a segfault on getblock if it can't read a block from disk
- Add paranoid return value checks in base58

Protocol and network code:
- Don't poll showmyip.com, it doesn't exist anymore
- Add a way to limit deserialized string lengths and use it
- Add a new checkpoint at block 295,000
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections
- Remove a useless millisleep in socket handler
- Stricter memory limits on CNode
- Better orphan transaction handling
- Add `-maxorphantx=n` and `-maxorphanblocks=n` options for
control over the maximum orphan transactions and blocks

Wallet:
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet

GUI:
- fix 'opens in testnet mode when presented with a BIP-72 link with no fallback'
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX

Miscellaneous:
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see
https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no
critical issues for Bitcoin Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms

Credits


Thanks to everyone who contributed to this release:

- Andrew Poelstra
- Cory Fields
- Gavin Andresen
- Jeff Garzik
- Johnathan Corgan
- Julian Haight
- Michael Ford
- Pavel Vasin
- Peter Todd
- phantomcircuit
- Pieter Wuille
- Rose Toomey
- Ruben Dario Ponticelli
- shshshsh
- Trevin Hofmann
- Warren Togami
- Wladimir J. van der Laan
- Zak Wilcox

As well as everyone that helped translating on
[Transifex](https://www.transifex.com/projects/p/bitcoin/).

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [ann] Bitcoin Core 0.9.3 rc2 is available for download

2014-09-18 Thread Wladimir
FYI rc2 has been uploaded last weekend to
https://bitcoin.org/bin/0.9.3/test/, with some further fixes in
network and memory behaviour

- Remove a useless millisleep in socket handler
- Stricter memory limits on CNode
- Better orphan transaction handling
- Add `-maxorphantx=n` and `-maxorphanblocks=n` options for
control over the maximum orphan counts

Wladimir

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-13 Thread Wladimir
On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk m...@coinqy.com wrote:
 If you do so, please make sure the length of the hash is included in the 
 PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an 
 authenticated way of knowing the expected length of the hash, a MITM attacker 
 can just truncate the hash to lower security.

But if they can truncate they can just as well pass a completely
different hash that matches their payment request. If an attacker can
change the bitcoin: URI, this scheme is broken.

The point of the proposal is to make sure that the payment request
matches the URI. So *if* you communicate the URI by secure means, this
authenticates the associated payment request as well, even if fetched
by insecure means (such as http:...) itself.

Wladimir

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Wladimir
On Fri, Sep 12, 2014 at 11:29 AM, Andreas Schildbach
andr...@schildbach.de wrote:
 This is the discussion post corresponding to this PR:
 https://github.com/bitcoin/bips/pull/106

 Amend BIP72 by an h parameter, which contains a hash of the
 PaymentRequest message that is fetched via the r parameter.

 The hash is meant to link the trust anchor (e.g. the QR code) to the
 payment request message in a secure way. This will solve the problem
 several apps are comparing address+amount fields as a workaround
 instead, preventing some advanced BIP70 usecases. When these apps read a
 matching hash, they need not compare any of the other fields.

Sounds like a good idea to me.

I had no idea that some clients were comparing addresses and amounts
in the URI with the payment request for security, that seems like a
hacky and inflexible way. This is much better.

Wladimir

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [ann] Bitcoin Core 0.9.3 rc1 is available for download

2014-08-28 Thread Wladimir
Bitcoin Core version 0.9.3rc1 is now available from:

  https://bitcoin.org/bin/0.9.3/test/

This is a release candidate (test version) for a new minor version
release, bringing
only bug fixes and updated translations.

Please report bugs using the issue tracker at github:

  https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading
==

How to Upgrade
--

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings


The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

0.9.3 Release notes
===

RPC:
- Avoid a segfault on getblock if it can't read a block from disk
- Add paranoid return value checks in base58

Protocol and network code:
- Don't poll showmyip.com, it doesn't exist anymore
- Add a way to limit deserialized string lengths and use it
- Add a new checkpoint at block 295,000
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections

Wallet:
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet

GUI:
- fix 'opens in testnet mode when presented with a BIP-72 link with no fallback'
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX

Miscellaneous:
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see
https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no
critical issues for Bitcoin Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms

Credits


Thanks to everyone who contributed to this release:

- Andrew Poelstra
- Cory Fields
- Jeff Garzik
- Johnathan Corgan
- Julian Haight
- Michael Ford
- Pavel Vasin
- Peter Todd
- Pieter Wuille
- Rose Toomey
- Ruben Dario Ponticelli
- Trevin Hofmann
- Wladimir J. van der Laan
- Zak Wilcox

As well as everyone that helped translating on
[Transifex](https://www.transifex.com/projects/p/bitcoin/).

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-23 Thread Wladimir
On Sat, Aug 23, 2014 at 1:38 PM, Pieter Wuille pieter.wui...@gmail.com 
wrote:

 Note that we're generally aiming (though not yet enforcing) to have
 merges done through the github-merge tool, which performs the merge
 locally, shows the resulting diff, compares it with the merge done by
 github, and GnuPG signs it.

Indeed. I always use that look at and test and the merges locally
before pushing them. I never use the github merge button.

I'd recommend other people to do so as well - and as can be seen with
`git log --show-signature` it's common practice.

For browsing git history locally I find gitk to be a useful tool.

I'd absolutely encourage for more people to review code changes. Even
better if a few people do this through local tooling instead of the
web page. But my gut feeling is that hosting the code on github
results in many more eyes on the code overall than would be when
requiring *everyone* to use local tools. It's easy to let paranoia get
in the way of actual effectiveness.

Wladimir

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-20 Thread Wladimir
On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes ho...@hozed.org wrote:

 If bitcoin wants to become irrelevant, then by all means, continue to
 depend on github and all the unknown attack surface it exposes.

 Those of us that do run our own servers will migrate to higher quality
 alternatives.

So that means you're volunteering to run a web-accessible mirror of
the bitcoin repositories?

Wladimir

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Wladimir
On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
 It would be nice if the issues and git repo for Bitcoin Core were not
 on such a centralized service as github, nice and convenient as it is.

Despite my complaining about github, I don't like the idea of moving
somewhere else. The current way of working - to use github for storing
the tree, and use a custom script for signing+merging - is fine with
me.

Github has a low barrier to contribution. Almost every open source
developer already has a github account. Switching to something
self-hosted makes it more difficult for people to contribute.

Plus if we have to take the hosting upon ourselves, we have to handle
sysadmin work ourselves as well. That's not a good use of the limited
manpower available.

Also it will be a lot of work to migrate over all the current issues
and pulls. I don't look forward to that. I don't see the point of
this, sorry.

Wladimir

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


Re: [Bitcoin-development] What is the danger if bitcoind startted with -flushwallet=false ?

2014-08-13 Thread Wladimir
On Wed, Aug 13, 2014 at 6:22 PM, 潘庆庆 qingqing@okcoin.com wrote:
 Hi everybody,

 I tried to reduce the IO of bitcoind, and I found '-flushwallet=false'. 
 After trying it, my IO reduced greatly.
 But why 'flushwallet' is true by default? Is there any danger if closing 
 the flush wallet thread?
 I lost all my coins in testnet after one crash with '-flushwallet=false', 
 was this because of no flush wallet thread?

When flushwallet is disabled, the wallet is not flushed (written to
disk in a self-contained state) periodically. This means that there's
a larger chance that the wallet database is in inconsistent state when
the process stops unexpectedly. This can happen either due to a crash,
or an external cause such as the power turning off unexpectedly.

With the wallet in non-self-contained state, the next time that you
start bitcoind BerkeleyDB will have to process log files. There is a
non-zero chance that this will fail and manual recovery is needed.

As the wallet is usually critical, it is unwise to disable that option.

Wladimir

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


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn m...@plan99.net wrote:
 Given that we're not running out of service bits and service bits mean you
 don't have to try connecting to every node to find out what services it
 supports, why not keep using the existing extension mechanism until we start
 running out of bits?

He wants to use it to advertise services that are not part of the P2P
protocol itself, but run on a different port. Reserving services bits
for those is not acceptable.

All the NODE_EXT_SERVICES bit does is advertise the P2P getextsrv
command to get information, such as the port to connect on, for the
auxilary service.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote:
 He wants to use it to advertise services that are not part of the P2P
 protocol itself, but run on a different port. Reserving services bits
 for those is not acceptable.


 Why not? Does the port matter much?

Yes. The services bits are for advertising services on the P2P
network. That's not open for discussion.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote:
 On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote:
 He wants to use it to advertise services that are not part of the P2P
 protocol itself, but run on a different port. Reserving services bits
 for those is not acceptable.


 Why not? Does the port matter much?

 Yes. The services bits are for advertising services on the P2P
 network. That's not open for discussion.

It also wouldn't work. A bit is not enough to find an external service
except in the naive case where the advertised service would have a
fixed port. Not even bitcoind has a fixed port. So there needs to be a
mechanism to find how to connect to the 'external service'. This is
provided by the proposed extension.

It would in principle be possible to advertise an extra service bit
*in addition to* this one, to make it easier to find through the addr
mechanism. But it  would be confusing and IMO an abuse of P2P service
bits.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
 Generally agreed, though for ZMQ it is a bit different than a P2P service.

 IMO, ZMQ really wants to be a plug-in that registers some internal
 signals.  It wants to capture the precise points where a block was
 accepted internally.  PR #4599 tries to lead by example:
 https://github.com/bitcoin/bitcoin/pull/4599

 A P2P service would be a slightly different sort of plug-in.

ZeroMQ is just a lightweight message routing system. It could just as
well make P2P messages available to other applications (if they
subscribe to them). The other way around, routing messages from ZeroMQ
to certain P2P clients, is easy.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net wrote:
 Something like `getutxos` or this proposal could be implemented as an
 external application or script, instead of having to integrate
 everything into bitcoind.


 Right, although getutxos needs access to the UTXO set which bitcoind already
 has. An external plugin would have to recalculate it from scratch which
 seems redundant.

Well to play the devil's advocate, you could set it up to query the
information back over RPC :-)

But yeah, I didn't mean getutxos specifically, it has a trivial
implementation anyway.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net wrote:
 Maybe, that feels like it could be overkill though. Probably just something
 like

 ./bitcoind -servicecookie=long random string -allowextservices=127.0.0.1/8

I don't like conflating the external and internal interface. The
interface to the outside and the interface to the inside should be
well-separated.

I'd be OK with such an idea if bitcoind listens on a separate port for
connections from plugins, a port that cannot be used for normal P2P
traffic. This could also be a UNIX socket instead of a TCP port.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin development (testing where to get Wallet code)

2014-07-30 Thread Wladimir
On Wed, Jul 30, 2014 at 12:32 AM, Caleb Roger Davis moab...@gmail.com wrote:
 I have several Bitcoin contributions I would like to make, mostly for
 learning purposes to get started:

 I would like to contribute to unit and/or other types of tests (code), not
 production code.

Low-level unit tests are in `src/test`. These use the boost
unit-testing framework. You can run them with 'make check' or
`src/test/test_bitcoin`.

High-level RPC tests are in `qa/rpc-tests`. These are Python scripts
that can be invoked manually, and are based on our own simple
framework.

There is also a java-based 'comparison tool' that tests high-level
behavior with regard to the block chain. It is based on bitcoinj and
acts as an external node. This is not part of the github bitcoin
repository itself, but of bitcoinj (AFAIK).

 I would like to understand the Bitcoin code (as much as possible from top to
 bottom)

See https://www.bitcoin.org/en/developer-guide

 I would like to write a Bitcoin wallet in another language (so would like to
 know where to get the Bitcoin - Core Wallet code, but not sure where it
 resides.

All of the wallet code is in `src/wallet.cpp` and `src/walletdb.cpp`.
If the purpose is just studying, the bitcoin core wallet is not the
most readable wallet code around, and also hard to port as it relies
on a full node in the same process. It's better to look at SPV
wallets, for example the bitcoinj-based ones.

 I am a seasoned software developer, but I do need direction on where to get
 started.  If there is a wiki doc for new developers that would reduce my
 searching and experimentation that would be great.

Something like that would be useful, yes.

 For each of the three items above, I would like to know the tools and
 frameworks I would need to understand and initially work on tests ( how to
 run the existing tests to get code coverage and find where coverage is
 needed, what is the preferred IDE and full development stack etc ), and also
 where to get started looking at the bitcoin core code and also the wallet
 code (where is the initial starting point and then I could trace from there
 ).

If you want to work on Bitcoin Core, a Linux box (or VM) is the best
development environment. Getting started building on WIndows or Mac is
harder (but possible). There is work in progress to make building the
dependencies easier for those.

Wladimir

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abusive and broken bitcoin seeders

2014-07-30 Thread Wladimir
 The version message helpfully tells me my own IP address but not theirs ;p

Try -logips. Logging peer IPs was disabled by default after #3764.

BTW I'm seeing the same abusive behavior. Who is running these? Why do
the requests need to be so frequent?

Wladimir

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Wladimir
We've established a few basic rules for the DNS seeds as used in the
Bitcoin Core software. See below.

If you run one of the DNS seeds please reply to this and let us know
whether you agree to these terms. if you think some requirements are
unreasonable let us know too. If we haven't heard from you by
2014-08-04 we will remove your DNS seed from the list of defaults.

Expectations for DNSSeed operators


Bitcoin Core attempts to minimize the level of trust in DNS seeds,
but DNS seeds still pose a small amount of risk for the network.
Other implementations of Bitcoin software may also use the same
seeds and may be more exposed. In light of this exposure this
document establishes some basic expectations for the expectations
for the operation of dnsseeds.

0. A DNSseed operating organization or person is expected
to follow good host security practices and maintain control of
their serving infrastructure and not sell or transfer control of their
infrastructure. Any hosting services contracted by the operator are
equally expected to uphold these expectations.

1. The DNSseed results must consist exclusively of fairly selected and
functioning Bitcoin nodes from the public network to the best of the
operators understanding and capability.

2. For the avoidance of doubt, the results may be randomized but must not
single-out any group of hosts to receive different results unless due to an
urgent technical necessity and disclosed.

3. The results may not be served with a DNS TTL of less than one minute.

4. Any logging of DNS queries should be only that which is necessary
for the operation of the service or urgent health of the Bitcoin
network and must not be retained longer than necessary or disclosed
to any third party.

5. Information gathered as a result of the operators node-spidering
(not from DNS queries) may be freely published or retained, but only
if this data was not made more complete by biasing node connectivity
(a violation of expectation (1)).

6. Operators are encouraged, but not required, to publicly document
the details of their operating practices.

7. A reachable email contact address must be published for inquiries
related to the DNSseed operation.

If these expectations cannot be satisfied the operator should
discontinue providing services and contact the active Bitcoin
Core development team as well as posting on bitcoin-development.

Behavior outside of these expectations may be reasonable in some
situations but should be discussed in public in advance.



See
https://github.com/bitcoin/bitcoin/pull/4566

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-19 Thread Wladimir
On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen gavinandre...@gmail.com wrote:
 Two more half-baked thoughts:

 We should be able to assume that the majority of transaction data (except
 for coinbase) has already been propagated. As Jeff said, incentivizing nodes
 to propagate transactions is a very good thing (the signature cache already
 gives a small incentive to miners to propagate and not 'hoard'
 transactions).

Maybe a stupid idea - but couldn't we make that assumption a surety by
starting the 'set synchronization process' as soon as the miner starts
crunching on a certain block, instead of when it broadcasts it? So the
peers are prepared, and the actual block broadcast is just the header
+ coinbase tx.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Small update to BIP 62

2014-07-18 Thread Wladimir
On Fri, Jul 18, 2014 at 5:14 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
 Hi all,

 I've sent a pull request to make a small change to BIP 62 (my
 anti-malleability proposal) which is still a draft; see:
 * https://github.com/bitcoin/bips/pull/90 (the request)
 * https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)

 It makes two of the 7 new rules mandatory in new blocks, even for
 old-style transactions. Both are already non-standard since 0.8.0, and
 have no use cases in my opinion.

Looks good to me.

 The reason for this change is dropping the requirement for signature
 verification engines to be bug-for-bug compatible with OpenSSL (which
 supports many non-standard encodings for signatures). Requiring strict
 DER compliance for signatures means any implementation just needs to
 support DER.

This is certainly a good thing. Not even OpenSSL is guaranteed to be
bug-for-bug compatible with its own prior versions forever, so better
to strictly define what is allowed.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 38 NFC normalisation issue

2014-07-16 Thread Wladimir
On Wed, Jul 16, 2014 at 11:29 AM, Mike Hearn m...@plan99.net wrote:
 Yes sorry, you're right, the issue starts with the null code point. Python
 seems to have problems starting there too. It might work if we took that
 out.

Forbidding control characters, at least anything  32 makes a lot of
sense to me. Carriage returns, linefeeds, formfeeds, null characters,
I see no valid reason to allow them and lots of reasons they could
cause havoc.

PILE OF POO or GRINNING CAT FACE WITH SMILING EYES should be allowed
in this day and age though.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Wladimir
On Tue, Jul 15, 2014 at 10:00 AM, Jeff Garzik jgar...@bitpay.com wrote:
 Proxying another's idea, from CoinSummit.

 The request:   It would be useful to limit the lifetime of a bitcoin
 address.  Intentionally prevent (somehow) bitcoins being sent to a
 pubkey/pkh after the key expires.

Payment request expiration was meant to address this.

Adding an optional expiration timestamp to addresses would be
possible, however, it would be a non-backward-compatible change and
lots of software would have to be changed at this point.

In my opinion encouraging the use of the payment protocol and
deprecating the use of addresses is the best way forward, and not just
for this reason.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Wladimir
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik jgar...@bitpay.com wrote:
 On Tue, Jul 15, 2014 at 4:19 AM, Wladimir laa...@gmail.com wrote:
 There are major gaps that the payment protocol doesn't cover.

 There are several deployed use cases where you are provided/request an
 address, an API provides one, and one or more incoming payments arrive
 as the user sends them over minutes/hours/days/weeks.

Couldn't these services return a payment message instead of an address?

I agree that there is currently an UI issue here: there is no way in
current wallets to store a payment message and pay to it later. We
will need something like that for recurring payments as well.

Bitcoin addresses were never designed with extensibility in mind.
Before the payment protocol there have been lots of ideas to add
functionality to them, but the underlying idea that they have to be
handled by users manually means that they have to be as short as
possible, which is a conflicting aim with extensibility...

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-07-14 Thread Wladimir
 As a loose description of the protocol for newbies it's an invaluable
 resource and perhaps we should link to it from the developer guide.

It has already been linked from the developer guide for quite a while,
under Additional Resources.

Wladimir

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck#174;
Code Sight#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Anyone still using SOCKS4?

2014-07-07 Thread Wladimir
On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla
odinn.cyberguerri...@riseup.net wrote:
 Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention
 of leaking of information?

SOCKS4a (unlike SOCKS4) supports doing DNS lookups on the server, but
it is not supported by bitcoin core. So it is not part of this
discussion.

And SOCKS5 can do all of that just as well. But if you feel like
contributing SOCKS4a support that's fine with me.

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Anyone still using SOCKS4?

2014-07-04 Thread Wladimir
On Wed, Jun 11, 2014 at 5:39 PM, Wladimir laa...@gmail.com wrote:

 If no one screams fire, we plan on removing support for it in the next
 major release, for two reasons:

 - It would remove some crufty, hardly tested code paths

 - SOCKS5 offers better privacy as it allows DNS redirection

Another one:

- SOCKS5 supports IPv6

Last call...

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] About the small number of bitcoin nodes

2014-06-30 Thread Wladimir
 - Create a grafical interface for bitcoind on Linux servers:
 Create a command, for example bitcoind show that shows a nice summary in
 your Terminal (Console) with all the data that a node administrator wants to
 know.
 When I say grafical interface I mean like top command, an interface made
 out of characters in ASCII.

FYI someone created this! It's still in the initial stages, I'm sure
the author could use some help to grow this into a full-functional
node admin tool.

https://github.com/azeteki/bitcoind-ncurses

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
 The question is; what does this buy us, and is it worth the potentially huge
 amount of time it could take? My gut feeling is we have bigger fish to fry.
 There's plenty of work to do just on the core consensus code, making Bitcoin
 Core into a competitive wallet as well would be an additional burden.

I don't intend to work on that myself but that's up to the people that
want to contribute to that. Once it's a separate project it could
either be a big success, or it could slowly wither away. It can have a
release cycle separate from the node. Likely faster.

The organizational reason to split off the wallet is to get rid of
that responsibility (and code) from the bitcoind repo. Maintaining a
wallet should not be part of maintaining the core infrastructure. But
just deleting it would be unreasonable.

 However I may be quite biased, as I am the maintainer of what is primarily a 
 wallet library :)

Hah. I've thought about that migration path as well.

From my experience the main thing people are missing with BitcoinJ is
a quick and easy way to set up a wallet as a daemon, to use the
functionality from non-java through RPC.

But there are other interesting upcoming wallet projects as well, for
example CoinVault.

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón jti...@monetize.io wrote:
 On 6/24/14, Mike Hearn m...@plan99.net wrote:
ou did want to separate the wallet code from the full node then that'd be
 the way to do it.

 Exactly, this is part of my point, the qt-wallet does not support SPV
 operation at this point, and that complex work should be done after
 the wallet is separated. Thus the first version of the separated
 wallet should be functionally equivalent to today's wallet, that is, a
 full node wallet (even though I understand Wladimir's arguments
 against full-node wallets).

Do mind that some of the steps on the path of bitcoind towards SPV are
also useful in general. For example, headers-first allows parallel
block download, which would solve a lot of sync issues people are
having - a much higher priority than the wallet.

But anyhow I'm describing how I would do it. If you're going to do it,
you can do it in any order that you want. As we're talking about a
separate project here it's not even clear who will be maintainer.

 2) That doesn't necessarily mean that optionally maintaining
 additional indexes in the core is not interesting for some use cases
 (interesting for bitcoind, I don't care much if electrum-server
 currently does this and more [with more dependencies]). Although
 Pieter thinks that should also be separated into an index node too,
 but I think that's another discussion.

I don't understand your argument against Electrum here. Dependencies?
Come on, that's a matter of software distribution. If that really
bothers you I suppose you could contribute to Electrum server so that
it has less deps. It doesn't make the protocol worth any less.

Although Pieter and I disagree with regard to issue #4351, we agree on
wanting to keep (or at least making) bitcoind as lean as possible.
Maintaining extra indices for others doesn't fit in there - that's
also why the address index patch was not merged. An 'index node' could
be a different animal.

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Wladimir
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn m...@plan99.net wrote:
 priority. So a single unified program that just figures it out automatically
 rather than expecting users to assemble a bag of parts seems a goal worth
 striving for.

As I've said before -- and I think we disagree here - I like moving
towards a bag of parts of specialized tools, maintained by people that
specialize in those tools, instead of a single project that aims to do
and know everything. This encourages experimentation  and makes
competition possible and I think that is healthy in this space.

Bitcoin has a strict need for consensus in the block chain format,
scripting system and validation. Outside of those, innovation should
be possible without any gatekeeper bottleneck or even widespread
agreement. Wallets, what data to store on disk, what indices to
maintain. But even P2P message extensions, as long as it doesn't
interfere with the rest of the network.

After an experiment is successful it could always be merged into
bitcoin core. But then the 'what-ifers' have less ammo, as it has been
tested in the real world.

For user convenience it's still possible to package pre-assembled
bags. But that doesn't need to figure into how things are developed.

Wladimir

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-23 Thread Wladimir
On Mon, Jun 23, 2014 at 11:50 AM, Jorge Timón jti...@monetize.io wrote:
 I know there are plans to separate the wallet from the core code and I
 think it's a great idea that will result in cleaner and more modular
 software.
 But it seems like my assumptions on how this would be done may be incorrect.

 I was assuming that the wallet would consume data from a trusted
 bitcoind core node using rpc or a better interface like an http rest
 api (see PR #2844).

It's least surprising if the wallet works as a SPV client by default.
Then, users can use it without first setting up a core. Thus the idea
would be to use P2P primarily.

There could be a mode to use a trusted core by RPC for
mempool/conflicted transaction validation and such. But I'm not sure
about this - as we've seen, pure-SPV wallets work pretty well. If you
want it to act as an edge router you can point a SPV wallet at your
trusted core as well.

There are no plans for adding Electrum-like functionality to bitcoind.
There is already Electrum. Let's not reinvent any wheels.

 So the core would take care of the hard consensus stuff, and the
 wallet would maintain its own database with private keys, addresses,
 balances, etc. and would consume some data contained in bitcoind's
 database.

Right, the wallet would keep track of those.

 I also assumed that the interface between wallet and core would
 include queries to the UTXO (see PR #4351) and maybe TXO (see PR
 #3652) for getting the historic balances.

 As said, I'm not sure these assumptions are true anymore so I ask.
 Is this the plan?
 Is the plan that the wallet will use the p2p directly and maintain its
 own chain database?

It does not need to keep a full chain database. But it needs its own
record of the chain, headers-only + what concerns the keys in the
wallet.

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use

2014-06-18 Thread Wladimir
On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik jgar...@bitpay.com wrote:
 I wrote a patch for string-based name extensions, circa 2011-2012.  I
 agree that is preferable to unreadable bits, for reasons you cite.

 However, it was noted that extensions (or UUIDs etc.) would not be
 propagated around the network in addr messages, as service bits are.

Thanks for letting me know, I didn't remember your patch.

Ugh, yes, propagating all extensions in `addr` messages is not how I
imagined this to work.

But then there would need to be an alternative way to discover nodes
that offer a certain extension. Alas, this moves it from a
straightforward and common sense change to a significant change to the
protocol.

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use

2014-06-17 Thread Wladimir
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir laa...@gmail.com wrote:
 On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock b...@mattwhitlock.name 
 wrote:
 On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
 Yes, as I said in the github topic
 (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
 string-based name space for extensions.

 Why use textual strings? These fields are not for human consumption. Why not 
 use UUIDs, which are fixed length and will not waste as much bandwidth in 
 the protocol? Or if you'd prefer a hierarchical namespace, you could use 
 OIDs, a la ASN.1.

Also it IS useful for these fields to be human readable for
statistics, peer list views and such. When encountering a new, unknown
extension when connecting to a node it's much more useful to get a
google-able string to find out what it is about, than some long
hexadecimal or dotted-number identifier.

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released

2014-06-17 Thread Wladimir
 events while client is running
- Optionally add third party links to transaction context menu
- Check for !pixmap() before trying to export QR code (avoids crashes
when no QR code could be generated)
- Fix Start bitcoin on system login

Miscellaneous:

- Replace non-threadsafe C functions (gmtime, strerror and setlocale)
- Add missing cs_main and wallet locks
- Avoid exception at startup when system locale not recognized
- Changed bitrpc.py's raw_input to getpass for passwords to conceal
characters during command line input
- devtools: add a script to fetch and postprocess translations

Credits


Thanks to everyone who contributed to this release:

- Addy Yeow
- Altoidnerd
- Andrea D'Amore
- Andreas Schildbach
- Bardi Harborow
- Brandon Dahler
- Bryan Bishop
- Chris Beams
- Christian von Roques
- Cory Fields
- Cozz Lovan
- daniel
- Daniel Newton
- David A. Harding
- ditto-b
- duanemoody
- Eric S. Bullington
- Fabian Raetz
- Gavin Andresen
- Gregory Maxwell
- gubatron
- Haakon Nilsen
- harry
- Hector Jusforgues
- Isidoro Ghezzi
- Jeff Garzik
- Johnathan Corgan
- jtimon
- Kamil Domanski
- langerhans
- Luke Dashjr
- Manuel Araoz
- Mark Friedenbach
- Matt Corallo
- Matthew Bogosian
- Meeh
- Michael Ford
- Michagogo
- Mikael Wikman
- Mike Hearn
- olalonde
- paveljanik
- peryaudo
- Philip Kaufmann
- philsong
- Pieter Wuille
- R E Broadley
- richierichrawr
- Rune K. Svendsen
- rxl
- shshshsh
- Simon de la Rouviere
- Stuart Cardall
- super3
- Telepatheic
- Thomas Zander
- Torstein Husebø
- Warren Togami
- Wladimir J. van der Laan
- Yoichi Hirai

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released

2014-06-17 Thread Wladimir
On Tue, Jun 17, 2014 at 4:27 PM, Jesus Cea j...@jcea.es wrote:
 On 17/06/14 11:46, Wladimir wrote:
 Under Ubuntu 10.04:

 jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-qt
 ./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol:
 _ZN10QTextCodec11validCodecsEv

Did it work with the release candidate?

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Going to tag 0.9.2 final

2014-06-14 Thread Wladimir
On Sat, Jun 14, 2014 at 7:58 AM, Un Ix slashdevn...@hotmail.com wrote:
 Was joking, but isn't the translation process back-ended with runtime tests 
 to ensure that any stray chars etc cause the application to fail?

There is some postprocessing done in the script that fetches
translation files (see
https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/update-translations.py
). It removes stray control characters, but for example there is no
check for number and presence of formatting characters. I generally
check that by manually looking through the diffs. But would be great
if someone added that.

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Going to tag 0.9.2 final

2014-06-14 Thread Wladimir
On Sat, Jun 14, 2014 at 7:42 AM, Un Ix slashdevn...@hotmail.com wrote:
 How about a prize for anyone who can spot any malicious strings within next 
 hour?

 ;-)

Hah, if there was to be a prize I'd rather have people looking out for
icebergs than for wrongly arranged deck chairs :-)

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Going to tag 0.9.2 final

2014-06-13 Thread Wladimir
It cannot, it is just data.

Wladimir
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Anyone still using SOCKS4?

2014-06-11 Thread Wladimir
Hello all,

Is anyone using a SOCKS4-only proxy with Bitcoin Core? SOCKS5 was
introduced in 1996, so there is hardly an excuse to not support it.

If no one screams fire, we plan on removing support for it in the next
major release, for two reasons:

- It would remove some crufty, hardly tested code paths

- SOCKS5 offers better privacy as it allows DNS redirection

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] 0.9.2rc2 tagged, gitian builds needed

2014-06-10 Thread Wladimir
Hello,

This Friday I tagged 0.9.2rc2, with the following changes compared to 0.9.2rc1:

- #4282: cwallet init fix
- #4295: upgrade OpenSSL to 1.0.1h
- #4261: Use pnode-nLastRecv as sync score

We still need more gitian builds - I'd like to do the 0.9.2 final
release end of this week as I haven't seen any new problems reported,
but it'd be useful to get these last-minute fixes tested too.

Wladimir

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   3   >