Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-20 Thread Jean-Pierre Rupp
Agree,

There are many legitimate uses for a larger OP_RETURN, and application 
developers are already complaining that the current size is not enough.  It is 
about adding value to the blockchain.  I know it can grow the blockchain 
faster, but so far at 40 bytes Bitcoin hasn't experienced death by bloat, nor 
that is even close to happen.  I understand starting with a prudent approach, 
but I think it is safe to increase this without worrying.  Actually I would 
make it even bigger than 80 bytes.

Cheers

On 17/11/14 02:30, Wladimir wrote:
 Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
 about the actual size.

-- 
Be Happy :)


0x310A8A5B.asc
Description: application/pgp-keys
attachment: root.vcf--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-18 Thread Btc Drak
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 Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
 from doing so. In fact they use multi-sig outputs which is worse than
 OP_RETURN since it's not always prunable, and yet let them store much more
 than 40 bytes.

 For Open Assets https://github.com/OpenAssets/open-assets-protocol, we
 need to store a URL in the OP_RETURN output (with optionally a hash) plus
 some bytes of overhead. 40 bytes comes really short for that. The benefit
 of having a URL in there is that any storage mechanism can be used (Web,
 FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
 hardcode the storing mechanism in the protocol (and even then, a hash is
 not enough to address a HTTP or FTP resource). Storing only a hash is fine
 for the most basic timestamping application, but it's hardly enough to
 build something interesting.

 I've counted the number of OP_RETURN outputs in the blockchain for the
 month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
 blocks. Assuming they were all 40 bytes (the average is probably less than
 half of that), that means an increase of 14.37 bytes per block. Considering
 a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
 in average.

 Increasing to 80 bytes will have a negligible impact on bandwidth and
 storage requirements, while being extremely useful for many use cases where
 a hash only is not enough.


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
their blog[1] with monthly charts at their block explorer[2]).

Refs:
[1]
http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/
[2] http://blockscan.com/
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-18 Thread Chris Pacia
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, metadata, messages sent using t
 What HD wallets (or any type of deterministic derivation scheme) offer
 is the fact that you can separate secret data and public data. You
 only need one safe backup of the master secret key - all the rest can
 at most result in privacy loss and not in lost coins.

 --
 Pieter

I agree but right now wallets not using stealth will only lose metadata,
not coins, if their computer crashes and they have the seed backed up.

But if a user wants to upgrade to stealth, they then risk losing metadata
AND coins if they either didn't manually back up after every transaction or
use a centralized cloud backup service.

That's if OP_RETURN is not utilized for storage.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-18 Thread Flavien Charlon

 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
 their blog[1] with monthly charts at their block explorer[2]).


Sure, but even if they are not permitted to store their data in OP_RETURN,
they will still store it in the blockchain in bare multisig outputs, so
it's not contributing to an overhead (in fact, it would consume less space
in the blockchain if they used OP_RETURN).

On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak btcd...@gmail.com wrote:

 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 Counterparty, and limiting OP_RETURN to 40 bytes didn't
 prevent them from doing so. In fact they use multi-sig outputs which is
 worse than OP_RETURN since it's not always prunable, and yet let them store
 much more than 40 bytes.

 For Open Assets https://github.com/OpenAssets/open-assets-protocol, we
 need to store a URL in the OP_RETURN output (with optionally a hash) plus
 some bytes of overhead. 40 bytes comes really short for that. The benefit
 of having a URL in there is that any storage mechanism can be used (Web,
 FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
 hardcode the storing mechanism in the protocol (and even then, a hash is
 not enough to address a HTTP or FTP resource). Storing only a hash is fine
 for the most basic timestamping application, but it's hardly enough to
 build something interesting.

 I've counted the number of OP_RETURN outputs in the blockchain for the
 month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
 blocks. Assuming they were all 40 bytes (the average is probably less than
 half of that), that means an increase of 14.37 bytes per block. Considering
 a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN
 data in average.

 Increasing to 80 bytes will have a negligible impact on bandwidth and
 storage requirements, while being extremely useful for many use cases where
 a hash only is not enough.


 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
 their blog[1] with monthly charts at their block explorer[2]).

 Refs:
 [1]
 http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/
 [2] http://blockscan.com/


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Wladimir
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 caution.

 After 9 months, it seems OP_RETURN did not lead to a blockchain catastrophe,

Agreed. I'm in favor of increasing OP_RETURN size as well. Don't care
about the actual size.

