Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan via bitcoin-dev]

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 
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
> > . 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
> >  that
> > *protocols wishing to claim OP_RETURN prefixes should use the standard
> > Bitcoin Improvement Proposals process*.
> >
> > That entry seems to have changed recently
> > , 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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Capping the size of locators [trivial protocol change BIP]

[Gregory Maxwell via bitcoin-dev]

Coinr8d posted on bct that the node software would process large
locators limited only by the maximum message size yet sensible usage
of locators only results in messages of log2(n_blocks) size. He was
concerned that it might be a DOS vulnerability but quick measurements
indicated to me that it likely wasn't worse than many other protocol
messages.  It still seems silly to allow absurd locators. So I propose
that the size of locators be limited.

However, capping them is a P2P change that could potentially result in
network splits if older nodes would potentially produce larger
locators (esp if triggered to produce unexpectedly large ones by
forks).  A quick survey of node software indicated that no software I
could find would ever produce a locator with more than 42 hashes
before encountering other limits, so I think a limit of 64 will be
automatically compatible with all or virtually all nodes on the
network.

I'm bothering writing a BIP because there might be some naive
implementation lurking out there that sends a crazy number due to
sub-exponential backoff that would be broken by nodes enforcing a
limit... particularly since the correct use of locators was never
previously mandated and might not be obvious to all developers.

I take the opportunity to also specify that the locators be correctly
ordered in terms of total work, but  don't specify that they all come
from the same chain.

Cheers,

==Introduction==

===Abstract===

This document proposes limiting the locator messages used in the getblocks
and getheaders to 64 entries and requiring that be ordered by total
work.

===Copyright===

This document is licensed under the 2-clause BSD license.

==Motivation==

The Bitcoin P2P protocol uses a simple and efficient data structure
to reconcile blockchains between nodes called a locator.  A locator
communicates a list of known hashes which allows a peer to find a
recent common ancestor between the best chains on two nodes.  By
exponentially increasing the space between each entry, the locator
allows a log() sized message to find the difference between two nodes
with only a constant factor overhead.

Because short forks are much more common than long forks the typical
usage of the locator includes a small number of topmost hashes before
switching to exponential spacing.

The original Bitcoin implementation provided no explicit limit to the
number of hashes in a locator message, allowing for absurd and
wasteful uses like including
all hashes in a chain.

Although locators are very inexpensive for existing node software to
process there is no known utility for sending very large locators.
To reduce the worst case cost of processing a locator message it would
be useful if the size of locator messages were strictly
bounded to sensible levels.

Common implementations have implicit limitations of 2^32 blocks and an
exponent of 2 after the first 10 locators and so could never request
more than 42 hashes in any case.

== Specification ==

A locator included in a getblock or getheaders message may include no more
than 64 hashes, including the final hash_stop hash. Additionally, the blocks
referenced by the locator must be in order of equal or decreasing total
work.

Sending a locator that violates these requirements may result in normal
processing, the message being ignored, a disconnection, or a ban.

Implementations that seek to handle larger numbers of blocks than afforded
by this limit with an exponent of 2 can adaptively switch to a larger
exponent as required to stay within the limit.

== Acknowledgements ==

Thanks to Coinr8d on bitcointalk for pointing out that node software would
process and respond to locators with about 125,000 hashes in them.
___
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

[Luke Dashjr via bitcoin-dev]

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
> . At Po.et we use
> colored coins
> 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
>  that
> *protocols wishing to claim OP_RETURN prefixes should use the standard
> Bitcoin Improvement Proposals process*.
>
> That entry seems to have changed recently
> , 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

___
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

[CryptAxe via bitcoin-dev]

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 
> 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
>> >. 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
>> > that
>> >*protocols
>> >wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>> >Improvement Proposals process*.
>> >
>> >That entry seems to have changed recently
>> >, 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
>
___
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

[Lautaro Dragan via bitcoin-dev]

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 
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
> >. 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
> > that
> >*protocols
> >wishing to claim OP_RETURN prefixes should use the standard Bitcoin
> >Improvement Proposals process*.
> >
> >That entry seems to have changed recently
> >, 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

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

[Peter Todd via bitcoin-dev]

On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev 
 wrote:
>Hi everyone,
>
>My name's Lautaro and I'm currently acting as Tech Lead of Po.et
>. At Po.et we
>use
>colored coins
>
>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
> that
>*protocols
>wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>Improvement Proposals process*.
>
>That entry seems to have changed recently
>, 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

[bitcoin-dev] Claiming an OP_RETURN Prefix

[Lautaro Dragan via bitcoin-dev]

Hi everyone,

My name's Lautaro and I'm currently acting as Tech Lead of Po.et
. At Po.et we use
colored coins

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
 that *protocols
wishing to claim OP_RETURN prefixes should use the standard Bitcoin
Improvement Proposals process*.

That entry seems to have changed recently
, 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Schnorr signatures BIP

[Russell O'Connor via bitcoin-dev]

Over chat it has been pointed out to me that computing the non-quadratic
residue is not the same cost as computing a quadratic residue.  As pointed
out in footnote 7 of the the proposed BIP, c^((p+1)/4) is always a
quadratic residue and must be negated to find the non-quadratic residue.

In light of this, I revise my proposed change to make the verification
equation

R + sG + eP = 0.

(by 0 in the equation above I mean the identity element for the (+)
operation, which is the point at infinity.)

This equation is suitable for batch verification.  This equation is clearly
written as a linear combination that doesn't use negation.  In most
implementations, equality comparison tests are implemented by subtraction
and a comparison with zero. By writing the verification equation this way,
we clearly see that only the comparison with zero test is needed.

For single signature verification the check becomes, compute Q := sG + eP.
Verify that Q isn't the point at infinity and Q.x = r.  Verify that Q.y is
*not* a quadratic residue. (While I was incorrect earlier about the costs
of computing a non-residue, it is the case the *verifying* a value is a
quadratic residue is the same cost as verifying a value is a non-residue.)

Effectively in my first email I was suggesting that the 'e' value in a
signature be negated from the current BIP proposal.  In this revision I am
effectively suggesting that the 's' value in a signature should be the one
that is negated instead.

On Sat, Aug 4, 2018 at 8:22 AM, Russell O'Connor 
wrote:

> I propose changing the verification equation from "Let *R = sG - eP*" to
>
> Let *R = sG + eP*
>
> This allows faster verification by avoiding negating a point (or a
> coefficient).
>
>
> If, instead of directly following the literal verification specification,
> one is instead reconstructing R from r by finding a y coordinate that is a
> quadratic residue, under the existing scheme one would verify
>
>
> *sG - eP = R*
>
> which is effectively verifying
>
>   0 = *sG - eP* - R  or 0 = R - *sG + eP*
>
> Either way one needs to negate at least one point (or one coefficient)
> because of the opposite signs between sG and eP.
>
>
> Under my proposed revised verification scheme, one would instead verify
>
>   0 = sG + eP + (-R).
>
> While it seems that this requires negating R, it does not.  Rather (-R)
> can be directly constructed from r by finding a y coordinate that is *not*
> a quadratic residue, which is precisely the same amount of work that
> construction R from r was.
>
> In either verification procedure, changing the verification equation to my
> proposal removes one negation operation from the cost of doing verification.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev