Adán Sánchez de Pedro Crespo [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-09-11 to 2018-01-29
💬 Posted a total of 7 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-09 12:48:43

- reply

📅 Original date posted:2018-01-29
📝 Original message:
I can recommend the #mainnet channel on the LN Discord:
https://discord.gg/QD7xzz3
Also, feel free to tell me your node_id and IP address and I'll be more
than happy to open a channel to you and play "the invoice game" back and
forth ;)
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180129/67c011f5/attachment-0001.sig>

2023-06-07 18:07:51

- reply

📅 Original date posted:2017-11-21
📝 Original message:Yes.
1. SegWit transactions spend less "weight", which is limited for every
block. Base transaction data weights as much as 4x the witness data.
2. SegWit signatures can be cheaper to verify (linear instead of
quadratic). Prior to this, DoS attacks were possible by using forged
transactions including signatures which could take several minutes to
verify.
The immediate result of this is that miners can fit more transactions
into a block and at the same time spend less power building the blocks.
On 20.11.2017 19:04, Dan Bryant via bitcoin-dev wrote:
> Is there any incentive for miners to pick segwit transactions over
> non-segwit transaction. Do they require less, equal, or more compute to
> process?
>
> On Nov 20, 2017 11:46 AM, "Johnson Lau via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> We can’t “just compute the Transaction ID the same way the hash for
> signing the transaction is computed” because with different SIGHASH
> flags, there are 6 (actually 256) ways to hash a transaction.
>
> Also, changing the definition of TxID is a hardfork change, i.e.
> everyone are required to upgrade or a chain split will happen.
>
> It is possible to use “normalised TxID” (BIP140) to fix malleability
> issue. As a softfork, BIP140 doesn’t change the definition of TxID.
> Instead, the normalised txid (i.e. txid with scriptSig removed) is
> used when making signature. Comparing with segwit (BIP141), BIP140
> does not have the side-effect of block size increase, and doesn’t
> provide any incentive to control the size of UTXO set. Also, BIP140
> makes the UTXO set permanently bigger, as the database needs to
> store both txid and normalised txid
>
>> On 21 Nov 2017, at 1:24 AM, Praveen Baratam via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Bitcoin Noob here. Please forgive my ignorance.
>>
>> From what I understand, in SegWit, the transaction needs to be
>> serialized into a data structure that is different from the
>> current one where signatures are separated from the rest of the
>> transaction data.
>>
>> Why change the format at all? Why cant we just compute the
>> Transaction ID the same way the hash for signing the transaction
>> is computed?
>>
>> --
>> Dr. Praveen Baratam
>>
>> about.me <http://about.me/praveen.baratam>
>> _______________________________________________
>>
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid

2023-06-07 18:07:30

- reply