(rationale: pruning is going to land soonish, and everything is better
than UTXO-polluting methods that encode everything into addresses such
as now used by cryptograffiti)

Wladimir

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
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.

 For reference, there was a brief time where I was irritated that the
 size had been reduced to 40 bytes, because I had an application where I
 wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
 need at least 64 bytes for that.   Unfortunately I can't remember now
 what that application was, so it's difficult for me to argue for it.
 But I don't think that's an unreasonable use case:  sending a payment
 with a signature, essentially all timestamped in the blockchain.

You can still send the signature out of band (for example using the
payment protocol), and just have the transaction commit to a hash of
that signature (or message in general), either using an OP_RETURN
output to store the hash, or using the pay-to-contract scheme that
Jorge mentioned above. That has exactly the same timestamping
properties.

My main concern with OP_RETURN is that it seems to encourage people to
use the blockchain as a convenient transport channel, rather than just
for data that the world needs to see to validate it. I'd rather
encourage solutions that don't require additional data there, which in
many cases (but not all) is perfectly possible.

-- 
Pieter

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Adam Back
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 address-set and want that logic to extend to the extra features;
c) they are thinking out of band, but they think they are forced to
send the data there in order to achieve atomicity.

I think the data that is sent on the blockchain is design-compressed
minimal necessary to achieve transaction integrity, and its important
for scalability that we keep it that way.  About the rationales for
using that scarce scalability impacting channel:

a) convenience: is not a great reason to my mind. there are lots of
channels: email, web forms, point2point various transports NFC, TCP,
HTTP for payment protocol or extensions or new protocols.  I think
there could be a need for a reliable privacy preserving store and
forward decentralised infrastructure to act as a channel for such
purposes.  Until then email could be pretty convenient, if you dont
get the message due to spam filter etc ask them to resend.  Or a web
storage locker related to the app.

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 them.  bitcoin already has
that covered as its a central requirement of blockchain security.  If
you want to archive your payment protocol receipts store them on some
cloud storage service or disk encrypted with related keys.  for
example tahoe-lafs is optimised for the decentralised long-term
storage kind of use.

c) atomicity. as an example application requiring atomicity that may
use op_return stealth addresses where if the stealth auxiliary message
was sent out of band, then if message is lost, and the sender didnt
keep it or cant be relied on to care, then the money could be
permanently lost to both parties.

It occurred to me recently the kind of use requiring atomicity as
stealth address in c) can be achieved by sending both the extra
message (the stealth packet) AND the signed bitcoin transaction over
the reliable store  forward (eg email for now).  Then the recipient
can do the calculations involving the auxiliary message and payment
message, and relay the message to the blockchain IFF they receive the
message (and chose to accept it).  If they dont receive the message
they can ask for it to be resent.  And if the payment is unclaimed the
sender still owns it and can double-spend to avoid risk of later
spending in their replacement message, or double-spend to self if the
recipient declines the payment.  This has privacy, efficiency and SPV
advantages over sending to the blockchain.

I think we could make a case that as a design principle auxiliary data
could do with a bitcoin-related but separate reliable store and
forward channel, as email has been sufficiently spammed to end up with
loss of reliability.  So I think a payment message transport would be
good here: invoices  receipts, and other things necessary for
applications, transaction disputes, records for normal p2p trades and
business functions reliable store and forward substrate with
decentralisation  privacy. For email the existing mechanism with
closest semantics, add-on privacy features exist: mixmaster,
nymservers, webmail + encryption, webmail over Tor etc for privacy
related uses.  Slow transports can offer better security than
interactive transports.

Adam

On 17 November 2014 10:35, Pieter Wuille pieter.wui...@gmail.com wrote:
 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.

 For reference, there was a brief time where I was irritated that the
 size had been reduced to 40 bytes, because I had an application where I
 wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
 need at least 64 bytes for that.   Unfortunately I can't remember now
 what that application was, so it's difficult for me to argue for it.
 But I don't think that's an unreasonable use case:  sending a payment
 with a signature, essentially all timestamped in the blockchain.

 You can still send the signature out of band (for example using the
 payment protocol), and just have the transaction commit to a hash of
 that signature (or message in general), either using an OP_RETURN
 output to store the hash, or using the pay-to-contract scheme that
 Jorge mentioned above. That has exactly the same timestamping
 properties.

 My main concern with OP_RETURN is that it seems to encourage people to
 use the blockchain as a convenient transport 

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Flavien Charlon
 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 they use multi-sig outputs which is worse than
