--- Log opened Sun Sep 18 00:00:23 2022
05:15 -!- tibo [~tibo@2a01:e0a:21b:a730:b43a:3763:6b58:56ba] has joined #bitcoin-rust
05:19 -!- tibo [~tibo@2a01:e0a:21b:a730:b43a:3763:6b58:56ba] has quit [Ping timeout: 244 seconds]
08:32 -!- chris_ [~chris@67-148-157-218.dia.static.qwest.net] has joined #bitcoin-rust
09:51 < chris_> Hi, I have a few questions about the rust-bitcoin library. I'm trying to figure out if it's the right thing to use for my project.
09:51 < chris_> I want to create an SGX enclave that takes bitcoin block data, verifies that a particular block has e.g. 6 confirmations, and then
09:51 < chris_> parses that block and possibly acts on the data.
09:52 < chris_> I've written several security-critical SGX enclaves before, and it's my practice to write them in Rust, because it's generally very
09:52 < chris_> bad for SGX enclaves if there's a memory-safety issue.
09:52 < chris_> For this reason, the rust-bitcoin library looks very attractive. It looks that it even has a `validate_pow` function defined on
09:52 < chris_> the `BlockHeader` object.
09:53 < chris_> I also saw this note: https://github.com/rust-bitcoin/rust-bitcoin#consensus
09:54 < BlueMatt[m]> if you want to fully validate bitcoin blocks, you really have no other choice but bitcoin core (or parts of its code)
09:54 < BlueMatt[m]> if you are okay with the "spv" trust model, rust-bitcoin will likely work great for this.
09:55 < chris_> not familiar with that term, what's spv trust model?
09:56 < chris_> I'm assuming it means like, since the whole thing is predicated on proof of work, if you see enough proof of work confirmations then you should assume it's part of the real chain, and that the real nodes checked that the Txs are well-formed
09:57 < chris_> that was the idea I had anyways, I'm not interested in actually running the bitcoin scripting language inside an enclave
09:57 < chris_> But you think it's reasonable to use the `validate_pow` function in `rust-bitcoin` in a security-critical way?
09:58 < BlueMatt[m]> yea, basically. I mean that's not really the "bitcoin trust model", per se - bitcoin generally relies on every node validating all the data is correct, with pow only ordering transactions.
09:59 < chris_> i see, SPV = simplified payment verification from the whitepaper? I think that's right, that's what I want to use
09:59 < BlueMatt[m]> yea
09:59 < BlueMatt[m]> but, yea, depending on how much is "at stake" here that's totally fine - if its to protect a few million dollars, you probably want to run a full node as a part of the system
10:00 < BlueMatt[m]> another common design would be to run a full bitcoin core "border node" and then have an "internal node" that's handling money (eg written in rust-bitcoin) that does spv on top of that.
10:00 < BlueMatt[m]> (and only connects to said border node)
10:00 < chris_> I think we would likely do that. But I want to make sure I define an enclave boundary that makes sense and can provide an intelligible guarantee
10:01 < BlueMatt[m]> yea, spv is still a pretty nice security improvement over nothing, without question
10:01 < chris_> Another thing I ran into was, I can't seem to find a version of the `CalculateNextWorkRequired` function from `pow.cpp` in bitcoin-core anywhere in this library.
10:02 < chris_> It seems to me that there's little point in calling `validate_pow` in an SGX enclave if the
10:02 < chris_> enclave can't determine for itself what the correct target value is?
10:02 < BlueMatt[m]> border node to validate the chain, spv in an enclave which validates that blocks actually exist and are "plausible" in terms of PoW
10:02 < chris_> So maybe no one else is trying to use this library this way, and I should not either?
10:04 < BlueMatt[m]> its something that could be added, but an easy shortcut is also that there's a consensus rule that it cant go up or down by more than 4x.
10:04 < BlueMatt[m]> which you can cheat and just enforce that
10:04 < chris_> i see
10:04 < BlueMatt[m]> but, yea, presumably a calculatenextwork function should be added
10:04 < chris_> if I go this route I would be happy to send a patch with tests
10:05 < chris_> as you like
10:06 < BlueMatt[m]> fwiw we do something similar in rust-lightning's block syncing - https://docs.rs/lightning-block-sync/latest/src/lightning_block_sync/poll.rs.html#116-137
10:06 < BlueMatt[m]> https://github.com/rust-bitcoin/rust-bitcoin/issues/1289
10:06 < chris_> cool thank you! that's very helpful
10:09 < chris_> I will keep playing with the library, thanks for answering my questions
11:32 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
11:33 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-rust
15:09 -!- afilini [~afilini@2001:bc8:1828:245::2] has quit [Ping timeout: 248 seconds]
15:09 -!- afilini [~afilini@2001:bc8:1828:245::2] has joined #bitcoin-rust
23:40 < RiccardoCasatta[> FYI https://github.com/RCasatta/bitcoin_slices
23:41 < RiccardoCasatta[> happy to move it in rust-bitcoin if there is interest
23:44 < RiccardoCasatta[> I saw from the logs that one long message of mine was truncated and found around that it could be because it contained `\n` this is long message on purpose to verify it's the new line the problem. So you can stop reading. I am being very long on purpose to verify that. Is this long enough? I guess so. I hate my bridge anyway even if this works. Sorry for the long messaage, bye.
--- Log closed Mon Sep 19 00:00:23 2022