📅 Original date posted:2017-11-03
📝 Original message:If I did understand it right, you don't need to publish the Simplicity
code for the "jetable" expression.
That's the whole point of MAST. Each Simplicity expression can be
identified by its MAST root (the Merkle root of all branches in its
Abstract Syntax Tree).
Imagine you want to write a Simplicity script that is roughly equivalent
to P2PKH. Regardless of directly writing such script or using a higher
level smart contract language, you won't likely write for yourself the
part in which you compute the hash of the public key. Instead, you are
expected to include some external library providing hash functions or at
least copy and paste such function into your code.
As everyone is expected to use the same, let's say, RIPEMD160
implementation, it doesn't matter how you included such function in your
program. The point is that once you build the MAST for your program,
such function will be completely replaced by its MAST root---which is
nothing but a hash.
This way, when the Simplicity interpreter (the BitMachine) bumps into
the hash, it can look for it in a predefined jets dictionary and find
the binary for a precompiled, formally proven implementation of a
function that is perfectly equivalent to the original Simplicity code.
On 03.11.2017 13:59, Hampus Sjöberg via bitcoin-dev wrote:
> Thank you for your answer, Russel.
>
> When a code path takes advantage of a jet, does the Simplicity code
> still need to be publicly available/visible in the blockchain? I imagine
> that for big algorithms (say for example EDCA verification/SHA256
> hashing etc), it would take up a lot of space in the blockchain.
> Is there any way to mitigate this?
>
> I guess in a softfork for a jet, the Simplicity code for a jet could be
> defined as "consensus", instead of needed to be provided within every
> script output.
> When the Simplicity interpretor encounters an expression that has a jet,
> it would run the C/Assembly code instead of interpreting the Simplicity
> code. By formal verification we would be sure they match.
>
> Greetings
> Hampus
>
> 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>
> Hi Jose,
>
> Jets are briefly discussed in section 3.4 of
> https://blockstream.com/simplicity.pdf
> <https://blockstream.com/simplicity.pdf>
>
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of
> these expressions it can skip over the Simplicity interpreter and
> instead directly evaluate the function using specialized C or
> assembly code.
>
> For example, when the Simplicity interpreter encounters the
> Simplicity expression for ECDSA verification, it might directly call
> into libsecp rather than continuing the ECDSA verification using
> interpreted Simplicity.
>
> HTH.
>
>
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi,
>
> I am trying to follow this Simplicity proposal and I am seeing
> all over references to ‘jets’, but I haven’t been able to find
> any good reference to it.
> Can anyone give me a brief explanation and or a link pointing to
> this feature?
> Thanks
>
>> On 31 Oct 2017, at 22:01,
>> bitcoin-dev-request at lists.linuxfoundation.org
>> <mailto:bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>>
>> The plan is that discounted jets will be explicitly labeled as
>> jets in the
>> commitment. If you can provide a Merkle path from the root to
>> a node that
>> is an explicit jet, but that jet isn't among the finite number
>> of known
>> discounted jets,
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid

2023-06-07 18:07:29

- reply

📅 Original date posted:2017-11-03
📝 Original message:Oops. That makes much more sense than what I said. Thanks a lot for the
clarification.
On 03.11.2017 02:10, Russell O'Connor via bitcoin-dev wrote:
> Hi Jose,
>
> Jets are briefly discussed in section 3.4 of
> https://blockstream.com/simplicity.pdf
>
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of these
> expressions it can skip over the Simplicity interpreter and instead
> directly evaluate the function using specialized C or assembly code.
>
> For example, when the Simplicity interpreter encounters the Simplicity
> expression for ECDSA verification, it might directly call into libsecp
> rather than continuing the ECDSA verification using interpreted Simplicity.
>
> HTH.
>
>
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi,
>
> I am trying to follow this Simplicity proposal and I am seeing all
> over references to ‘jets’, but I haven’t been able to find any good
> reference to it.
> Can anyone give me a brief explanation and or a link pointing to
> this feature?
> Thanks
>
>> On 31 Oct 2017, at 22:01,
>> bitcoin-dev-request at lists.linuxfoundation.org
>> <mailto:bitcoin-dev-request at lists.linuxfoundation.org> wrote:
>>
>> The plan is that discounted jets will be explicitly labeled as
>> jets in the
>> commitment. If you can provide a Merkle path from the root to a
>> node that
>> is an explicit jet, but that jet isn't among the finite number of
>> known
>> discounted jets,
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid

2023-06-07 18:07:28

- reply

