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
htt
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 SIGNED MESSAGE-
Hash: SHA512
On Thu, Jun 18, 2015 at 03:49:06PM +0200, Mike Hearn wrote:
> One reason I keep banging on about *process* and how Wladimir needs to be
> The Decider is that the current attempt at "process" is so vague, not only
> is it unexplain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Jun 18, 2015 at 02:29:42PM +0200, Pieter Wuille wrote:
> On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan
> wrote:
>
> > Like in any open source project there is lots of decision making ability
> > for code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Jun 18, 2015 at 01:14:09PM +0200, Wladimir J. van der Laan wrote:
> On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
>
> > Core is in the weird position where there's no decision making ability at
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
> Core is in the weird position where there's no decision making ability at
> all, because anyone who shows up and shouts enough can generate
> 'controversy', the
n build process,
Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJVgoeFAAoJEHSBCwEjRsmmkggH/3jyzuPXDpUpCpfzyDZDW4CO
GRqIZwCa8vY9Gv9T0mX5jLXOfXpPAMyzWnCz2Eqh0hRLHK8WzObPqdX+3KLaaoO/
rOroDCG7AUZB4GaodSZURqJm8RmnNtWNckK7GBwXbZ7qNZrkp
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
--
___
B
ioned 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
ation 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
tcoin/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
Bitc
ogic
- `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
[T
one 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](htt
--
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 div
o 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 me
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 s
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 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
wrote:
> Hello all,
>
> The release window for 0.11 is nearing, I&
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
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 po
e 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.
lization: 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
) 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.
tize 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 ever
e connections.
This could even work if the normal node functionality does not go
through Tor - although then one'd have to be even more careful about
any kind of residual fingerprinting or timing attacks.
Wladimir
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 t
Luke Dashjr
- Mark Friedenbach
- Mathy Vanvoorden
- Matt Corallo
- Matthew Bogosian
- Micha
- Michael Ford
- Mike Hearn
- mrbandrews
- mruddy
- ntrgn
- Otto Allmendinger
- paveljanik
- Pavel Vasin
- Peter Todd
- phantomcircuit
- Philip Kaufmann
- Pieter Wuille
- pryds
- randy-waterhouse
- R E Broadley
- Ro
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 i
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 Inte
On Thu, Feb 5, 2015 at 12:33 PM, Wladimir 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 an
reEncoding()
- 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 fina
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 Progr
andment 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
elease?
> 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 in
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 ReadCo
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
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&#x
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, Jan 12, 2015 at 3:28 PM, Wladimir wrote:
> On Mon, Jan 12, 2015 at 11:31 AM, Wladimir wrote:
>
> If you build from source, and have already built rc2, there is no
> reason to build rc3.
0.10.0rc3 executables have been uploa
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
O
On Sat, Jan 10, 2015 at 12:18 PM, Ivan Jelincic 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]
Wladi
itcoin/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 partnershi
:
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
> 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
at (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 Rep
7;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-
On Wed, Dec 10, 2014 at 6:47 AM, Wladimir 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
> Te
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 wrote:
> Also utACK ("untested ack") and "tested ack" when people are being explicit.
>
&g
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 Busi
-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
--
ncode 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
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
ion. 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
gt; # 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
s 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
--
_
On Sun, Oct 26, 2014 at 9:53 AM, Luke Dashjr 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: subm
ll/3959
- https://github.com/bitcoin/bitcoin/pull/4250
Wladimir
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 whatev
tive 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.
Monito
ms
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.
Ge
>
> 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
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
(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 se
, 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 alerte
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
ink 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 m
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
Achi
, 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
Achi
ase:
- 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
A
=` 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
ment 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 exciteme
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
(..)
https://github.com/bitcoin/bitcoin/pull/4805
Wladimir
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-d
rms
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
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.
V
tives.
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.
ht
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
dcast the transaction, wait
a bit, pick a new node, broadcast the transaction until it is comes
back through one of the other peers.
Separating the transaction broadcasting (of the wallet) from, for
example, the nodes used to request blocks from could make sense. Maybe
doubly so if bloom filt
t 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
---
e 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
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
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 s
completely crazy
as there are already plans to add zeromq as an optional dependency for
notifications [1].
[1] https://github.com/bitcoin/bitcoin/pull/4594
Wladimir
--
Want fast and easy access to all the code in your e
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote:
> On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn 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 i
ch?
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 l
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
Cod
> 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?
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 pos
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
unching 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 enter
riptSig is a source of
malleability, as there can be multiple sequences of opcodes that
evaluate to the same result.
Wladimir
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lin
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 enterp
ot 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
On Tue, Jul 15, 2014 at 10:23 AM, Jeff Garzik wrote:
> On Tue, Jul 15, 2014 at 4:19 AM, Wladimir 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
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 fre
> 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
art 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 E
On Wed, Jun 11, 2014 at 5:39 PM, Wladimir 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 redire
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
nod
. Anything from 'GUI
uses wallet as a library' (multibit, electrum, bitcoin core) to
elaborate client-server protocols (btcd, coinvault?) are acceptable
depending on the use case.
Wladimir
--
Open source busi
1 - 100 of 294 matches
Mail list logo
