On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should explicitly
> define one rather than relying on “prima facie” assumptions. Otherwise, I
> would recommend not relying on the existence of a signed transaction as proof
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
> >
> > > So connecting to many nodes just because we can and it's not technically
> > > prevented is bad for the network and creating systemic risks of failure,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, an
On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd wrote:
> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> > It is disappointing that F2Pool would enable full RBF when the safe
> > alternative, first-seen-safe RBF, is also available, especially since the
>
On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote:
> >
> > Unless you're sybil attacking the network and miners, consuming valuable
> > resources and creating systemic risks of failure like we saw with
> > Chainalysis, I don't see how you're getting "very small" double-spend
> > probab
On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote:
> On 2015-06-19 10:39, Peter Todd wrote:
>
> Yesterday F2Pool, currently the largest pool with 21% of the hashing
> power, enabled full replace-by-fee (RBF) support after discussions
> with
>
On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote:
> > In that case would you enter into such contracts?
> >
>
> We take it as it comes.
>
> Currently, it's perfectly possible to accept zeroconf transactions with
> only a very small chance of double spend. As long as it's only possib
On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:
> >
> > For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transa
On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote:
> I just sent the following email to F2Pool:
>
>
> I was disappointed to see Peter Todd claiming that you have (or will?) run
> his replace-by-fee patch.
>
> I strongly encourage you to wait until most wal
On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote:
> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
No worries, let me know if you have any issues. You have my phone
number.
While my own preference - and a number of other devs - is full-RBF,
either one is a good
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. D
XT nodes.
Secondly, try out my replace-by-fee-tools at:
https://github.com/petertodd/replace-by-fee-tools
You can watch double-spends on the network here:
http://respends.thinlink.com/
References
--
1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
v
On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote:
> > Agreed. Pieter Wuille's recent work is a great example of the kind of
> > science-driven investigations that need to be done - and haven't been
> > done very much - to get us some hard data to make decisions on.
> >
>
> Thank you ver
On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:
> Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
> should at least prevent nodes from crashing. When I looked a few days ago I
> only found a few old PRs that seemed to have fallen by the wayside, so this
> n
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote:
> On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille
> wrote:
>
> > It's simple: either you care about validation, and you must validate
> > everything, or you don't, and you don't validate anything. Sidechains do
> > not offer you a useful
On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
> This is very well done.
>
> Have you seen this discussion that I started regarding BIP 63?
>
> https://bitcointalk.org/index.php?topic=1083961.0
>
> I have no response from Peter Todd back on it other than "
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> On Tue, Jun 16, 2015 at 2:03 AM, Adam Back wrote:
> Dear Adam, All:
>
> At the community's convenience, it would be an honour to arrange an initial
> open summit to meet with representatives of the Chinese miners in Hong Kong
> (UTC+8
On Mon, Jun 15, 2015 at 12:23:44AM +0200, Mike Hearn wrote:
> >
> > One thing that is concerning is that few in industry seem inclined to
> > take any development initiatives or even integrate a library.
>
>
> Um, you mean except all the people who have built more scalable wallets
> over the past
On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote:
> I think the whole complexity talk is missing the bigger issue.
>
> Sure, per block validation scales linearly (or quasilinearly…there’s an O(log
> n) term in there somewhere but it’s probably dominated by linear factors at
> curren
On Sun, Jun 14, 2015 at 11:15:18AM -0400, Jeff Garzik wrote:
> * ACK on moving away from SourceForge mailing lists - though only once a
> community-welcomed replacement is up and running
>
> * ACK on using LF as a mailing infrastructure provider
>
> * Research secure mailing list models, for bitc
On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote:
> This is a misguided idea, to say the least. If such a mechanism of of
> user input would be possible, one would use it for transaction
> verification in the first place. In proof-of-stake outcomes are
> determined by vote by stake (that vo
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > Why should miners only be able to vote for "double the limit" or "h
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which they
> > claim in th
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> Why should miners only be able to vote for "double the limit" or "halve" the
> limit? If you're going to use bits, I think you need to use two bits:
>
> 0 0 = no preference ("wildcard" vote)
> 0 1 = vote for the limit to
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> Nice work, Pieter. You're right that my simulation assumed bandwidth for
> 'block' messages isn't the bottleneck.
>
> But doesn't Matt's fast relay network (and the work I believe we're both
> planning on doing in the near future to
Jeff Garzik recently proposed that the upper blocksize limit be removed
entirely, with a "soft" limit being enforced via miner vote, recorded by
hashing power.
This mechanism within the protocol for users to have any influence over
the miner vote. We can add that back by providing a way for transa
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote:
> The configuration used in the code right now simulates two groups of miners
> (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
> internally, but are only connected to each other through a slow 2 Mbit/s
> link.
>
>
Summary
---
The BIP66 soft-fork recently passed the 75% support threshold. This
means that 75% of the hashing power has upgraded to support BIP66; 25%
of the hashing power has not. Once 95% of the hashing power has
upgraded, blocks created by the 5% who have not upgraded will be
rejected.
If
On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
> The other complication is that this will tend to be a lagging indicator
> based on network congestion from the last time you connected. If we assume
> that transactions are being dropped in an unpredictable way when blocks are
> full,
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine wrote:
>
> > It could be done by agreeing on a data format and encoding it in an
> > op_return output in the coinbase transaction. If it catches on it could
> > later be enforced with a
On Wed, Jun 10, 2015 at 03:36:42PM -0400, Andy Schroder wrote:
> It's possible that the enigmail extension is not working right, but
> I was under the impression that it is just feeding data to gpg and
> then receiving the response back. It's possible that your e-mail you
> just checked was not sen
On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote:
>
> Andy Schroder
>
> On 06/10/2015 03:03 PM, Peter Todd wrote:
> >
> >>4. Seems like digital signatures are always broken on messages because
> >>the list server slightly modifies them (?),
On Wed, Jun 10, 2015 at 02:59:48PM -0400, Andy Schroder wrote:
> Hello,
>
> A couple of motivations for a mailing list switch:
>
> 1. Sometimes the mailing list delays delivery for 10 minutes to several
>days.
> 2. There are usually lots of ads at the footer of the messages. Really
>confu
First-seen-safe Replace-by-Fee is now available as a patch against
v0.10.2:
https://github.com/petertodd/bitcoin/tree/first-seen-safe-rbf-v0.10.2
I've also had a pull-req against git HEAD open for a few weeks now:
https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829
I've
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
Two other things:
> On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd wrote:
>
> > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > protocols; you haven't taken into account the n
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote:
> There was this wonderful technology invented a few years ago to deal with
> spam. It's called Hashcash. All these hacky heuristics like block size are
> just dancing around the problem, and the natural solution is already present
>
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote:
> With the 0.01mBTC/KB minimum
> relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
>
> IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and
> $23k/GB (assuming $23 * 1000, as each $2
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote:
> >There will always be a blocksize limit based on technological
> >considerations - the network has a finite bandwidth limit.
>
> A bandwidth limit is not the same as a blocksize limit. Bandwidth
> is unique to every individual. Miners
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spam
> transactions, the attack succeeds when the attacker is well funded. This
> gives well-funded private and/or public enti
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote:
> FWIW, The Open Assets colored coin protocol (CoinPrism) places special
> significance on the zeroth input and the position of the OP_RETURN colored
> coin marker output to distinguish colored coin issuance outputs from
> transfer outpu
On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > there is no memory pool cap currently
>
> Real hardware does not have an infinite amount of RAM. Memory pool sizes
> cannot grow unbounded. Some transactions with insufficient fees do get
> dropped today after many hours.
Actuall
On Sat, Jun 06, 2015 at 08:06:56PM -0400, Kristov Atlas wrote:
In general I think this is a good idea, and should be implemented; we've
had a depressing number of wallets fail to implement randomization
properly, if at all.
> I've updated the draft BIP in two ways:
> -Making it clear that sorting
On Sat, Jun 06, 2015 at 05:23:48PM +0200, Pieter Wuille wrote:
> On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr wrote:
>
> > I also agree with Pieter, that this should *not* be so cleanly compatible
> > with Bitcoin transactions. If you wish to share code, perhaps using an
> > invalid opcode rather
On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn wrote:
>
> > Whilst it would be nice if miners in China can carry on forever regardless
> > of their internet situation, nobody has any inherent "right" to mine if
> > they can't do the job -
On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network. So far top 100 biggest bitcoin blocks are all from us. We
> do support bigger blocks and sooner rather than later. But we cannot
> handle 20 MB blocks r
On Thu, May 28, 2015 at 01:19:44PM -0400, Gavin Andresen wrote:
> As for whether there "should" be fee pressure now or not: I have no
> opinion, besides "we should make block propagation faster so there is no
> technical reason for miners to produce tiny blocks." I don't think us
> developers shoul
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:
> Can you update it so that it only applies to transactions with version
> number 3 and higher. Changing the meaning of a field is exactly what the
> version numbers are for.
>
> You could even decode version 3 transactions like that.
>
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote:
> On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote:
> I think it would be better to have the deadlines set as block counts. That
> eliminates the need to use the median time mechanism.
The median time mechanism is basically a way for hashing power to show
what time they think it is. Equal
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
> Sequence numbers appear to have been originally intended as a mechanism for
> transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel. The idea is that a participant
> can s
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote:
> Case 1: Increasing the fee on a single tx
> -
>
> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
> with the minimal relay fee, 2.26uBTC. Increasin
On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
> What is wrong with the man testing some ideas on his custom branch? This
> is how improvements come to life. I saw in the BIPs some really
> interesting ideas and nice brainstorming which came from Peter Todd.
>
> Now, my quest
On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
> On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> > Do any wallets actually do this yet?
>
> Not that I know of, but they do seed their address database via DNS, which
> you can poison if you control the LAN's DNS resolver.
Summary
---
First-seen-safe replace-by-fee (FSS RBF) does the following:
1) Give users effective ways of getting "stuck" transactions unstuck.
2) Use blockchain space efficiently.
without:
3) Changing the status quo with regard to zeroconf.
The current Bitcoin Core implementation has "firs
On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> CPFP also solves it just fine.
CPFP is a significantly more expensive way of paying fees than RBF,
particularly for the use-case of defragmenting outputs, with cost
savings ranging from 30% to 90%
Case 1: CPFP vs. RBF for increasing t
On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote:
> Wallets are incentivised to do a better job with defragmentation already,
> as if you have lots of tiny UTXOs then your fees end up being huge when
> trying to make a payment.
>
> The reason they largely don't is just one of manpower. N
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
> > I see this behavior all the time. I am using the latest release, as far as
> > I know. Version 4.30.
> >
> > The same behavior occurs in the Testnet3 variant of the app. Go in there
> > with an empty wallet and receive one p
My replace-by-fee patch is now available for the Bitcoin Core v0.10.2
release:
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
This release fixes a serious DoS attack present in previous releases.
Upgrading is strongly recommended for relay nodes, and mandatory for
miners. Us
f attackers by
outspending them after the fact, while keeping sacrifices low in the
general case; the sacrifice could even be crowdfunded with
SIGHASH_ANYONECANPAY transactions)
1) "[Bitcoin-development] Disentangling Crypto-Coin Mining: Timestamping,
Proof-of-Publication, and Validation&quo
On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote:
> It should actually be straightforward to softfork RCLTV in as a negative CLTV.
> All nLockTime are >= any negative number, so a negative number makes CLTV a
> no-op always. Therefore, it is clean to define negative numbers as relative
On Tue, May 12, 2015 at 09:05:44AM -0700, Jeff Garzik wrote:
> A general assumption is that you will have a few archive nodes with the
> full blockchain, and a majority of nodes are pruned, able to serve only the
> tail of the chains.
Hmm?
Lots of people are tossing around ideas for partial archi
takes too much
> time to verify or bandwidth to transmit. This is currently true on the
> Bitcoin network. Nevertheless there is no such incentive for miners,
> since they will be shooting on their own foots. Peter Todd has argued
> that the best strategy for miners is actually to rea
On Sun, May 10, 2015 at 05:45:32PM -0300, Sergio Lerner wrote:
> Two years ago I presented a new way to create a fee market that does not
> depend on the block chain limit.
> Solution: Require that the set of fees collected in a block has a
> dispersion below a threshold. Use, for example, the C
On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote:
> The vast majority of users are running one of a handful of different wallet
> apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
> Blockchain.info; and maybe a few others. The developers of all these
> wallets have
On Sat, May 09, 2015 at 01:36:56AM +0300, Joel Joonatan Kaartinen wrote:
> such a contract is a possibility, but why would big owners give an
> exclusive right to such pools? It seems to me it'd make sense to offer
> those for any miner as long as the get paid a little for it. Especially
> when it'
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote:
> On Sat, May 9, 2015 at 12:00 AM, Damian Gomez wrote:
> > where w represents the weight of the total number of semantical
> > constraints that an idivdual has expressed throught emotivoe packets that I
> > am working on (implementat
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:
> >
> > 1 OP_CLTV
> >
> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> > future relative CLTV co
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
> On Fri, May 8, 2015 at 5:37 PM, Peter Todd wrote:
>
> > The soft-limit is there miners themselves produce smaller blocks; the
> > soft-limit does not prevent other miners from producing larger blocks.
> >
&
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
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:
https://github.com/petertodd/replace-by-fee-tools/
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.
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 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 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 06:21:50PM +0200, Jorge Timón wrote:
> On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen
> wrote:
> > I would very much like to find some concrete course of action that we can
> > come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> > how much transac
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote:
> Peter Todd writes:
> > That said, if people have strong feelings about this, I would be willing
> > to make OP_CLTV work as follows:
> >
> > 1 OP_CLTV
> >
> > Where the 1 selects absolute
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote:
> On 05/07/2015 04:49 PM, Peter Todd wrote:
> >
> > I think we'll find an basic assumption of civility to be more
> > productive, until proven otherwise. (e.g. NSA ties)
>
> I'm not sure
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote:
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
> fast Internet connection, and assume Nelson's law to increase over time),
> and
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote:
> On 05/07/2015 04:04 PM, Jeff Garzik wrote:
> > - This is a major change to the economics of a $3.2B system. This
> > change picks winners and losers. There is attendant moral hazard.
>
> This is exactly true.
>
> There are a numb
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
> > One thing is the Bitcoin core project where you could argue that the 5
> > committers decide (I don't know why Wladimir would have any more
> > authority than the others).
> >
>
> Because he is formally the maintainer.
I quite liked
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote:
> I have a lot more written down, a WIP; here are the highlights.
>
> - The 1MB limit is an ancient anti-spam limit, and needs to go.
>
> - The 1MB limit is economically entrenched at this point, and cannot be
> removed at a whim.
>
>
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 illusi
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote:
> What if Gavin popped up right now and said he disagreed with every current
> proposal, he disagreed with side chains too, and there would be no
> consensus on any of them until the block size limit was raised.
>
> Would you say, oh, OK,
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 c
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
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 ve
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
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 v
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
-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 shor
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 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 remove the
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 compe
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
> pa
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 OP_RELATIVECHECKLOCKTIME
On Thu, Apr 09, 2015 at 10:56:20PM -0400, Stephen Morse wrote:
> On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd wrote:
>
> > For the OP: Have you looked at how CODESEPARATOR allows the signature to
> > sign code to run as part of verifying the signature? E.g. my signature
> &g
On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote:
> On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse
> wrote:
>
> > Is hashing transaction data once for each input really a huge bottleneck,
> > though? Do mobile devices have an issue with this?
> >
>
>
> Think about what slow transactio
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 i
-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 a
On Thu, Mar 26, 2015 at 02:26:59PM -0700, Tom Harding wrote:
> On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> > Which is why a simpler, safer, client enforced behavior is probably
> > preferable. Someone who wants to go hack their client to make a
> > payment that isn't according to the payee will
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 proof-of-public
GMT-05:00, Tom Harding wrote:
>On 2/22/2015 9:12 AM, Peter Todd wrote:
>> Did you notice the even more obvious way to defeat ANYONECANPAY
>> scorched earth with that patch?
>
>Let's see. I could pay 10 people 1 BTC each with one tx, then
>double-spend it with fees of
1 - 100 of 578 matches
Mail list logo