OP_RETURN since it's not always prunable, and yet let them store much more
than 40 bytes.

For Open Assets https://github.com/OpenAssets/open-assets-protocol, we
need to store a URL in the OP_RETURN output (with optionally a hash) plus
some bytes of overhead. 40 bytes comes really short for that. The benefit
of having a URL in there is that any storage mechanism can be used (Web,
FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
hardcode the storing mechanism in the protocol (and even then, a hash is
not enough to address a HTTP or FTP resource). Storing only a hash is fine
for the most basic timestamping application, but it's hardly enough to
build something interesting.

I've counted the number of OP_RETURN outputs in the blockchain for the
month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
blocks. Assuming they were all 40 bytes (the average is probably less than
half of that), that means an increase of 14.37 bytes per block. Considering
a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
in average.

Increasing to 80 bytes will have a negligible impact on bandwidth and
storage requirements, while being extremely useful for many use cases where
a hash only is not enough.

Flavien

On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille pieter.wui...@gmail.com
wrote:

 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.
 
  For reference, there was a brief time where I was irritated that the
  size had been reduced to 40 bytes, because I had an application where I
  wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
  need at least 64 bytes for that.   Unfortunately I can't remember now
  what that application was, so it's difficult for me to argue for it.
  But I don't think that's an unreasonable use case:  sending a payment
  with a signature, essentially all timestamped in the blockchain.

 You can still send the signature out of band (for example using the
 payment protocol), and just have the transaction commit to a hash of
 that signature (or message in general), either using an OP_RETURN
 output to store the hash, or using the pay-to-contract scheme that
 Jorge mentioned above. That has exactly the same timestamping
 properties.

 My main concern with OP_RETURN is that it seems to encourage people to
 use the blockchain as a convenient transport channel, rather than just
 for data that the world needs to see to validate it. I'd rather
 encourage solutions that don't require additional data there, which in
 many cases (but not all) is perfectly possible.

 --
 Pieter


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
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 Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from
 doing so. In fact they use multi-sig outputs which is worse than OP_RETURN
 since it's not always prunable, and yet let them store much more than 40
 bytes.

It wasn't limited to stop them from using it. It was limited to avoid
giving others the impression that OP_RETURN was intended for data
storage. For the intended purpose (making a transaction commit to some
external data) a 32-byte hash + 8 byte id is more than sufficient.

 For Open Assets, we need to store a URL in the OP_RETURN output (with
 optionally a hash) plus some bytes of overhead. 40 bytes comes really short
 for that. The benefit of having a URL in there is that any storage mechanism
 can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash,
 you have to hardcode the storing mechanism in the protocol (and even then, a
 hash is not enough to address a HTTP or FTP resource). Storing only a hash
 is fine for the most basic timestamping application, but it's hardly enough
 to build something interesting.

Do you really need that data published to everyone? You're at the very
least exposing yourself to censorship, and (depending on the design)
potentially decreased privacy for your users. I would expect that for
most colored coin applications, just having the color transfer
information in external data sent directly to the receiver with
transactions committing to it should suffice.

-- 
Pieter

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Jorge Timón
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
flavien.char...@coinprism.com wrote:
 Storing only a hash
 is fine for the most basic timestamping application, but it's hardly enough
 to build something interesting.

No, storing only a hash is enough for ALL timestamping applications.
If you need to broadcast more data then we're not talking about
timestamping anymore, but rather proof of publication.
Unfortunately (and as it has been already mentioned) many applications
don't need proof of publication and yet they are just using the
blockchain as a convenient transport mechanism, but that's highly
inefficient.
It's like if you sent all your mails to all the existing email
addresses with the metadata to be read by: destinat...@yourhost.com.
It wouldn't make any sense and it wouldn't scale.
A url definitely looks like something that doesn't belong in the chain.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Chris Pacia

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 them.  bitcoin already has
 that covered as its a central requirement of blockchain security.  If
 you want to archive your payment protocol receipts store them on some
 cloud storage service or disk encrypted with related keys.  for
 example tahoe-lafs is optimised for the decentralised long-term
 storage kind of use.

This is my main concern in the context of stealth addresses. I intend to
start a larger discussion on stealth addresses, but I wont hijack the
tread.

Of course it's easy to send the necessary data out of band as opposed to
OP_RETURN. The problem is if you do that the transaction cannot not be
recovered from seed. We've been fairly successful in transitioning to HD
wallets and avoiding the need to make regular wallet backups.

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.

There are only a couple options in such cases:

1) The user could send the payment to an addresses that is derived from
seed, but now you're using even /more/ storage space than you would by
just using OP_RETURN.

