Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>Should we actually be using the BIP process to claim a prefix?

I recommend against using an op_return prefix, as they allow for
transaction censorship.

In fact, in our case, where we use an IPFS hash in an op_return, we remove
the IPFS multihash prefix information to post a “bare” SHA256 hash to look
like many other hashes being posted in op_returns, to minimize any ability
for a miner to identify our transaction. The more projects that do this the
better — a form of herd immunity.

Longer term I’m looking for more responsible ways to publish this hash, for
instance have the hash be in the witness script data, so that it can be
easily purged from nodes that do not wish to preserve it and prevent block
size bloat. However, to do so everyone has to do it the same way, ideally
have it look like any other transaction. I’ve not quite seen a solid
proposal for best practices here.

— Christopher Allen

[-- Attachment #2: Type: text/html, Size: 1198 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Jorge Timón]

op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract  instead.

On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>Should we actually be using the BIP process to claim a prefix?
>
> I recommend against using an op_return prefix, as they allow for transaction
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we remove
> the IPFS multihash prefix information to post a “bare” SHA256 hash to look
> like many other hashes being posted in op_returns, to minimize any ability
> for a miner to identify our transaction. The more projects that do this the
> better — a form of herd immunity.
>
> Longer term I’m looking for more responsible ways to publish this hash, for
> instance have the hash be in the witness script data, so that it can be
> easily purged from nodes that do not wish to preserve it and prevent block
> size bloat. However, to do so everyone has to do it the same way, ideally
> have it look like any other transaction. I’ve not quite seen a solid
> proposal for best practices here.
>
> — Christopher Allen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Jude Nelson]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

> I recommend against using an op_return prefix,
> as they allow for transaction censorship.

> In fact, in our case, where we use an IPFS hash in
> an op_return, we remove the IPFS multihash prefix
> information to post a “bare” SHA256 hash to look like
> many other hashes being posted in op_returns, to
> minimize any ability for a miner to identify our transaction.
> The more projects that do this the better — a form of herd
> immunity.

Can a miner identify which transactions came from your software simply by
running a copy themselves?  If so, then they can censor your transactions
no matter how you encode them.

On Wed, Aug 15, 2018 at 8:34 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> op_return outputs can be pruned because they are not spendable.
> putting a hash on in the witness script data won't make things better
> (it would actually make them worse) and it definitely doesn't help
> "block size bloat".
> I think I'm missing some context, but if you're using op_return purely
> for timestamping I would recommend using pay 2 contract  instead.
>
> On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>Should we actually be using the BIP process to claim a prefix?
> >
> > I recommend against using an op_return prefix, as they allow for
> transaction
> > censorship.
> >
> > In fact, in our case, where we use an IPFS hash in an op_return, we
> remove
> > the IPFS multihash prefix information to post a “bare” SHA256 hash to
> look
> > like many other hashes being posted in op_returns, to minimize any
> ability
> > for a miner to identify our transaction. The more projects that do this
> the
> > better — a form of herd immunity.
> >
> > Longer term I’m looking for more responsible ways to publish this hash,
> for
> > instance have the hash be in the witness script data, so that it can be
> > easily purged from nodes that do not wish to preserve it and prevent
> block
> > size bloat. However, to do so everyone has to do it the same way, ideally
> > have it look like any other transaction. I’ve not quite seen a solid
> > proposal for best practices here.
> >
> > — Christopher Allen
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3908 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Christopher Allen]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Can a miner identify which transactions came from your software simply by
> running a copy themselves?  If so, then they can censor your transactions
> no matter how you encode them.
>

Possibly, but in the IPFS case I suspect the latency required to inspect
all hashes would likely  impact the ability of the miner to succeed in the
block. (True? I don’t touch mining software.)

Thus as long as all hashes look the same, and there are multiple content
addressable schemes that use hashes that have to be searched in order to
know to censor, you have to censor all or none.

— Christopher Allen

>

