On 05/29/15 23:48, Gavin Andresen wrote:
On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me
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 several times during
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 bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
* Though
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 where
.
On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM,
Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
-snip-
If, instead, there had been an intro on the list as I think we should
do the blocksize increase soon, what do people think?, the response
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
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 still
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
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
Replies inline.
On 05/06/15 22:44, Tier Nolan wrote:
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me
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 question
On 04/21/15 07:59, Peter Todd wrote:
On Mon, Mar 16, 2015 at 10:22:13PM +, 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-height-of-my-input. ie you could
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
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
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 +, Matt Corallo wrote:
There was recently some discussion around
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.
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
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.
-
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
which
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
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.
and 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 Bitcoin
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
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)
--
Accelerate
Oops, missed the lost
On May 16, 2014 3:04:40 PM EDT, Matt Corallo bitcoin-l...@bluematt.me 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/16/14
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 bitc...@olivere.de wrote:
Hello,
so far, nothing yet?
See: https://launchpad.net/~bitcoin/
I'm developing currently a LiveCD for hot/cold
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 gmaxw...@gmail.com wrote:
On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
In case there are
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 jer...@taplink.co wrote:
I didn't know about the dedicated server meltdown, it
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
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
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 m...@plan99.net wrote:
I added some additional logging to my node and ran it for a
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
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
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
(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
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
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
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
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
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 all
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 made on the
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
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
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
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
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 welcome.
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
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 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 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.
If that's
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 said, I
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 transactions.
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 can
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
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 of this is to
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
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. To
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 visible user
facing GUI projects (all
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 justmoon
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 all very
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
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 a
61 matches
Mail list logo