2) The user can backup after every transaction, which nobody wants to do.

3) The user could use some form of a cloud backup service and place
trust in them that their servers wont go down and lose their coins.

None of those options are really that appealing. OP_RETURN seems like
the best alternative to me, at least for that use case.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
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.


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, metadata, messages sent using the payment
protocol, ...) needs backups.

What HD wallets (or any type of deterministic derivation scheme) offer
is the fact that you can separate secret data and public data. You
only need one safe backup of the master secret key - all the rest can
at most result in privacy loss and not in lost coins.

-- 
Pieter

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Flavien Charlon
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 caution.

After 9 months, it seems OP_RETURN did not lead to a blockchain
catastrophe, so I think it might be time to discuss increasing the limit.

There are a number of proposals:

   1. Allow two OP_RETURN outputs per transaction (PR
   https://github.com/bitcoin/bitcoin/pull/5075)
   2. Increase the default maximum payload size from 40 bytes to 80 bytes (
   PR https://github.com/bitcoin/bitcoin/pull/5286)
   Note that the maximum can be configured already through the
   'datacarriersize' option - this is just changing the default.
   3. Make the maximum OP_RETURN payload size proportional to the number of
   outputs of the transaction
   4. A combination of the above

3 sounds the most interesting, and 2 would be the second best.

1 is also good to have as long as the space budget is shared between the
two outputs.

Can we discuss this and agree on a plan?

Thanks,
Flavien
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Luke Dashjr
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
 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 caution.
 
 After 9 months, it seems OP_RETURN did not lead to a blockchain
 catastrophe, so I think it might be time to discuss increasing the limit.

Mining policies such as this is always up to miners.
It's not a development topic.

 There are a number of proposals:
 
1. Allow two OP_RETURN outputs per transaction (PR
https://github.com/bitcoin/bitcoin/pull/5075)

This one seems uselessly inefficient. Protocols needing OP_RETURN could just 
as easily look for an independent push opcode in a single OP_RETURN output.

2. Increase the default maximum payload size from 40 bytes to 80 bytes (
PR https://github.com/bitcoin/bitcoin/pull/5286)
Note that the maximum can be configured already through the
'datacarriersize' option - this is just changing the default.

I don't care strongly, but IMO this kind of focus on defaults is part of the 
problem. I'd prefer to have the default be randomised to incentivise miners to 
make the decision they're supposed to be making, rather than pushing the 
responsibility onto developers to set defaults.

3. Make the maximum OP_RETURN payload size proportional to the number of
outputs of the transaction

Right now, this policy requires code hacks. Of the three ideas, this one looks 
the most ripe for code changes (particularly one that makes it possible to 
configure this policy, not hardcoding it).

Luke

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Jorge Timón
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 configure their own policy.
In my opinion the best we can do is to make it easier for miners to
implement their own policies by abstracting out those parts of the
code. Pull requests like #5071 and #5114 are steps in that direction.
So if you're interested in having more miners accepting 80 bytes
OP_RETURN transactions, I suggest you invest some time reviewing and
testing those PRs.
Although this wasn't its main purpose, separating script/standard was
also a little step in the same direction.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Jorge Timón
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 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.
I'm aware that so called proof of publication is not equivalent to
timestamping, but I wasn't aware at the moment (and I don't think it's
very interesting but that's obviously only my opinion, embedded
systems developers will disagree).

[1] Here's a video explaining pay-to-contract in the context of
invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q
Here's a generic working implementation:
https://github.com/Blockstream/contracthashtool


On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón jti...@jtimon.cc wrote:
 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 configure their own policy.
 In my opinion the best we can do is to make it easier for miners to
 implement their own policies by abstracting out those parts of the
 code. Pull requests like #5071 and #5114 are steps in that direction.
 So if you're interested in having more miners accepting 80 bytes
 OP_RETURN transactions, I suggest you invest some time reviewing and
 testing those PRs.
 Although this wasn't its main purpose, separating script/standard was
 also a little step in the same direction.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Alan Reiner

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 had been reduced to 40 bytes, because I had an application where I
wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
need at least 64 bytes for that.   Unfortunately I can't remember now
what that application was, so it's difficult for me to argue for it. 
But I don't think that's an unreasonable use case:  sending a payment
with a signature, essentially all timestamped in the blockchain.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development