Troy Benjegerdes wrote:
> Mark Friedenbach wrote:
>> Bitcoin is not a centralized system, and neither is its development. I
>> don't even know how to respond to that. Bringing up altchains is a total
>> red herring.
>>
>> This is *bitcoin*-development. Please don't make it have to become a
>> moder
On Mon, Mar 24, 2014 at 01:57:14PM -0700, Mark Friedenbach wrote:
> On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
> > I'm here because I want to sell corn for bitcoin, and I believe it will be
> > more profitable for me to do that with a bitcoin-blockchain-based system
> > in which I have the cap
On Saturday, March 22, 2014 8:47:02 AM Peter Todd wrote:
> To make a long story short, it was soon suggested that Bitcoin Core be
> forked - the software, not the protocol - and miners encouraged to
> support it.
There's been at least one public miner-oriented fork of Bitcoin Core since 0.7
or ea
On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
> I'm here because I want to sell corn for bitcoin, and I believe it will be
> more profitable for me to do that with a bitcoin-blockchain-based system
> in which I have the capability to audit the code that executes the trade.
A discussion over such
I think that's fair, so long as we limit bitcoin-development discussion to
issues that are relevant to the owners of the hashrate and companies that
pay developer salaries.
What I'm asking for is some honesty that Bitcoin is a centralized system
and to stop arguing technical points on the altar of
This isn't distributed-systems-development, it is bitcoin-development.
Discussion over chain parameters is a fine thing to have among people
who are interested in that sort of thing. But not here.
On 03/23/2014 04:17 PM, Troy Benjegerdes wrote:
> I find it very irresponsible for Bitcoiners to on o
> > Right, but there's also a lot of the community who thinks
> > proof-of-publication applications are bad and should be discouraged. I
> > argued before that the way OP_RETURN was being deployed didn't actually
> > give any reason to use it vs. other data encoding methods.
> >
> > Unfortunately u
On Sat, Mar 22, 2014 at 03:08:25PM -0400, Peter Todd wrote:
> On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
> > On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> > > There's been a lot of recent hoopla over proof-of-publication, with the
> > > OP_RETURN length getti
On 3/22/14, Peter Todd wrote:
> Well remember that my thinking re: UTXO is that we need to move to a
> system like TXO commitments where storing the entirety of the UTXO set
> for all eternity is *not* required. Of course, that doesn't necessarily
> mean you can't have the advantages of UTXO commi
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote:
> On 3/22/14, Peter Todd wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN length getting reduced to a rather useless 40 bytes at
> > the last minute prior to the 0.9 release.
>
>
> I'm n
On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
> On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN length getting reduced to a rather useless 40 bytes at
> > the last minute prior
Please, by all means: ignore our well-reasoned arguments about
externalized storage and validation cost and alternative solutions.
Please re-discover how proof of publication doesn't require burdening
the network with silly extra data that must be transmitted, kept, and
validated from now until the
On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
> There's been a lot of recent hoopla over proof-of-publication, with the
> OP_RETURN length getting reduced to a rather useless 40 bytes at
> the last minute prior to the 0.9 release. Secondly I noticed a
> overlooked security flaw in th
On 3/22/14, Peter Todd wrote:
> There's been a lot of recent hoopla over proof-of-publication, with the
> OP_RETURN length getting reduced to a rather useless 40 bytes at
> the last minute prior to the 0.9 release.
I'm not against about miners accepting transactions that have longer
data in no
14 matches
Mail list logo
