-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15 September 2014 17:10:14 BST, Gregory Maxwell gmaxw...@gmail.com wrote:
If the server could replace the public key, it could replace the
signature in all the same places.
Please, can this stuff move to another list? It's offtopic.
+1
My
On Sat, Sep 20, 2014 at 08:38:15AM -0700, Peter Grigor wrote:
From block 0 to block 72499 the Merkle root is the same as the
coinbase transaction id. Why is that?
It's because of how the merkle tree algorithm works:
uint256 CBlock::BuildMerkleTree() const
{
vMerkleTree.clear();
On Sat, Sep 27, 2014 at 07:55:44PM -0700, Tom Harding wrote:
On 9/25/2014 7:37 PM, Aaron Voisine wrote:
Of course you wouldn't want nodes to propagate alerts without
independently verifying them
How would a node independently verify a double-spend alert, other than
by having access to an
On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote:
RE: soft-forks bumping version numbers:
Yes, we have consensus that is the way we will do it. I should probably
turn https://gist.github.com/gavinandresen/2355445 into an informational
BIP.
That gist is mistaken. To see the
On Mon, Sep 29, 2014 at 12:30:11AM -0400, Alan Reiner wrote:
On 09/28/2014 10:35 PM, Peter Todd wrote:
This can be solved by upgrading the address format at
the same time to let senders know they must send the funds in a
transaction with an increased version number, but obviously needing
of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify
pre
BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd p...@petertodd.org
Status: Draft
Type: Standards Track
Created: 2014-10-01
/pre
==Abstract==
This BIP describes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yeah, there are lots of upper-level details to consider; I'm not going to
pretend that BIP is complete yet. My thinking is that the first release should
include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that
blacklist for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote:
Thoughts on some way to have the stack item be incremented by the
height at
which the scriptPubKey was in a block?
Better to create a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com
wrote:
No, the burner would supply the funding transaction plus the redeeming
script as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
Very nice, semantics are clear and use cases are compelling.
Thanks!
Can we defer discussion of how to roll this out for a little bit, and
see
if there is
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote:
RE It's not like other software where people can choose to skip an
upgrade and things still work just like before.
If you're a minority, sure you can. Still a few nutters out there on
a 0.3.x codebase, including one or two
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote:
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org wrote:
I think you can do everything with the existing script level nlocktime
in some kind of turing completeness sense (maybe); but there is a
complexity cost
On Mon, Oct 13, 2014 at 07:34:16PM -0700, Pieter Wuille wrote:
Hi all,
while working on a BIP62 implementation I discovered yet another type
of malleability: the interpretation of booleans.
Any byte array with non-zero bytes in it (ignoring the highest bit of
the last byte, which is the
On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote:
please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.
Adam
* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe
On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is associated with a
gmail account. Quite
On Mon, Oct 27, 2014 at 03:33:45PM -0400, Alex Morcos wrote:
I've been playing around with the code for estimating fees and found a few
issues with the existing code. I think this will address several
observations that the estimates returned by the existing code appear to be
too high. For
On Tue, Nov 04, 2014 at 05:29:46AM -0800, Pieter Wuille wrote:
one of the rules in BIP62 is the clean stack requirement, which
makes passing more inputs to a script than necessary illegal.
Unfortunately, this rule needs an exception for P2SH scripts: the test
can only be done after (and not
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote:
So right now git head will accept the following invalid transaction into
the mempool
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org wrote:
However the implementation of the STRICTENC flag simply makes pubkey
formats it doesn't recognize act as through the signature was invalid,
rather than failing
Recently wrote the following for a friend and thought others might learn
from it.
Nope, never heard that term. By bug-for-bug compatibility, do you mean
that, for each version which has a bug, each bug must behave in the *same*
buggy way?
Exactly. tl;dr: if you accept a block as valid due
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo wrote:
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.
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote:
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.
RE soft fork vs. hard fork: It's about this time at Mike Hearn will
chime in, on the side of hard forks. Hard forks are in a sense much
cleaner, and permit solving
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote:
Why not schedule protocol upgrades every two years for the foreseeable
future?
For the same reason we don't do hard-forking upgrades of basically every
protocol on the planet on a regular basis, even when we don't have
consensus
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote:
This explanation is completely incoherent.
Because Bitcoin has a extra consensus requirements, requirements which
are really rare in engineering, the necessity of fixing bugs is even
greater.
There are two general ways to fix
On Fri, Nov 07, 2014 at 09:07:47AM +0100, Tamas Blummer wrote:
Peter,
forking would work best with a freeze of the consensus code. Do you see any
chance for that?
To a first approximation the consensus code *is* frozen; if we introduce
any consensus changes into it at this point it's due to
On Fri, Nov 07, 2014 at 11:30:22AM +, Clément Elbaz 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 ?
That's a pretty old idea, and we're working on it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com
wrote:
snip 100% accurate commentary from gmaxwell
The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 December 2014 20:02:17 GMT+00:00, Jeffrey Paul j...@eeqj.com wrote:
On 20141204, at 07:42, Luke Dashjr l...@dashjr.org wrote:
Is anyone working on a serialisation format to convey P2SH HD chains?
For
example, to give someone who wants to
From the So-Obvious-No-one-Has-Bothered-to-Write-It-Down-Department:
tl;dr: Micropayment channels can be extended to arbitrary numbers of
parties using a nearly completley untrusted hub, greatly decreasing
transaction fees and greatly increasing the maximum number of financial
transactions per
On Fri, Dec 12, 2014 at 07:50:48PM +0200, Alex Mizrahi wrote:
I think what Gareth was getting at was that with client-side validation
there can be no concept of a soft-fork. And how certain are you that the
consensus rules will never change?
Yes, it is true that you can't do a
. Which some people now appear to be in a hurry to
discard :)
FWIW usually Satoshi's solution is described as a hack, sometimes as an
elegant hack.
Peter Todd might disagree with the wisdom of that :) He wrote an
excellent email to this list not long ago warning of the dangers of
centralisation
On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote:
Peter... It kind of sounds to me that (as fine of a position paper as
this is) on _certain_ points, you're falling prey to the but it's
inefficient, but it's a scamcoin, but luke-jr told me so argument...
I prefer to make robust arguments;
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
Burn mining side chains might be one of the foundation ideas for that
ecosystem, enabling permission-less merge mining for
anyone with interest in a side chain.
I am puzzled by the lack of feedback on the idea.
It's not a new
BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
days ago and found a fairly large design change that makes merging it currently
impossible. Pull-req #4890², specifically commit c7829ea7, changed the
EvalScript() function to take an abstract SignatureChecker object,
On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote:
Usually at this point people say we assume that miners aren't going to
collude, otherwise even Bitcoin is not secure.
Well, this is BS. The fact that a pool can acquire more than 50% of total
hashpower was successfully demonstrated
.msg2961736
2) Setting the record straight on Proof-of-Publication,
Peter Todd, Dec 12th 2014,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html
3) Decentralized digital asset exchange with honest pricing and market depth,
Peter Todd, Feb 9th 2014,
http
On Wed, Dec 17, 2014 at 10:55:28PM +1100, Gareth Williams wrote:
I covered this in my original post: 1-way-pegs allow the creation of new
valuable tokens without those tokens being useful for speculation.
I stand corrected. A permanent 1-way-peg is sufficient to preserve
scarcity; nothing
for.
1) Decentralized digital asset exchange with honest pricing and market depth,
Peter Todd, Feb 9th 2014,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html
--
'peter'[:-1]@petertodd.org
On Sun, Dec 21, 2014 at 07:49:17AM -0600, paul snow wrote:
On Dec 20, 2014 8:49 AM, Peter Todd p...@petertodd.org wrote:
However the converse is not possible: anti-replay cannot be used to
implement proof-of-publication. Knowing that no conflicting message exists
says nothing about who
On Sun, Dec 21, 2014 at 10:01:37AM +, Adam Back wrote:
On 20 December 2014 at 14:48, Peter Todd p...@petertodd.org wrote:
We need the following primitives operating on message m, pubkey p, and a
valid signature sig1 for m, p:
AntiReplaySign(m, p, sig1) - sig2
On Sun, Dec 21, 2014 at 03:11:32PM +0800, Mark Friedenbach wrote:
On Sun, Dec 21, 2014 at 3:01 PM, Peter Todd p...@petertodd.org wrote:
Right, so Freimarkets is deliberately insecure.
Please define your terms, particularly what your security requirements are
here. In the architecture we
On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón wrote:
So let's go through an example to see in which ways
non-proof-of-publication orders are insecure.
Alice the seller wants to sell 1 unit of A for 100 units of B.
Bob is willing to pay up to 200 Bs for 1 A.
Let's assume a proof of
On Sun, Dec 21, 2014 at 06:10:47PM +, Adam Back wrote:
Yes you could for example define a new rule that two signatures
(double-spend) authorises something - eg miners to take funds. (And
this would work with existing ECDSA addresses unrestricted R-value
choices).
I wasnt really making
On Sat, Dec 20, 2014 at 09:48:01AM -0500, Peter Todd wrote:
Andrew Miller asked me to publish the following to the mailing list on his
behalf: (https://twitter.com/socrates1024/status/546819355565391872)
One of the main points in this note is that you can use a
proof-of-publication system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A big one is the privacy is way too good: every DNS request goes through
multiple levels of caching and indirection, so there's no way to figure out who
made the request to subject them additional targeting.
A connection-oriented protocol gets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29 December 2014 12:49:45 CET, Thomas Zander tho...@thomaszander.se wrote:
On Monday 29. December 2014 11.30.42 Mike Hearn wrote:
With the current DNS protocol you get an all or nothing choice
Its a seed. Not the protocol itself.
Firstly,
TxOut Hashcash,
Peter Todd, May 10th 2013,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html
--
'peter'[:-1]@petertodd.org
08bb7f424d81b7a0ea568086f4d320c2867705f88c27bb0a
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23 January 2015 08:35:23 GMT-08:00, slush sl...@centrum.cz wrote:
Oh, now I got the 'soft-fork' alternative. If that means that *senders*
to
Trezor need to be nice guys and use some special outputs, then it's,
obviously, no-go solution.
That's
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote:
Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically calculated miner fees, this
may often be ineffective:
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote:
Hi there,
comments in-line:
I later wrote up the idea in the context of adding Zerocoin to
Bitcoin:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
For the sake of maximum clarity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This is an incredibly dangerous and foolish proposal that opens up the Bitcoin
network to serious vulnerabilities, both from attackers outside the network, as
well as miners trying to gain an advantage over their competition.
Ultimately it's
On Tue, Jan 20, 2015 at 08:43:57AM -0800, Daniel Stadulis wrote:
Hey Peter,
What would you say to the argument: given developers have auto update
capabilities they only have the ability to *give themselves* *the ability* to
have custodial rights?
Heh, well, courts tend not to have the
I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have a custodial relationship with their users,
especially if they use auto-update mechanisms. Unfortunately this has
potential legal
On Tue, Jan 20, 2015 at 12:23:14PM -0500, Matt Whitlock wrote:
On Tuesday, 20 January 2015, at 10:46 am, Peter Todd wrote:
I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have
On Tue, Jan 20, 2015 at 12:47:04PM -0500, Matt Whitlock wrote:
On Tuesday, 20 January 2015, at 6:44 pm, Tamas Blummer wrote:
Knowing the private key and owning the linked coins is not necessarily the
same in front of a court.
At least in german law there is a difference between
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 January 2015 12:09:13 GMT-07:00, Jeff Garzik jgar...@bitpay.com wrote:
Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very
hash-able,
the list goes on.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
That's 100% true: BIP70 passes around serialized protobuf data that it signs
directly for this reason; it could just as easily be a byte array with json in
it. (not that json/XML/etc. doesn't have other flaws)
On 19 January 2015 13:03:32
On Thu, Feb 12, 2015 at 08:15:01PM +0100, Alan Reiner wrote:
The Bitcoin network achieves something that we didnt' think was possible
10 years ago: a totally trustless, decentralized ledger. The cost? It
takes time for the decentralized network to reach consensus that
transactions happened.
On Thu, Feb 12, 2015 at 07:49:29PM +, Gregory Maxwell wrote:
One challenge is that without rather smart child-pays-for-parent logic
the positive argument for replace by fee doesn't really work.
That's actually incorrect now, as a mechanism for implementing
scorched-earth without
On Thu, Feb 12, 2015 at 07:34:22PM +, Justus Ranvier wrote:
In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.
Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more
My replace-by-fee patch is now available for the v0.10.0rc4 release:
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
Along with demo scripts of the functionality:
https://github.com/petertodd/replace-by-fee-tools
New to this version is a comprehensive set of
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote:
On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote:
IOW, assume every transaction your border router gives you is now the
one and only true transaction, and everything conflicting with it must
go.
You
On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote:
Where is the Specification section?? Does this support arbitrary scripts, or
only the simplest CHECKMULTISIG case?
It might be enough to rewrite this BIP to basically say all pubkeys
executed by all CHECKMULTISIG opcodes will be in
On Sat, Jan 10, 2015 at 04:26:23AM +, Gregory Maxwell wrote:
The incompatibility is due to the OpenSSL update changing the
behavior of ECDSA validation to reject any signature which is
not encoded in a very rigid manner. This was a result of
OpenSSL's change for CVE-2014-8275 Certificate
On Fri, Jan 09, 2015 at 01:40:53PM +0200, Nathan Cook wrote:
Would you mind doing up some actual scriptPubKeys/transactions using
this idea as an example? I think it'd make the review process a lot
easier for everyone if there was something more concrete. (equally,
sorry I haven't had a chance to
I haven't bothered reading the thread, but I'll put this out there:
The consensus critical Satoshi-derived sourcecode is a protocol
*specification* that happens to also be machine readable and executable.
Rewriting it is just as silly as as taking RFC 791 and rewriting it
because you wanted to
On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote:
Peter,
An important use of the core is being border router to proprietary software,
that is usually indexing the block chain and mempool. That software is also
assuming that double spends are not relayed by the core.
To
On Sat, Feb 14, 2015 at 11:04:49AM -0800, Adam Back wrote:
Strongly with Peter on this. That its highly complex to maintain strict
consensus between bitcoin versions, does not justify consensus rewrite
experiments; it tells you that the risk is exponentially worse and people
should use and
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote:
On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote:
Yes you are dicking around.
I thought I was clear, that I am using Bitcoin Core as border router talking
to its P2P interface.
Ah, sorry, that wasn't clear
On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote:
Peter,
You did not address me but libbitcoin. Since our story and your evaluation is
probably similar, I chime in.
On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote:
So stop wasting your time. Help get
On Sun, Jan 04, 2015 at 05:44:59PM +, Gregory Maxwell wrote:
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Can you send me the actual raw transaction (that site doesn't appear
have a way to get it, only some cooked json output; which doesn't
include the
Repost of
https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo
for archival/disclosure purposes:
I'm very skeptical about the long-term viability of Factom and the value of the
Factom token.
The idea behind Factom is to create a
On Fri, Mar 20, 2015 at 12:46:18AM -0500, Brian Deery wrote:
Greetings mailing list.
Not sure that this content is 100% appropriate here, but Peter Todd
invited me to post this for archival purposes. The original thread
has been removed from the search results, but is still up here:
http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Would you so us all a favor and make a list of companies *actually* relying on
first-seen mempool behaviour. Because I've been having a hard time actually
finding anyone who does who hasn't given up on it. Not very useful to talk
about attacks
On Sun, Feb 22, 2015 at 08:02:03AM +, Adam Back wrote:
FWIW I've been advocating this kind of thing in various forms for
literally years, including to hold fidelity bonded banks honest - what
you now call 'federated sidechains' - and most recently Feb 12th on
#bitcoin-dev:
19:56 petertodd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com
wrote:
In case it wasn't clear in my earlier post, there's of course a third
possibility - namely, some outputs are kept but not all. Here, it is
generally impossible to
On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote:
My actual point outside of the emotive stuff (and I should've stayed
away from that too) is how about we explore ways to improve practical
security of fast confirmation transactions, and if we find something
better, then we can help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock b...@mattwhitlock.name
wrote:
On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
In other words, you are unprotected and potentially at greater risk
if you
create a transaction
On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote:
On 2/11/2015 10:47 PM, Peter Todd wrote:
My replace-by-fee patch is now available for the v0.10.0rc4 release:
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
This patch immediately simplifies successful
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik jgar...@bitpay.com wrote:
scorched earth refers to the _real world_ impact such policies would
have on present-day 0-conf usage within the bitcoin community.
I think you guys are reading too
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 imagine
an
On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote:
Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide
adoption of RBF (without a suitable replacement available) would make it
extremely difficult to pitch bitcoin as a viable alternative to credit cards
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY
implemented on Bitcoin will be something like summer 2016, a year and a half
after it got adopted on Viacoin. (and a few other alts whose names I forget)
Right now the
On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote:
And a new softfork rule could enforce that all new CTxIn set nHeight
to the correct height in which its corresponding prevout got into the
chain.
That would
My replace-by-fee patch is now available for the v0.10.1 release:
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1
No new features in this version; this is simply a rebase for the Bitcoin
Core v0.10.1 release. (there weren't even any merge conflicts) As with
the Bitcoin Core
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool
only CLTV pull-req²:
I like merging this, but doing both CLTV things in one swoop would be
really nice. Certainly if we're gonna use one of the precious few
OP_NOPs we have we might as well make it more flexible.
I
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote:
Hi William,
I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.
The two are complementary, not competing.
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote:
Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
Certainly a consensus in this kind of technical community should be a
basic requirement for any serious commitment to blocksize increase.
I'm afraid I have come to disagree. I no longer believe this community can
reach consensus
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote:
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
Peter: your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.
Satoshi's hacker had no illusions
On Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote:
Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote:
Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
The
On Fri, May 08, 2015 at 06:00:37AM -0400, Jeff Garzik wrote:
That reminds me - I need to integrate the patch that automatically sweeps
anyone-can-pay transactions for a miner.
You mean anyone-can-spend?
I've got code that does this actually:
On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote:
Matt,
It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the block.
I think it has potential for both scaling as well as keeping up a
. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
Actually the correct figure is less than ~30%:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
percent
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could
301 - 400 of 455 matches
Mail list logo