[-- Attachment #2: Type: text/html, Size: 1273 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr]

On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev wrote:
> On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Can a miner identify which transactions came from your software simply by
> > running a copy themselves?  If so, then they can censor your transactions
> > no matter how you encode them.
>
> Possibly, but in the IPFS case I suspect the latency required to inspect
> all hashes would likely  impact the ability of the miner to succeed in the
> block. (True? I don’t touch mining software.)

Not true at all.

> Thus as long as all hashes look the same, and there are multiple content
> addressable schemes that use hashes that have to be searched in order to
> know to censor, you have to censor all or none.

Choosing not to mine transactions is not censorship.

Luke

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

Thanks Christopher.

> op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".

Agreed

> I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract  instead.

And

> If you're *actually* just doing timestamping you're better off using
OpenTimestamps. But many times people think they're just doing timestamping
in reality mere timestamps are insufficient for the task.

No, it's not only timestamping. Think of it as storing the URL of something
in the OP_RETURN, only that instead of a URL it's a hash. But it's not just
the hash of the work — IPFS adds a few other elements that affect this
hash, so calculating it out of the file being added won't do. Also, the
batching OTS uses and the batching we use (using IPFS directories) are
incompatible.

> Can a miner identify which transactions came from your software simply by
running a copy themselves?  If so, then they can censor your transactions
no matter how you encode them.

Miners would have to try and `ipfs cat` every OP_RETURN of every
transaction (maybe filtering by byte length), which is a relatively high
cost operation. But such a script is straight forward to write and can be
hosted in a cheap AWS machine. We're talking about less than a week of
coding and less than a hundred bucks of hosting, so if they're out to get
you it won't make a difference.

> Choosing not to mine transactions is not censorship.

Is it not, if for political rather than economical reasons? These
transactions pay fees like any other.



El mié., 15 de ago. de 2018 a la(s) 22:08, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> escribió:

> On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev
> wrote:
> > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > Can a miner identify which transactions came from your software simply
> by
> > > running a copy themselves?  If so, then they can censor your
> transactions
> > > no matter how you encode them.
> >
> > Possibly, but in the IPFS case I suspect the latency required to inspect
> > all hashes would likely  impact the ability of the miner to succeed in
> the
> > block. (True? I don’t touch mining software.)
>
> Not true at all.
>
> > Thus as long as all hashes look the same, and there are multiple content
> > addressable schemes that use hashes that have to be searched in order to
> > know to censor, you have to censor all or none.
>
> Choosing not to mine transactions is not censorship.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5510 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr]

On Thursday 16 August 2018 02:22:21 Lautaro Dragan wrote:
> > Choosing not to mine transactions is not censorship.
>
> Is it not, if for political rather than economical reasons? These
> transactions pay fees like any other.

Miners have always chosen transaction on "political" basises, and doing such 
is their right. That's why the system is supposed to be comprised of many 
miners, all with their own policies - so the choices of one do not impact the 
overall ability to spend (presumably only spam should be rejected by all 
miners).

For fees to themselves justify the cost of a transaction, they would need to 
be magnitudes higher than we've ever seen on Bitcoin. But even then, nobody 
has an obligation to accept payment, no matter how reasonable it is, for a 
service they don't want to provide.

Luke

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Ryan Grant]

On Wed, Aug 15, 2018 at 8:40 PM, Jude Nelson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Can a miner identify which transactions came from your software simply by
> running a copy themselves?  If so, then they can censor your transactions no
> matter how you encode them.

The hash of the file is deterministic and `ipfs add` tells us what it
is whether the network is connected or disconnected.  We don't upload
files to IPFS until the transaction has settled with several
confirmations.

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Peter Todd]

On August 15, 2018 8:33:43 PM UTC, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>op_return outputs can be pruned because they are not spendable.
>putting a hash on in the witness script data won't make things better
>(it would actually make them worse) and it definitely doesn't help
>"block size bloat".
>I think I'm missing some context, but if you're using op_return purely
>for timestamping I would recommend using pay 2 contract  instead.

If you're *actually* just doing timestamping you're better off using OpenTimestamps. But many times people think they're just doing timestamping in reality mere timestamps are insufficient for the task.