📅 Original date posted:2017-11-02
📝 Original message:Hi everyone,
I agree that the paper could use some more details on the rationale
behind "jets". After a couple of reads, I think I can "ELI5 them":
As far as I understand, jets are a smart optimization that makes complex
Simplicity contracts way cheaper to compute (ideally, comparable to
Script or EVM).
For this purpose, jets leverage the most important element of the
Simplicity Bit Machine: the frames stack.
In a Simplicity program, every expression or sub-expression can be
thought of as a pure function that when applied on a certain initial
read frame, results in the active write frame having a different value.
This happens deterministically and without any side effects.
So, if the Simplicity interpreter finds some expression whose result
when applied upon a certain read frame is already known (because it has
already been executed or it was somehow precomputed), it doesn't need to
execute such expression step-by-step once again. Instead, it just need
to write the known result to the active write frame.
The paper suggests that at all times the interpreter knows the result of
applying many common operations on all possible combinations of inputs
in the range of 8 to 256 bits. In other words, the interpreter won't
need to calculate "123 + 321" or compare "456 > 654 because the results
of those expressions will be already known to it. These are stupid
examples, but the savings are real for hash functions internals,
elliptic curve calculations or even validation of signatures.
As said before, this can help making Simplicity programs lighter on CPU
usage, but it has many other benefits too:
+ Jets can replicate the behavior of complex chunks of Simplicity code
with the guarantee that they can't introduce side effects.
+ Interpreter-bundled jets are formally proven. The more a Simplicity
program relies on jets, the more it benefits from their safety. When
proving the soundness of your program, you can just ignore the jets,
assume they are valid and focus on your own logic.
The paper also suggests that different sets of jets could make up
different single purpose dialects, just like domain-specific languages
bring richer vocabulary and semantics to the bare syntax and grammar of
general-purpose languages.
I hope Russel or Mark can correct me if I got something totally wrong. I
must admit I really like this proposal and hereby declare myself a huge
fan of their work :)
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid

2023-06-07 18:07:11

- reply

📅 Original date posted:2017-10-19
📝 Original message:Blockchains with fast confirmation times are currently believed to
suffer from reduced security due to a high stale rate.
As blocks take a certain time to propagate through the network, if miner
A mines a block and then miner B happens to mine another block before
miner A's block propagates to B, miner B's block will end up wasted and
will not "contribute to network security".
Furthermore, there is a centralization issue: if miner A is a mining
pool with 30% hashpower and B has 10% hashpower, A will have a risk of
producing a stale block 70% of the time (since the other 30% of the time
A produced the last block and so will get mining data immediately)
whereas B will have a risk of producing a stale block 90% of the time.
Thus, if the block interval is short enough for the stale rate
to be high, A will be substantially more efficient simply by virtue of
its size. With these two effects combined, blockchains which produce
blocks quickly are very likely to lead to one mining pool having a large
enough percentage of the network hashpower to have de facto control over
the mining process.
Another possible implication of reducing the average block time is that
block size should be reduced accordingly. In an hypothetical 5 minutes
block size Bitcoin blockchain, there would be twice the block space
available for miners to include transactions, which could lead to 2
immediate consequences: (1) the blockchain could grow up to twice the
rate, which is known to be bad for decentralization; and (2) transaction
fees might go down, making it cheaper for spammers to bloat our beloved
UTXO sets.
There have been numerous proposals that tried to overcome the downsides
of faster blocks, the most noteworthy probably being the "Greedy
Heaviest Observed Subtree" (GHOST) protocol:
http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_full.pdf
Personally, I can't see why Bitcoin would need or how could it even
benefit at all from faster blocks. Nevertheless, I would really love if
someone in the list who has already run the numbers could bring some
valid points on why 10 minutes is the optimal rate (other than "if it
ain't broke, don't fix it").
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid

2023-06-07 18:05:37

- reply

📅 Original date posted:2017-09-11
📝 Original message:Coincidentally, the kind of Merkle tree that Mark describes in his
proposal is exactly the one that we use at Stampery.
The Stampery BTA whitepaper[1] includes pseudocode for many of the
algorithms outlined by this proposal, including fast-SHA256, the tree
building process and the inclusion proving routine.
The wording is slightly different but the logic is just the same, so I
hope it helps future implementations in case of eventual adoption.
[1]
https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v6-whitepaper.pdf
Best,
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
T: +34 663 163 375
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/bcc880d1/attachment-0001.sig>