Lautaro Dragan [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-08-05 to 2019-03-09
💬 Posted a total of 5 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:16:57

- reply

📅 Original date posted:2019-03-09
📝 Original message:Hi Karl-Johan, my two cents:
At Po.et we use regtest to simulate reorgs in integration tests in Travis /
CircleCI. It has proved quite useful.
In general regtest for automated testing has given us all we needed so far,
but I admit we have a rather simple use of Bitcoin right now (colored
coins).
For local development, we sometimes use a script that "mines" blocks in
regtest periodically. It was my goal to also use this method in QA,
although we wound up using testnet and didn't encounter any problems so far.
Out of curiosity: what limitations did you find in using, for example, a
private network of bitcoin core nodes running regtest? (this gives you the
same power as centralization without any changes or extra functionality
required)
El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> escribió:
> Hello,
>
> As some of you already know, I've been working on a network called
> "signet", which is bascially a complement to the already existing testnet,
> except it is completely centralized, and blocks are signed by a specific
> key rather than using proof of work.
>
> Benefits of this:
>
> 1. It is more predictable than testnet. Miners appear and disappear
> regularly, causing irregular block generation.
>
> 2. Since it is centrally controlled, it is easy to perform global testing,
> such as reorgs (e.g. the network performs a 4 block reorg by request, or as
> scheduled).
>
> 3. It is more stable than testnet, which occasionally sees several
> thousand block reorgs.
>
> 4. It is trivial to spin up (and shut down) new signets to make public
> tests where anyone can participate.
>
> Anyone can create a signet at any time, simply by creating a key pair and
> creating a challenge (scriptPubKey). The network can then be used globally
> by anyone, assuming the creator sends some coins to the other participants.
>
> Having a persistent signet would be beneficial in particular to services
> which need a stable place to test features over an extended period of time.
> My own company implements protocols on top of Bitcoin with sidechains. We
> need multi-node test frameworks to behave in a predictable manner (unlike
> testnet) and with the same standardness relay policy as mainnet.
>
> Signets consist of 2 parameters: the challenge script (scriptPubKey) and
> the solution length. (The latter is needed to retain fixed length block
> headers, despite having an additional payload.)
>
> I propose that a default persistent "signet1" is created, which can be
> replaced in future versions e.g. if the coins are unwisely used as real
> money, similarly to what happened to previous testnets. This signet is
> picked by default if a user includes -signet without providing any of the
> parameters mentioned above. The key holder would be someone sufficiently
> trusted in the community, who would be willing to run the system (block
> generation code, faucet, etc). It could be made a little more sturdy by
> using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers
> disappear. If people oppose this, it can be skipped, but will mean people
> can't just jump onto signet without first tracking down parameters from
> somewhere.
>
> Implementation-wise, the code adds an std::map with block hash to block
> signature. This is serialized/deserialized as appropriate (Segwit witness
> style), which means block headers in p2p messages are (80 +
> solution_length) bytes. Block header non-contextual check goes from
> checking if block header hash < target to checking if the payload is a
> valid signature for the block header hash instead.
>
> Single commit with code (will split into commits and make PR later, but
> just to give an idea what it looks like):
> https://github.com/kallewoof/bitcoin/pull/4
>
> I don't think this PR is overly intrusive, and I'm hoping to be able to
> get signet code into Bitcoin Core eventually, and am equally hopeful that
> devs of other (wallet etc) implementations will consider supporting it.
>
> Feedback requested on this.
>
> Attribution: parts of the signet code (in particular signblock and
> getnewblockhex) were adapted from the ElementsProject/elements repository.
> When PR is split into atomic commits, I will put appropriate attribution
> there.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190309/c16196eb/attachment.html>

2023-06-07 20:14:01

- reply

📅 Original date posted:2018-08-15
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180815/ae997542/attachment-0001.html>

2023-06-07 20:13:59

- reply

📅 Original date posted:2018-08-05
📝 Original message: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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180805/ed0fdefe/attachment-0001.html>

2023-06-07 20:13:58

- reply

📅 Original date posted:2018-08-05
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180805/c445b874/attachment.html>

2023-06-07 20:13:58

- reply

📅 Original date posted:2018-08-05
📝 Original message: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 at petertodd.org>
escribió:
>
>
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <
> bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180805/e3265ebe/attachment-0001.html>