On 6 June 2013 23:48, Luke-Jr wrote:
> On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
> > > This doesn't work like you might think: first of all, the fees today
> are
> > > greatly subsidized - the actual cost to store data in the blockchain is
> > > much higher than most st
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
> > This doesn't work like you might think: first of all, the fees today are
> > greatly subsidized - the actual cost to store data in the blockchain is
> > much higher than most storage solutions. Secondly, only the miner receive
On 6 June 2013 21:59, Andreas M. Antonopoulos wrote:
> Is there any consideration given to the fact that bitcoin can operate as a
> platform for many other services, if it is able to be neutral to payload,
> as long as the fee is paid for the transaction size?
>
> Unless I have misunderstood this
Is there any consideration given to the fact that bitcoin can operate as a
platform for many other services, if it is able to be neutral to payload,
as long as the fee is paid for the transaction size?
Unless I have misunderstood this discussion, it seems to me that this is a
bit like saying in 19
> This doesn't work like you might think: first of all, the fees today are
> greatly subsidized - the actual cost to store data in the blockchain is
> much
> higher than most storage solutions. Secondly, only the miner receives the
> fees, not the majority of nodes which have to bear the burden of
On Thursday, June 06, 2013 7:59:16 PM Andreas M. Antonopoulos wrote:
> Is there any consideration given to the fact that bitcoin can operate as a
> platform for many other services, if it is able to be neutral to payload,
> as long as the fee is paid for the transaction size?
This doesn't work lik
On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> scriptPubKey: OP_TRUE
>
> ...
> Along with that change anyone-can-spend outputs should be make IsStandard()
> so they will be relayed.
Data does not belong in the blockchain. People running nodes have all
implicitly agreed to store the b
On Tue, Jun 04, 2013 at 02:49:54PM -0400, Jeff Garzik wrote:
> On Tue, Jun 4, 2013 at 2:36 PM, Roy Badami wrote:
> >> Sure they are paying themselves, but given bitcoin network
> >> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> >> transactions is itself difficult.
> >
> >
> Sure they are paying themselves, but given bitcoin network
> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> transactions is itself difficult.
Not for pool operators it isn't. Nor for people buying hashing power
from a GPUMAX-type service, if such services still exist (or
On Tue, Jun 4, 2013 at 2:36 PM, Roy Badami wrote:
>> Sure they are paying themselves, but given bitcoin network
>> difficulty is uso high, simply obtaining payments-go-myself-as-miner
>> transactions is itself difficult.
>
> Not for pool operators it isn't. Nor for people buying hashing power
> f
On Tue, Jun 4, 2013 at 10:55 AM, John Dillon
wrote:
>> I'm one of the people experimenting in this area. I've long argued
>> that a zero-output transaction should be permitted -- 100% miner fee
>> -- as an elegant proof of sacrifice. Unfortunately that requires a
>> hard fork. Also, for most pe
On Sun, Jun 2, 2013 at 5:45 PM, Adam Back wrote:
> d) some new standardized spend to fees (only miners can claim).
> so if I understand what you proposed d) seems like a useful concept if that
> is not currently possible. eg alternatively could we not just propose a
> standard recognized address
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> I'm one of the people experimenting in this area. I've long argued
> that a zero-output transaction should be permitted -- 100% miner fee
> -- as an elegant proof of sacrifice. Unfortunately that requires a
> hard fork. Also, for most people, it
On Mon, Jun 3, 2013 at 5:43 PM, Melvin Carvalho wrote:
> Sorry if this is a stupid question, but why would someone want to
> sacrifice their bitcoins?
>
Good question. One reason is https://en.bitcoin.it/wiki/Fidelity_bonds
Cheers,
Michael
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote:
>> Feels like a new opcode might be better.
>>
>> Eg 100 OP_NOP1
>>
>> ... Where op_nop1 is redefined to be 'verify depth' ...
I would suggest the more general 'push depth onto stack'. You can t
On 1 June 2013 21:30, Peter Todd wrote:
> Currently the most compact way (proof-size) to sacrifice Bitcoins that
> does not involve making them unspendable is to create a anyone-can-spend
> output as the last txout in the coinbase of a block:
>
> scriptPubKey: OP_TRUE
>
> The proof is then the S
So the idea is that people may want to use proof-of-work unrelated to
bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC
(and with a published USD exchange rate). And the ways they can do that are
to:
a) create unspendable addresses (which maybe you cant compact in the U
On Sun, Jun 02, 2013 at 01:35:10PM -0400, Jeff Garzik wrote:
> It is a fair criticism that this inches the incentives, a bit, towards
> timestamping and other non-currency uses. But those uses (a) cannot
> be prevented and (b) have already been automated anyway (e.g. the
> python upload/download t
On Sun, Jun 2, 2013 at 2:13 AM, Peter Todd wrote:
> I'd say we tell people to sacrifice to (provably) unspendable for now
> and do a soft-fork later if there is real demand for this stuff in the
> future.
That seems fair.
In general, people are actively bloating the UTXO set with unspendable
out
On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote:
> Feels like a new opcode might be better.
>
> Eg 100 OP_NOP1
>
> ... Where op_nop1 is redefined to be 'verify depth' ...
Good idea.
Either way, looks like complex announce-commit logic isn't needed and a
simple txout with one of a few p
On Sat, Jun 01, 2013 at 08:34:29PM +, Luke-Jr wrote:
> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> > scriptPubKey: OP_TRUE
> >
> > ...
> > Along with that change anyone-can-spend outputs should be make IsStandard()
> > so they will be relayed.
>
> Data does not belong in the bl
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
output as the last txout in the coinbase of a block:
scriptPubKey: OP_TRUE
The proof is then the SHA256 midstate, the txout, and the merkle path to
the
22 matches
Mail list logo