Notably, this is something the Satoshi Bitcoin white paper gets wrong, incorrectly describing Bitcoin as a timestamping system: timestamping is insufficient to prevent double-spends.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Hi everyone,

My name's Lautaro and I'm currently acting as Tech Lead of Po.et
<https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we use
colored coins
<https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110>
to
store data on the Bitcoin blockchain with prefix "POET".

I've read in an old version of the OP_RETURN entry of the bitcoin wiki
<https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that *protocols
wishing to claim OP_RETURN prefixes should use the standard Bitcoin
Improvement Proposals process*.

That entry seems to have changed recently
<https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
stating that we should follow the BIP process, and I haven't been able to
find any existing BIP claiming an OP_RETURN prexif, but for the sake of
thoroughness I'd like to ask for your help or confirmation here.

Should we actually be using the BIP process to claim a prefix?

Thanks in advance,

Lautaro

[-- Attachment #2: Type: text/html, Size: 1281 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Peter Todd]

On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Hi everyone,
>
>My name's Lautaro and I'm currently acting as Tech Lead of Po.et
><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
>use
>colored coins
><https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110>
>to
>store data on the Bitcoin blockchain with prefix "POET".
>
>I've read in an old version of the OP_RETURN entry of the bitcoin wiki
><https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
>*protocols
>wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>Improvement Proposals process*.
>
>That entry seems to have changed recently
><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
>stating that we should follow the BIP process, and I haven't been able
>to
>find any existing BIP claiming an OP_RETURN prexif, but for the sake of
>thoroughness I'd like to ask for your help or confirmation here.
>
>Should we actually be using the BIP process to claim a prefix?

It's better if you don't use a prefix at all from a censorship resistance and anonymity perspective; you're application should not require a prefix for technical reasons.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

Thanks Peter for your prompt reply.

And now that I think of it you're right - as easy as it is for us to
differentiate OP_RETURN outputs that contain the Po.et prefix it would be
for miners to block those transactions altogether. Is this what you mean?

Still, a prefix is something we may have to live with for a little while
until we can address that issue.

Is there a formal / standard process to claim it we should follow?




El dom., 5 de ago. de 2018 a la(s) 20:58, Peter Todd <pete@petertodd.org>
escribió:

>
>
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Hi everyone,
> >
> >My name's Lautaro and I'm currently acting as Tech Lead of Po.et
> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
> >use
> >colored coins
> ><
> https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110
> >
> >to
> >store data on the Bitcoin blockchain with prefix "POET".
> >
> >I've read in an old version of the OP_RETURN entry of the bitcoin wiki
> ><https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
> >*protocols
> >wishing to claim OP_RETURN prefixes should use the standard Bitcoin
> >Improvement Proposals process*.
> >
> >That entry seems to have changed recently
> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
> >stating that we should follow the BIP process, and I haven't been able
> >to
> >find any existing BIP claiming an OP_RETURN prexif, but for the sake of
> >thoroughness I'd like to ask for your help or confirmation here.
> >
> >Should we actually be using the BIP process to claim a prefix?
>
> It's better if you don't use a prefix at all from a censorship resistance
> and anonymity perspective; you're application should not require a prefix
> for technical reasons.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 3275 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

Don't worry about claiming it. There are no reserved prefixes enforced by
the software. For example anyone could create an output that uses the
witness coinbase commitment prefix bytes. It would just be ignored (unless
it was in the coinbase, in which case it would also need to be valid).

On Sun, Aug 5, 2018, 6:47 PM Lautaro Dragan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks Peter for your prompt reply.
>
> And now that I think of it you're right - as easy as it is for us to
> differentiate OP_RETURN outputs that contain the Po.et prefix it would be
> for miners to block those transactions altogether. Is this what you mean?
>
> Still, a prefix is something we may have to live with for a little while
> until we can address that issue.
>
> Is there a formal / standard process to claim it we should follow?
>
>
>
>
> El dom., 5 de ago. de 2018 a la(s) 20:58, Peter Todd <pete@petertodd.org>
> escribió:
>
>>
>>
>> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >Hi everyone,
>> >
>> >My name's Lautaro and I'm currently acting as Tech Lead of Po.et
>> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
>> >use
>> >colored coins
>> ><
>> https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110
>> >
>> >to
>> >store data on the Bitcoin blockchain with prefix "POET".
>> >
>> >I've read in an old version of the OP_RETURN entry of the bitcoin wiki
>> ><https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
>> >*protocols
>> >wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>> >Improvement Proposals process*.
>> >
>> >That entry seems to have changed recently
>> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
>> >stating that we should follow the BIP process, and I haven't been able
>> >to
>> >find any existing BIP claiming an OP_RETURN prexif, but for the sake of
>> >thoroughness I'd like to ask for your help or confirmation here.
>> >
>> >Should we actually be using the BIP process to claim a prefix?
>>
>> It's better if you don't use a prefix at all from a censorship resistance
>> and anonymity perspective; you're application should not require a prefix
>> for technical reasons.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4463 bytes --]

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Luke Dashjr]

