Two reasons: (1) it's annoying to test with multiple files because my browsers cache separate js files, and I have to remember to clear my cache before every test, otherwise my code changes don't take effect (2) shareware is easier to deploy as a single file rather than a folder
it's not "fully turing complete" because there is a limit on how many cpu cycles this cpu can run for. It's a large limit, somewhere on the order of 2^128 cycles, which is far more cycles than any cpu has ever run. But it is technically a limit, so this cpu is not "fully turing complete" and is guaranteed to halt eventually. Just long after the death of the universe.
Besides every program being guaranteed to halt eventually, another factor is this: the two parties agree on the program up front, and the challenge period limits how long the prover has to run it. So if the prover for some wild reason agrees to run a program that doesn't halt quickly, the verifier can initiate a challenge to prove the end state, and then the prover will simply lose his money when he can't get the program to terminate before the challenge period expires.
I will be following this channel closely for more content. Great stuff 👌 I had this idea to create a 24/7 BTC charity /daily orange-pilling service where some few sats are "streamed" to users freely every day Hoping to implement it using hedgehog sometimes this year. Side note: I was also hoping to build a system that tracks the value of BTC nodes using the value of Lost BTC. I think lost BTC gives BTC nodes intrinsic value and they can be traded based on the average value of lost BTC represented by each node.
OK, so I guess the problem is, you need 3 transactions to open and close a Hedgehog channel, whereas in Lightning you only need 2. Just a question on what you want to tradeoff.
Just started watching this video, it sounds like it could be a lightning killer at first glance. I think the fact that the recipient has to be online to receive the payments is a huge disadvantage for Lightning. I saw a recent article, we're seeing lightning nodes actually go offline, and they were trying to spin it as positive somehow (seems like a cope).
As far as I can tell, only 1 person deposited 0.25 BTC into the smart contract to begin with, ideally each one would deposit 0.125 BTC, but then they'd have to use partially signed bitcoin transactions, right? Another thing is teams usually aren't 50/50 to win, there's a favorite and an underdog, so Alice and Bob would have to agree on the odds as well
If I was building this out in real life I would probably use partially signed bitcoin transactions to ensure both parties deposit funds, though another option would be to use an atomic swap so that Alice pays Bob to put the total into the contract in such a way that he only collects her payment if he does so. Also, yes, the two parties would need to agree on payout terms such that both are happy with whatever the terms are
At about 46:00, I think you're being unfair to satoshi. Bitcoin core needs to know how long the script is in advance, so it's prefixed by a length of script. Otherwise, you'd have to have some kind of 'end of script' opcode, but let's say that it was 0xFF for argument's sake - but then 0xFF can also be part of a hash or preimage, so that would confuse Bitcoin Core. Perhaps there's a better Javascript bitcoin library out there?
I think you could route payments the same way lightning routes them, with a chain of htlcs that ends at your destination. Only difference is, your recipient could be offline. You send him or her the data he or she needs to redeem his htlc, and he or she collects it the next time he or she gets online
The idea of connectors is pretty cool. I've heard people talking about conditions like: do X iff UTXO A exists. But we can't do this in script, and it would be a horrible idea do sf in. But a solution that doesn't involve arbitrary UTXO set introspection is awesome! I'll take a further look at the payment protocol, it seems really promising. Thanks for sharing
but we *can* do it in script OP_CHECKSIG is a script opcode and any signature it checks must commit to at least one input. When you use OP_CHECKSIG on a signature that commits to input utxo A, your transaction will fire iff utxo A exists
Man you are building some awesome functions, ? Could this be used with a BlockStream Satellite base station for the online account, then to allow multiple offline accounts to do transaction? No need for internet. And can a seed signer be used for this ?
exactly correct a hedgehog wallet could be fully backward compatible with lightning though, so in some sense hedgehog is like a lightning extension or plugin
1 deposit transaction 9 while each player takes a turn marking the board 1 withdrawal transaction So there are 11 transactions in the most expensive case The middle 9 transactions are skipped if there is no dispute, leaving only 2 transactions, a deposit and a withdrawal
