This is very strange...when did you run this test and can anyone else
reproduce this?
Matt
On 05/15/14 11:50, Andreas Schildbach wrote:
> testnet-seed.bluematt.me OK (but only returns one node)
--
"Accelerat
Oops, missed the lost
On May 16, 2014 3:04:40 PM EDT, Matt Corallo wrote:
>Oh, I missed that this was the testnet seed. Yea, that one never got
>set
>up properly and was just pointing to a static seed node (that is now
>down...). The mainnet seed actually works.
>
>On 05/1
Absolutely not. Time and time again we've seen "anonymized" data sets
that dont work out so well. I'm sure its possible to do but there are
too many factors and we dont want to succumb to this.
Also, these generally look good (and essentially the same as what had
been a gentleman's agreement for t
a
relay node at http://bitcoin.ninja/RelayNodeClient.jar and the source
for the whole thing at https://github.com/TheBlueMatt/RelayNode.
Matt
On 11/06/13 05:50, Matt Corallo wrote:
> Recently, there has been a reasonable amount of discussion about the
> continued fragility of the public B
I'm sure many of you have already seen this, but Hal Finney passed away
on Tuesday. While his body is being cryogenically preserved, we should
all take a moment to thank Hal for everything he did for the cypherpunk
community, specifically helping hugely in the early days of Bitcoin as
well as PGP.
It already is https://bitcointalk.org/index.php?topic=766190.0;all.
Well, ok, a variation on the idea is.
Matt
On 10/02/14 04:39, Rebroad (sourceforge) wrote:
> https://bitcointalk.org/index.php?topic=145066.0
>
> The idea proposed in the above article seemed like an excellent idea.
> What is ho
See-also: this related bug on Curve25519 and some MS Research curves
that generated far more discussion.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
Matt
On 10/13/14 10:01, Melvin Carvalho wrote:
> FYI:
>
> This is an issue I filed related to adding secp256k1 into Web Crypto API
> whic
On 10/15/14 08:47, Wladimir wrote:
> 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)
ACK.
It is a very bad idea to delay relaying/accepting blocks based on
information which is only local to your node (ie would create the
ability for people to split the network by sending out lots of
double-spends to different parts of the network at the same time). Thus,
miners are incentivized to go c
Depends, without BIP62 a /lot/ of the even basic contracts that people
want to use today (or wanted to use 18 months ago) are unusable, in
fact, without BIP62, the atomic swaps suggested as important for
sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
its a very long-term th
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.
>
>
>
> -
There was recently some discussion around dnsseeds. Currently some
dnsseeds are getting blocked by ISPs because the hosts they pick up
(which run bitcoin core nodes) often run rather web servers alongside
which serve malware or whatever else and thus end up on IP-based malware
blacklists.
Of cours
perfectly good nodes will get caught in the crossfire. Hiding what
actual IPs we're returning in the results seems much cleaner, despite
being an ugly hack.
On 12/20/14 11:14, Jeremy Spilman wrote:
> On Sat, Dec 20, 2014 at 08:57:53AM +0000, Matt Corallo wrote:
>>> There was recentl
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the heigh
On 04/21/15 07:59, Peter Todd wrote:
> On Mon, Mar 16, 2015 at 10:22:13PM +0000, Matt Corallo wrote:
>> In building some CLTV-based contracts, it is often also useful to have a
>> method of requiring, instead of locktime-is-at-least-N,
>> locktime-is-at-least-N-plus-the-h
Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Block size is a question to which there is no a
Replies inline.
On 05/06/15 22:44, Tier Nolan wrote:
> On Wed, May 6, 2015 at 11:12 PM, Matt Corallo <mailto:bitcoin-l...@bluematt.me>> wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.
-snip-
> The q
For now, lets leave the discussion to JUST the block size increase. If
it helps - everyone should assume that their pet feature is included in
a hard fork or, if you prefer, that no other features are included in a
hard fork.
On 05/06/15 23:11, Matt Whitlock wrote:
> I'm not so much opposed to a b
On 05/06/15 23:33, Tier Nolan wrote:
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <mailto:bitcoin-l...@bluematt.me>> wrote:
>
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would a
On 05/07/15 14:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email me objections I might have missed. I
> would st
Replies inline.
On 05/07/15 17:43, Mike Hearn wrote:
> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks
> roughly every 10 minutes on average for the next eleven years, and
> it seems likely that a bl
On 05/07/15 11:29, Mike Hearn wrote:
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
>
>
> I was referring to winter next year. 0.12 isn't scheduled until the end
> of the year, according to Wladimir. I explained wh
On 05/07/15 19:34, Mike Hearn wrote:
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
>
>
> So your concern is just about the ordering and
making progress on building the software
needed in all of the above for a while now, but I think they're all
very, very immature today.
On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
Matt Corallo <mailto:bitcoin-l...@bluematt.me>> wrote:
-snip-
>> If, inst
On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
>
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <mailto:bitcoin-l...@bluematt.me>> wrote:
>
>
&
On 05/29/15 23:48, Gavin Andresen wrote:
> On Fri, May 29, 2015 at 7:25 PM, Matt Corallo <mailto:bitcoin-l...@bluematt.me>> wrote:
>
> Sadly, this is very far from the whole story. The issue of miners
> optimizing for returns has been discussed seve
>For example, I think some of the resistance for bigger blocks is coming
>from contributors who are worried they, personally, won't be able to
>keep
>up with a bigger blockchain. They might not be able to run full nodes
>from
>their home network connections (or might not be able to run a full node
In other words when we roll out the update, we have to make sure we have
>>50% not just 50%. Something like 60%-75% should do fine (IMHO). In
other words we just have to be very, very vocal about the change when it
happens and make sure miners are all on board.
Matt
On Wed, 2012-02-29 at 22:05
On Tue, 2012-03-13 at 14:45 -0400, Luke-Jr wrote:
> On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote:
> > https://github.com/bitcoin/bitcoin/pull/932 adds a "pong" message that
> > echoes back a 64 bit nonce contained in the ping, if the protocol
> > version is new enough.
> >
> > The goal o
I spent some time changing the internal bitcoin code to use callback
hooks, but its far from complete (or even really usable from anything
other than the code in the satoshi client itself, it doesnt even have
any deregister methods!). As it sits now, it is likely to get more
eyeballs and merged fo
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote:
> > filterinit(false positive rate, number of elements): initialize
> > filterload(data): input a serialized bloom filter table metadata and data.
>
> Why not combine these two?
I believe its because it allows the node which will have to use the
On Fri, 2012-06-15 at 13:29 +0200, Mike Hearn wrote:
> I had to hit the sack last night as it was 2am CET, but I'd like to
> sum up the discussion we had on IRC about scalability and SatoshiDice
> in particular.
>
> I think we all agreed on the following:
>
> - Having senders/buyers pay no fees i
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote:
> > > Why not combine these two?
> >
> > I believe its because it allows the node which will have to use the
> > bloom filter to scan transactions to chose how much effort it wants to
> > put into each transaction on behalf of the SPV client.
>
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
> > Yes, the format is something that must be hashed out (no pun
> > intended). Need input from potential users about what information
> > they might need.
>
> Matts point that a branch-per-transaction may duplicate data is well
> made, that sa
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
> > The idea can be more generalized in that there are many cases where the
> > generator of a transaction doesn't care about confirmation times, and
> > would really be willing to make their transaction lower priority than
> > other 0-fee transa
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote:
> As for full nodes... I like the organic growth and random nature of
> the mempools. On the fence, WRT full node mempool sync at startup.
>
I dont particularly care either way, but I have a feeling miners will
really want that so that they c
On Sat, 2012-06-16 at 10:27 +0200, Mike Hearn wrote:
> > I'd much rather have an overloaded node respond with 50% fp rate filters
> > as an option if there aren't many full nodes available than simply
> > disconnect SPV clients.
>
> I don't think the bloom filter settings have any impact on server
I mentioned this on IRC a week or so ago, noticing that though they are
not executed and required to be well-formed, we still count any sigops
that appear in them (which I guessed may be an interesting attack if you
could get a miner to put a byte in there that is the equivalent of
OP_CHECKSIG beca
On Mon, 2012-07-23 at 09:54 +0200, Andreas Petersson wrote:
> Some concerns regarding Bloom Filters. I talked with Stefan Thomas on
> the Hackathon Berlin about this.
> I tried to follow the discussion closely but i have not taken a look at
> the code yet (is there already an implementation?) so
On Sun, 2012-07-29 at 20:52 -0400, Gavin Andresen wrote:
> > Is there interest to port more tests (P2SH, checksig, checkmultisig,
> > block verification, maybe even DoS rules) into data-driven format? It
> > might be something that I'd like to help with if pull requests in that
> > direction are we
I spend some time implementing some of the changes discussed in the
previous thread "New P2P commands for diagnostics, SPV clients", and
wanted to field comments before I write up a BIP.
I have implemented a simple bloom filter that works on transactions as
well as a new block relay type which rel
If you are playing around with the current rawtx API, be careful using
SIGHASH_SINGLE:
When parsing a transaction input, which uses a SIGHASH_SINGLE signature,
and the given input's index is >= the total number of outputs in the
current transaction, bitcoind doesn't sign anything useful, it signs
I actually implemented parts of the header+ v stuff in a branch with
my bloom filter stuff, you can see it here:
https://github.com/TheBlueMatt/bitcoin/commits/bloom%2Brelayblock
Its pretty stupid and would be pretty easy to DoS/get it stuck/etc, but
in theory it works. I don't see much reason why
It seems to me the whole idea of segmenting blocks would add very little
(to nothing) with any sane block size. Sure, if a block were to be
10GB, it may make sense. However, even in that case, it would be easier
to relay a list of tx hashes (which may be a bit expensive) and txes
separately inste
Although Jenkins may not be the best system, we already have jenkins and
pull-tester (which is a dumb python script I wrote to test all incoming
pull requests from github).
They both run the same set of scripts, namely those at
https://github.com/TheBlueMatt/test-scripts (its pretty basic right
On Wed, 2012-09-26 at 13:28 +0100, steve wrote:
> Hi Matt,
>
> Glad to have another ninja onboard :)
>
> On 25/09/2012 21:41, Matt Corallo wrote:
> > Although Jenkins may not be the best system, we already have
> > jenkins and pull-tester (which is a dumb python scr
On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen wrote:
> RE: sharing parts of the merkle branches when returning a 'merkleblock' :
>
> I think I agree that complicating the BIP for what should be a very
> rare case (more than a handful of transactions in a block match the
> transactions in your
On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote:
> On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote:
> > I've written a draft BIP describing the bloom filtering protocol
> > extension developed by myself and Matt.
> >
> > https://en.bitcoin.it/wiki/BIP_0037
>
> Two comments I mad
On Thu, 2013-01-10 at 16:21 +0100, Mike Hearn wrote:
> Here's a quick update on where we're up to.
>
> Thanks to Matts excellent work, I was able to test his bitcoinj and
> bitcoin-qt work together today. There are a few minor tweaks needed,
> but I feel like we're maybe a week away from having al
Actually, there is one more minor algorithmic change I would like to
make to the way the hash function is computed really quick before it
gets merged, I'll have that finished up by the end of today.
Matt
On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
> Matts latest code has been tested by A
These tests are run on each pull requests and on each new commit to
master. They arent very complete, but they do test a lot of block
acceptance rules.
https://github.com/TheBlueMatt/test-scripts
Matt
On Fri, 2013-04-05 at 12:24 -0500, Adam Ritter wrote:
> Hey guys,
>
> I just bought some BitC
I hacked together a new min fee/prio calculator and memory-limited
mempool a while back and figured Id post the code here to get some
comments. Its more of a discussion-starter than a strict proposal and
has a few obvious holes (hence posting here instead of pull-requesting).
It works as such (no
I really beg to differ on this one. If you're an Ubuntu user who is
behind only one distro (quantal) you're stuck on version 0.6.2 with no
updates since 2012 (yes, that means on May 15th you'll be lost).
For those still on Debian Squeeze (ie barely out of date), you get
0.3.24! Yes, 0.3.24 incl
ACK, I see no reason to leave broken things in that a) arent necessary
and b) no one has the developer resources to fix.
Matt
On Mon, 2013-08-19 at 12:27 -0400, Jeff Garzik wrote:
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https:/
(Finally) got around to this, sorry for the delay. 0.8.5 has the new
category and pull request is at
https://github.com/bitcoin/bitcoin/pull/2999
Matt
On Fri, 2013-08-02 at 12:08 -0700, Kip Warner wrote:
> Hey list,
>
> Currently the bitcoin-qt application's XDG desktop integration on some
> des
Recently, there has been a reasonable amount of discussion about the
continued fragility of the public Bitcoin network on IRC and elsewhere
(1). To this extent, I'm organizing a system of peering between nodes in
the network by creating a system of high-speed relay nodes for miners
and merchants/ex
miner a full block's worth of profits, which they are
fairly unlikely to do. In any case, if it every becomes a problem, its
not hard to adapt addnode to allow higher DoS scores for individual nodes.
Matt
On 11/06/13 07:25, Tier Nolan wrote:
>
>
>
> On Wed, Nov 6, 2013 at 5:50
On 11/08/13 06:46, Mike Hearn wrote:
> I took a brief look at the code - it's looking very reasonable. You can
> replace any construct like
>
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
>
> which is quite verbose, just with
> Unint
In the short-term, maybe. Keep in mind that the code for tx relay is
fairly different and the bandwidth for transaction relay on these
nodes is already lower than it is for blocks (by design). That said,
I'd like to look into doing tx-less block relays for transactions that
peers already have to li
No, mine identifies as BitcoinJ, RelayNode, version string
On 11/21/2013 10:27 AM, Jeff Garzik wrote:
> Is that Matt's relay, which has reduced validity checking?
>
>
> On Thu, Nov 21, 2013 at 8:48 AM, Mike Hearn wrote:
>> I added some additional logging to my node and ran it for a few days.
>>
An attacker with some small hashpower isolates you (as an individual)
from the network by MITMing your network. You just switch the the
attackers chain as if nothing happened because of the network rule
that defines it as OK. Today, you will see that you're behind and warn
the user.
Was it really
I'm not sure where you got the idea that Bitcoin-development was ideal for
hiring scamcoin developers, but it's not. Most of the people on this list are
smart enough to realize posts like this are dumb ideas backed by greedy
"entrepreneurs" who don't understand the system they're trying to impro
We already have a wonderful system for secure updating - gitian-downloader. We
just neither use it not bother making actual gitian releases so anyone can use
it to verify signatures of downloads.
Jeremy Spilman wrote:
>I didn't know about the dedicated server meltdown, it wasn't any of my
>
>i
I disagree with this proposal both in spirit and in practice.
We all know satoshi was the best programmer like no one ever was. Clearly he
intended this monetary supply from the beginning, who are we but mere mortals
to go against satoshi's will?
Also, should we really do this with a soft fork
I move to reclaim bip 42 as reserved for a bip containing either a reference to
musical dolphins or towels in the name.
Matt
On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell wrote:
>On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille
>wrote:
>> In case there are no further objections (excluding from
Hmm? It's up to date... 0.9.1 doesn't change anything for
dynamically-linked-to-openssl builds.
Matt
On April 12, 2014 10:26:07 AM EDT, Oliver Egginger wrote:
>Hello,
>
>so far, nothing yet?
>
>See: https://launchpad.net/~bitcoin/
>
>I'm developing currently a LiveCD for hot/cold wallet managem
On Mon, 2011-08-29 at 16:10 -0400, Gavin Andresen wrote:
> Quick brain dump on a bunch of stuff:
>
> I'd like to get a 0.4 release out, but am still working on a fix for
> the deadlock bugs that the new wallet encryption and/or the CWallet
> refactoring caused. My short-term plan is to reduce the
On Wed, 2011-08-31 at 14:20 +, John Smith wrote:
> Hi,
>
> Bitcoin-qt is now feature complete (including wallet encryption), and
> has been tested for a while by various people without any major
> problems.
>
> It is now in status of feature freeze.
>
> The project builds on Windows, MacOSX
On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote:
> Quick status update on 0.4; I probably won't have time to tackle these
> properly before Tuesday:
>
> + sipa found what looks like a deadlock between the addr-handling and
> IRC-join-handling code.
> + UukGoblin reports a deadlock problem
On Tue, 2011-09-06 at 20:32 -0400, Alex Waters wrote:
> I am working on the following to create a stable build environment for
> testers:
>
>
> - Build bitcoin 4.0 source in Windows 7
When did it switch from 0.4 to 4.0?
I feel like the user-facing quality of the software should not be
over-emphas
On Thu, 2011-09-08 at 07:42 -0700, David Perry wrote:
> There has been some discussion on the new Bitcoin StackExchange site
> lately about the alert protocol. A few have suggested that it might
> carry the potential for abuse (spam/DoS) and others have argued that
> it's merely deprecated. In any
On Thu, 2011-09-08 at 09:09 -0700, David Perry wrote:
> @Steve re "Who knows, it might be the only way we'll ever hear from
> Satoshi again."
>
>
> That brings up a good point... Does anyone aside from Satoshi actually
> have the ability to send such an alert?
Gavin does
> Should we at the very l
On Fri, 2011-09-09 at 10:02 -0400, Gavin Andresen wrote:
> I just tagged the git tree: v0.4.00rc2
>
> Fixes from release candidate 1:
>
> + Optimize database writes for transactions with lots of inputs
> + Fix a deadlock that could occur when adding addresses from 'addr'
> messages and irc
> + F
Gavin tagged 0.4 release today, so here are my gitian builds.
These zips are in gitian-download format which means they can be
automatically downloaded and pgp-verified using the gitian-updater
script (see
https://github.com/devrandom/gitian-builder/blob/master/share/gitian-updater).
Currently the
On Tue, 2011-09-27 at 20:28 +0200, da...@bitcoin.se wrote:
> Hi all,
>
> I posted this question on the forums but got no answers.
Most developers treat the forums as write-only or just ignore them all
together, they are way too full of junk to bother reading.
>
> I'd like to make some improvement
On Tue, 2011-10-04 at 16:40 -0700, Brian McQueen wrote:
> I installed boost via the mac ports. Its got lobboost_thread-mt, but
> it doesn't have libboost_thread.a. Should I modify the makefile or get
> a different version of boost?
>
(from
http://stackoverflow.com/questions/2293962/boost-librari
On Tue, 2011-12-13 at 00:37 +0100, Jorge Timón wrote:
> I don't think Amir wants to put it into the protocol, but I still
> don't like much the proposal if it has to rely on servers.
> As an aside, even if firstbits it's not useful enough for the human
> memory, it is still useful for QR-codes like
On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete u...@server.com handling:
I'm not against this, but I think its way ov
On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
> Don't know much about QR codes, but I thought they have a length limitation.
> Why jav wants to use not just addresses but firstbits then?
Under no circumstances should the use of firstbits ever be supported.
It doesn't scale, not even close,
On Fri, 2011-12-30 at 00:57 -0800, Amir Taaki wrote:
> hey,
>
> so sipa/gmaxwell proposed on irc that maybe upnp is not working anymore but
> there isnt any way to test.
>
> well i made an alternate chain, and ran the daemon on my vps.
>
> sometimes it accepts connections, sometimes not. It's a
Because many made the mistake and it isnt specified in this email, this
meeting is tomorrow (not 30 minutes ago).
On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote:
> This meeting is to discuss the new OP_EVAL changes coming to bitcoin.
>
> A good summary of the past discussion so far by justmo
I have to say, I agree with Luke here, this was Finalized a long time
ago. The version that was agreed on can be seen at
https://en.bitcoin.it/wiki/BIP_0021
Also see https://bitcointalk.org/index.php?topic=6205.0 and Luke's three
biased polls at
https://bitcointalk.org/index.php?topic=6206.0
htt
On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote:
> BIP 20 really has no support among implementations such as Bitcoin-Qt,
> Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing
> GUI projects (all with some form of URI Scheme), their opinion carries the
> most weight.
h a broken implementation).
Matt
On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote:
> On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote:
> > BIP 20 really has no support among implementations such as Bitcoin-Qt,
> > Electrum, MultiBit or Bitcoin-JS. As the most active and vis
avoid any localization concerns).
Matt
On Tue, 2012-01-31 at 20:02 +0100, Wladimir wrote:
>
> On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo
> wrote:
>
> All that said, I dont think its an ideal solution, depending
> on the
> names of
, from the RFC these are
>
>
> * Option A: req_something (underscore)
> * Option B: req-something (hyphen)
> * Option C: req~something (tilde)
> * Option D: req.something (period)
>
>
> Personally, my eye likes Option B, the hyphen.
>
> On 31 January 2012 22:14, Andreas Sc
Not yet, its up to genjix (Amir) to do that. See
https://github.com/genjix/bips/pull/2
Matt
On Thu, 2012-02-02 at 17:07 +, Gary Rowe wrote:
> BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated?
> I'm looking there now and it seems to be still at "req:"
> --
I changed the description of the message parameter to be a bit more
descriptive, however, I dont want to change the name of the parameter
because some clients have already implemented that and I really prefer
to make as minor of changes as possible to this BIP even if it is
officially only a Draft.
88 matches
Mail list logo