Are you doing coloured coins or storing data?

If the former, you should probably collaborate with the authors of BIP 160 
(yet to be added to the main repo), and/or write a new BIP if BIP 160 is 
insufficient for some reason.

If the latter, you just shouldn't do it at all.

Note that BIPs need to specify an actual protocol, not just claim a prefix.


On Sunday 05 August 2018 21:11:26 Lautaro Dragan via bitcoin-dev wrote:
> Hi everyone,
>
> My name's Lautaro and I'm currently acting as Tech Lead of Po.et
> <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we use
> colored coins
> <https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e
>84c/src/BlockchainWriter/ClaimController.ts#L101-L110> to
> store data on the Bitcoin blockchain with prefix "POET".
>
> I've read in an old version of the OP_RETURN entry of the bitcoin wiki
> <https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
> *protocols wishing to claim OP_RETURN prefixes should use the standard
> Bitcoin Improvement Proposals process*.
>
> That entry seems to have changed recently
> <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
> stating that we should follow the BIP process, and I haven't been able to
> find any existing BIP claiming an OP_RETURN prexif, but for the sake of
> thoroughness I'd like to ask for your help or confirmation here.
>
> Should we actually be using the BIP process to claim a prefix?
>
> Thanks in advance,
>
> Lautaro

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Sorry for the confusion. We're doing coloured coins — storing the "POET"
prefix followed by an IPFS hash in the output and storing the full data in
IPFS.

Would you point me to the current work on BIP 160 or the authors?

El dom., 5 de ago. de 2018 a la(s) 23:05, Luke Dashjr <luke@dashjr.org>
escribió:

> Are you doing coloured coins or storing data?
>
> If the former, you should probably collaborate with the authors of BIP 160
> (yet to be added to the main repo), and/or write a new BIP if BIP 160 is
> insufficient for some reason.
>
> If the latter, you just shouldn't do it at all.
>
> Note that BIPs need to specify an actual protocol, not just claim a prefix.
>
>
> On Sunday 05 August 2018 21:11:26 Lautaro Dragan via bitcoin-dev wrote:
> > Hi everyone,
> >
> > My name's Lautaro and I'm currently acting as Tech Lead of Po.et
> > <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
> use
> > colored coins
> > <
> https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e
> >84c/src/BlockchainWriter/ClaimController.ts#L101-L110> to
> > store data on the Bitcoin blockchain with prefix "POET".
> >
> > I've read in an old version of the OP_RETURN entry of the bitcoin wiki
> > <https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
> > *protocols wishing to claim OP_RETURN prefixes should use the standard
> > Bitcoin Improvement Proposals process*.
> >
> > That entry seems to have changed recently
> > <https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
> > stating that we should follow the BIP process, and I haven't been able to
> > find any existing BIP claiming an OP_RETURN prexif, but for the sake of
> > thoroughness I'd like to ask for your help or confirmation here.
> >
> > Should we actually be using the BIP process to claim a prefix?
> >
> > Thanks in advance,
> >
> > Lautaro
>
>

[-- Attachment #2: Type: text/html, Size: 2880 bytes --]