On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon
flavien.char...@coinprism.com wrote:
My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel
The number one user of the blockchain as a storage and transport mechanism
is
On Nov 17, 2014 7:39 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
That is inevitable for any wallet that offers any functionality beyond
just maintaining a balance and the ability to send coins. In
particular, anything that wishes to list previous transaction (with
timestamps, history,
While I am not opposing the proposal, I am not sure about your statistics
because while Counterparty is not currently using OP_RETURN encoding, you
should factor in the number of CP transactions that would have been
OP_RETURNs if they had been permitted (100,000 since inception according
On Sun, Nov 16, 2014 at 5:21 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
Hi,
The data that can be embedded as part of an OP_RETURN output is currently
limited to 40 bytes. It was initially supposed to be 80 bytes, but got
reduced to 40 before the 0.9 release to err on the side of
On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com wrote:
On 11/16/2014 02:04 PM, Jorge Timón wrote:
I remember people asking in #bitcoin-dev Does anyone know any use
case for greater sizes OP_RETURNs? and me answering I do not know of
any use cases that require bigger sizes.
It seems to me that people maybe arriving at the idea that they should
put transaction data in the blockchain for three related reasons: a)
its there and its convenient; and b) they are thinking about permanent
storage and being able to recover from backup using a master seed to a
bip32
My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel
The number one user of the blockchain as a storage and transport mechanism
is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
from doing so. In fact
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
My main concern with OP_RETURN is that it seems to encourage people to use
the blockchain as a convenient transport channel
The number one user of the blockchain as a storage and transport mechanism
is
On 11/17/2014 06:20 AM, Adam Back wrote:
b) backup: the blockchain is not an efficient reliable generic backup
mechanism because its broadcast. there are cheaper and relatively
simple ways to get end2end secure backup, the main challenge of which
is having secure keys and not forgetting
On Mon, Nov 17, 2014 at 1:31 PM, Chris Pacia ctpa...@gmail.com wrote:
If users wishes to use stealth addresses with out of band communication, the
benefits of HD would largely be lost and they would be back to making
regular backups -- this time after every transaction rather than every 100.
I agree with Luke, we can endlessly discuss the best defaults like
the default size allowed for OP_RETURN, minimum fees, anti-dust
policies, first-seen vs replace-by-fee, etc; but the fact is that
policies depend on miners. Unfortunately most miners and pools are
quite apathetic when it comes to
As an aside, the decision to make it 40 bytes made sense because it is
enough for timestamping. In fact, you can do cheaper and even secret
(and thus impossible to censor by miners) timestamping using
pay-to-contract [1], which uses exactly 0 extra bytes in your
transaction and the blockchain.
I
On 11/16/2014 02:04 PM, Jorge Timón wrote:
I remember people asking in #bitcoin-dev Does anyone know any use
case for greater sizes OP_RETURNs? and me answering I do not know of
any use cases that require bigger sizes.
For reference, there was a brief time where I was irritated that the
size
13 matches
Mail list logo
