osing replacing checkpoints with nothing.
--
Gavin Andresen
> On May 13, 2015, at 8:26 AM, Alex Mizrahi wrote:
>
> Let's consider a concrete example:
>
> 1. User wants to accept Bitcoin payments, as his customers want this.
> 2. He downloads a recent version of Bitcoin Core, c
Completely off-topic for this mailing list, which is about coding/technology
not people.
Stop or I will excercise my moderator superpowers and remove you from this list.
--
Gavin Andresen
> On Jun 4, 2015, at 5:52 PM, Sven Berg wrote:
>
> 1) Hours/
I have no objections to a rc1 happening before I'm back.
--
Gavin Andresen
On Aug 2, 2012, at 10:45 AM, Jeff Garzik wrote:
> On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik wrote:
>> There seems to be consensus that we should go ahead and do a release,
>> before leve
patibility or security merchants
might want to include both a x509chain AND
--
Gavin Andresen
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers,
Busy with pre-conference stuff, not following details of this conversation...
... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking about
a year or so ago.
--
AlienVault Unified Security Management (US
On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman
wrote:
>
> Would it make sense to use either fixed length strings or maybe even enums?
No. Enums or fixed length strings just make it harder to extend, for no benefit
(bandwidth of 'reject' messages doesn't matter, they will be rare and are n
Message encoding and length (or terminator or checksum or error correction
or...) should be part of the transport protocol, in my humble opinion.
--
Gavin Andresen
> On Jan 26, 2014, at 6:01 PM, Mike Hearn wrote:
>
> To be more accurate, the embedded messages already have length
Consensus is the spec should be clarified to match current behavior, so it
won't change.
--
Gavin Andresen
> On Apr 29, 2014, at 9:44 AM, Jouke Hofman wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> We have BIP70 already in use (over a hundred paid re
We've got no power, so it might be a day or two before I can help verify gitian
builds or pull patches.
Sent from my iPhone
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry Ap
On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier wrote:
>
> You and Gavin could do a lot better by working on a Bitcoin social
> contract - a promise of what features will *never* be added (or taken
> away) from Bitcoin, because despite what you say it's not acceptable
> to pro
it. I have much higher tasks on my TODO list.
--
--
Gavin Andresen
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get un
ized wallets or specialized
applications.
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What
quest.
I'm going to take the lack of immediate "That's a Terrible Idea!" as rough
consensus...
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
HPCC Sy
.
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC
are hundreds of
field numbers available.
It would be silly to add a "generic stuff" field inside a container format
that ALREADY has all the mechanisms necessary for forwards and backwards
extensibility.
--
--
Gavin Andresen
-
. I develop with:
./configure --disable-hardening --disable-silent-rules CXXFLAGS='-g3 -O0
-DDEBUG_LOCKORDER'
--
--
Gavin Andresen
--
Open source business process management suite built on Java and Eclipse
Turn
y
fast propagation of most newly solved blocks.
--
--
Gavin Andresen
--
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 Sig
f fee-paying transactions,
sorted by fee") might make it possible to save even more bandwidth by
letting your peers create a very good approximation of your block with just
that information
--
--
Gavin Andresen
--
ument about whether it should
roll out as a soft fork, wait for a hard fork, be combined with some other
things that it would be nice to add or change, etc.
--
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements
action until they can also take the "burn to fee".
>
If the first transaction is P2SH, then the miner won't know there is an
advantage to holding it until it is too late (the scriptPubKey is an opaque
hash until the second transaction is final and relayed/broad
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner wrote:
> On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> > If the first transaction is P2SH, then the miner won't know there is
> > an advantage to holding it until it is too late (the scriptPubKey is
> > an opaque hash until
27;t have any opinion on the hard- versus soft- fork debate. I think
either can work.
--
--
Gavin Andresen
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of
7;t a clearly better solution I think "we" should create a strictly
moderated bitcoin-bips@lists.sourceforge list.
--
--
Gavin Andresen
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Mo
We had a halving, and it was a non-event.
Is there some reason to believe next time will be different?
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin
ow long would it
take to be able to get enough data for a reasonable estimate of "what is
the least I can pay and still be 90% sure I get confirmed in 20 blocks" ?
Hours? Days? Weeks?
--
--
Gavin Andresen
-
eshold=0.5 (or
-estimatefeethreshold=0.95 if as-fast-as-possible confirmations are
needed). Setting both the number of confirmations and the estimation
threshold on a transaction-by-transaction
s only apply to transaction with strict nVersion==3, and not to
> higher ones.
>
I agree; soft-forking is a useful way of rolling out upgrades, we shouldn't
prohibit
ymentRequests
whenever they need to make a payment" or maybe "Give them an array of
PaymentRequests for the next X days/months/years of payments."
--
--
Gavin Andresen
--
Download BIRT iHub F-Type - The
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn wrote:
> OK, I guess we can boil this down more simply. BIP 70 uses protocol
>> buffers because I designed it and implemented the original prototype (with
>> lots of input from Gavin and an earlier proposal by sipa). I used protocol
>
nd very few
transactions..."
"reducing this avenue for malleability is useful on itself as well" :
awkward English. How about just "This proposal has the added benefit of
reducing transaction malleability (see BIP62)."
--
--
Gavin Andresen
-
but now I'd like to receive
>> feedback from community.
>>
>
> IMO it's better to pair a protocol spec with an implementation.
>
--
--
Gavin Andresen
--
Dive into the World of Parallel P
t
> need a cycle of making this non-standard, and then in a further
> release doing a second softfork to enforce it.
>
> It's a 2-line change; see #5743.
>
> --
> Pieter
>
>
--
--
Gavin Andresen
---
miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.
Because ultimately consensus comes down to what software people choose to
run.
--
--
Gavin Andresen
--
One dashboar
a/the-myth-of-not-full-blocks
We don’t need 100% full one megabyte blocks to start to learn about what is
likely to happen as transaction volume rises and/or the one megabyte block
size limit is raised.
--
--
Gavin And
much change sooner or later.
There is not yet consensus on exactly how or when. I will be pushing to
change it this year."
This is what "I will be pushing to change it this year" looks like.
--
--
Gavin Andresen
Can anyone opposed to this proposal articulate in plain english the worst
case scenario(s) if it goes ahead?
Some people in the conversation appear to be uncomfortable, perturbed,
defensive etc about the proposal . But I am not seeing specifics on why it
is not a feasible plan.
From: Mike Hearn
k it has potential for both scaling as well as keeping up a constant
> fee pressure. If tuned properly, it should both stop spamming and increase
> block size maximum when there are a lot of real transactions waiting f
lower dynamic limit algorithm: I REALLY like that idea.
--
--
Gavin Andresen
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performa
quot;don't grow too quickly, give
some reasonable-percentage-minority of miners the ability to block further
increases."
Also relevant here:
"The curious task of economics is to demonstrate to men how little they
really know about what they imagine they can design." - Fri
hink that is the best you
can (honestly) do.
--
--
Gavin Andresen
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metric
at 10:39 AM, Thomas Voegtlin
wrote:
> Le 12/05/2015 15:44, Gavin Andresen a écrit :
> > Ok, here's my scenario:
> >
> > https://blog.bitcoinfoundation.org/a-scalability-roadmap/
> >
> > It might be wrong. I welcome other people to present their road maps.
>
; 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
On Tue, May 12, 2015 at 7:48 PM, Adam Back wrote:
> I think its fair to say no one knows how to make a consensus that
> works in a decentralised fashion that doesnt weaken the bitcoin
> security model without proof-of-work for now.
>
Yes.
> I am presuming Gavin is just saying
le of
histograms of block sizes to infer what policy miners are ACTUALLY
following today with respect to block size:
Last 1,000 blocks:
http://bitcoincore.org/~gavin/sizes_last1000.html
Notice a big spike at 750K -- the default size for Bitcoin Core.
This graph might be misleading, because tran
don't think us
developers should be deciding things like whether or not fees are too high,
too low, .
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitco
a/time-to-roll-out-bigger-blocks )
There is the "a sudden jump to a 20MB max might have unforseen
consequences" risk that I don't address, but a dynamic increas
t;
>
> I am very skeptical about this idea.
>
By the time a hard fork can happen, I expect average block size will be
above 500K.
Would you support a rule that was "larger of 1MB or 2x average size" ? That
is strictly better than the sit
Can we hold off on bike-shedding the particular choice of parameters until
people have a chance to weigh in on whether or not there is SOME set of
dynamic parameters they would support right now?
--
--
Gavin Andresen
re, the ultimate authority for
determining consensus is what code the majority of merchants and exchanges
and miners are running.
--
--
Gavin Andresen
--
___
Bitcoin-development
nodes on the network.
(e.g. see the count at https://getaddr.bitnodes.io/nodes/ )
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.
Are you arguing that work won't happen if the max block size increases?
* I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
Again, see http://gavinandr
ks,
yes? If not, why not?)
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?
--
--
Gavin Andresen
--
___
Bitcoin-development ma
locks fit in a single packet to cross the gfw,
> but that is probably overkill and not well-researched.
>
Last night's transaction volume test shows that most miners do just go
along with defaults:
http://bitcoincore.org/~gavin/sizes_358594.html
> I'm not suggesting that we increase the
you can afford that.
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
On Sun, May 31, 2015 at 3:05 AM, Peter Todd wrote:
> Yeah, I'm pretty surprised myself that Gavin never accepted the
> compromises offered by others in this space for a slow growth solution
>
What compromise? I haven't seen a specific proposal that could be turned
a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
"what
would it actually cost."
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/l
dresen.ninja/when-the-block-reward-goes-away
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.n
nsive cooling, ability to use waste heat...
That's good. An equation with lots of variables has lots of different
maximum solutions, and that means better decentralization -- ther
he middle of the Sahara" then we're going to have to agree to disagree.
So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
co
overhead of 'inv'
messages, and if we ever get really serious about scaling up we'll need to
fix the protocol to reduce that overhead, but that won't be a problem for
years).
--
--
Gavin Andresen
https://github.com/bitcoin/bitcoin/pull/5835 or
https://github.com/bitcoin/bitcoin/pull/6077 ).
If Chun had six seconds of latency, and he can't pay for a lower-latency
connection (or it is insanely expensive), then there's nothing he can do,
he'l
eliable and expensive, driving more and more people
away from Bitcoin towards... I don't know what. Some less expensive, more
reliable, probably more-centralized solution.
The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short
On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240...@gmail.com> wrote:
> I cannot believe why Gavin (who seems to have difficulty to spell my
> name correctly.) insists on his 20MB proposal regardless the
> community. BIP66 has been introduced for a long time and no one knows
>
>> Raystonn
>>
>>
>>
>> --
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
70% of
hashpower follows) of setting aside some space for high-priority
transactions regardless of fee might also be enough to cause this attack to
fail in practice.
--
ation)
make both of our simulations irrelevant in the long-run?
Or, even simpler, why couldn't the little miners just run their
block-assembling-and-announcing code on the other high-bandwidth-side of
the band
individual user as to what code they run and what rules
> they enforce. So then why is everyone so up in arms about what Mike and
> Gavin are proposing if everyone is free to decide for themselves? I
> believe that each individual user should adhere to the principle that there
> sh
good for the whole system: users, merchants,
exchanges and miners.
As always, if you have questions or concerns feel free to email me.
--
--
Gavin Andresen
--
___
Bitcoin
th the argument:
-paytoscripthashtime=1333238400
... to delay switchover until April 1.
Hopefully this will be the last delay; Tycho has told me that deepbit will
support BIP16 as soon as he's able to merge and test the changes, which
will put support at well over 55%.
-
n. So, who
> is in favor?
Pieter
>
Most of you might already know this, but I'm strongly in favor of doing
this as soon as possible.
--
--
Gavin Andresen
--
Keep Your Developer Skills Current with LearnDevN
attract a great Windows developer? (we've
got issues piling up...)
+ Multisignature next-steps: who is working on what?
Am I forgetting anything?
--
--
Gavin Andresen
--
Keep Your Developer Skills Current with LearnD
es, which takes 100 blocks.
And it won't mature because a majority of hashing power is rejecting
it, right?
--
--
Gavin Andresen
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use o
ew
opcode to enable strong anonymity (at the very least, I assume we'll
need one or more new 'standard' transaction types that clients
understand).
--
--
Gavin Andresen
--
Virtualization & Cloud Ma
being stuck on the wrong block-chain fork
--
--
Gavin Andresen
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio
a reasonable draft I'll start a discussion
about it here.
--
--
Gavin Andresen
PS: If you're curious, here is what support over the last 30 days
looks like, beginning with the last 24 hours (144 blocks) and going
backwards for each 24 hour period:
Found 103 matches in 144 blocks (71.5
> Pretty graph of support over the last 100 blocks here:
> github.com/bitcoin/bitcoin/
D'oh! correct url for the pretty graph:
http://blockchain.info/P2SH
--
--
Gavin Andresen
--
This SF email is sponsos
free to drop by the #bitcoin-dev channel
on FreeNode IRC.
- --
Gavin Andresen
Gregory Maxwell
Matt Corallo
Nils Schneider
Wladimir J. van der Laan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
;t mean we give up and go back to paying each other with
cowrie shells; it means we assume that devices get compromised and
design around that assumption. I think that is a lesson that the
entire software industry needs to learn better.
--
--
Gavin Andresen
--
Messages over 40Kbytes big require moderator approval on this list; if
you want your messages to appear promptly, please trim excessive
quoting before hitting send.
Thanks!
--
--
Gavin Andresen
--
This SF email is
blockchain reorganizations
+ New code for managing the addr.dat file that prevents an attacker
from filling it with bogus entries.
- --
- --
Gavin Andresen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
f you want your favorite feature
to get into bitcoin core faster please spend some time helping test
other people's favorite features.
--
--
Gavin Andresen
--
This SF email is sponsosred by:
Try Windows Azure free fo
uld/should use?
You're glossing over little details like what character encoding is
used for the message, but I'd rather leverage all the work already
done by the IETF to nail down all those little details rather then
re-discover them and come up with our own solutions.
-
seems like a perfectly reasonable protocol improvement to me.
Anybody else have an opinion?
--
--
Gavin Andresen
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Appl
, etc (thanks to gmaxwell)
If you're re-implementing Bitcoin then accepting the Mark III testnet
blockchain is a good first test for compatibility. You'll still need to do
a lot of work to make sure you reject the same set of invalid transactions
or blocks as
mpler. I'd
especially like to hear what people think will be the "will be used by
lots of pool customers" features and what are the "will be used by
less than 5% of pool customers" features.
--
--
Gavin Andresen
-
ete" : false
}
sendrawtx
Submits raw transaction (serialized, hex-encoded) to local node and network.
E.g.: sendrawtx
010001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc9100473044022007f3ba1b8bdc156f2340ef1222eb287c3f5481a8078a8dad43aa09fd289ba19002201cc72e97406d546dc918159978dc78aee8215a6418375956665ee44e6eacc1150147522102894ca6e7a6483d0f8fa6110c77c431035
wallet entirely).
+ Private keys would stay in bitcoind memory only for the duration of
the RPC call.
--
--
Gavin Andresen
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security a
rules (HTTP fetch info from a
web page that is updated as often or infrequently as is convenient,
maybe). I think I like this solution the best, it should let clients
compete to have the smartest/bestest algorithms for saving their
user's money on transaction fees.
--
--
Gavin Andresen
---
ard' -- don't
relay/mine them by default, but accept blocks that happen to contain
them.
I agree that a rule change isn't worth it right now, but making them
non-standard now is easy and should make a rule change
> OK, to make progress on this work I need a few decisions (Gavin?)
>
> 1) Shall we do it?
What problem does it solve?
If the problem it will solve is "it will only take 4 hours to download
the entire blockchain next year instead of taking 16 hours" then no, I
don't think
e part of the main chain.
--
--
Gavin Andresen
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discu
. This means that if we go
> forward with the version==2 marker, we will forever need to make an exception
> for that block.
No, the rules are "enforce the rules when the chain has a
super-majority." Since block 190192 is in a part of the chain
, starting from a common chain (maybe the testnet3
tesnet-in-a-box chain) would be very useful for regression testing.
--
--
Gavin Andresen
--
Live Security Virtual Conference
Exclusive live event will cover all the ways tod
upon SIGHUP
* Bash programmable completion for bitcoind(1)
* On supported OS's, each thread is given a useful name
Thanks to everybody who contributed to this release:
===
Chris Moore
Christian von Roques
David Joel Schwartz
Douglas Huff
Fordy
Gavin Andresen
Gi
overview page
* (Windows only): enable ASLR and DEP for bitcoin-qt.exe
* (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)
Internal codebase
-
* Additional unit tests
* Compile warning fixes
Miscellaneous
-
* Reopen debug.log upon SIGHUP
* Bash programmable completion for b
s
where I think a QA team can add a lot of value.
Steve: I'm worried you're over-designing The Process. A release acceptance
test plan could be nothing more than a step-by-step checklist on a wiki
page, Google Doc, or Drobox shar
ut I think v1 should have it anyway:
+ Where-to-send-refund information included with payments, so
overpayments/refunds can be handled efficiently and displayed intelligently
in the customer's wallet.
Everything else I think can wai
ot;
PS: Thanks to Peter for responding to the "what's the relationship
between the Foundation and the Testing Project" (executive summary: no
relationship right now).
--
--
Gavin Andresen
--
Don't let
1 - 100 of 302 matches
Mail list logo
