Disclosure: I'm a Blockstream co-founder
Major feature contributions to Bitcoin Core:
Greg Maxwell, Andrew Poelstra and myself (as well as several other contributors) worked on libsecp256k1, a well-tested library for efficient elliptic curve cryptography using the curve secp256k1. Bitcoin Core switched signing to it in 0.10 and verification in 0.12 (with a ...
Blockstream launched a satellite service. It did not launch a satellite.
Bitcoin blocks are being broadcast by Blockstream, by contracting with several existing several satellite systems. These satellites are primarily designed for broadcasting TV signals, and thus don't run their own full nodes; the broadcast is dependent on ground stations that uplink ...
Disclaimer: I'm a Blockstream co-founder and the primary author of the SegWit proposal.
I believe SegWit benefits everyone in the Bitcoin ecosystem. It solves several long-standing problems that hurt future evolution and scalability:
Transaction malleability complicates multi-transaction contracts
Lack of script versions makes introduction of new opcodes ...
As others have said you can use https://blockstream.info/api/address/bc1qgsmfaz22lzy08wqjspd8xtm43hal5tgz4hyac6 for the JSON - the doc is in reference to running a local instance - the exact endpoint is depending on deployment, the default deployment we use has nginx forward /api/ requests to electrs without the api bit https://github.com/Blockstream/esplora/...
The error hints that you're not signing the transaction correctly.
In fact, you're generating a signature with:
txHash := updater.Data.UnsignedTx.TxHash()
sig, err := privkey.Sign(txHash[:])
But the current transaction hash is not what you need to sign. Instead, you should use HashForSignature for legacy input types:
sigHash, err := updater.Data.UnsignedTx....
Your understanding of the commitment root is correct. Taking advantage of Haskell's laziness, feel free to put undefined into the signature when computing the commitment root.
At the moment, the witness root is not used in the protocol. There are some ideas on how to use it in more sophisticated protocols, but those ideas haven't been realized yet. ...
It is unlikely that the Blockstream business model requires small blocks. For Blockstream to succeed, Bitcoin will need to succeed independently or there will be limited demand and other devs will increase the block size and the model will fail anyway.
As far as I know, they don't have an explicit business model published anywhere. We do know that they are working on:
Side chains - a two-way peg that has fixed transfers of value from bitcoin to a sidechain and back.
Lightning network - a network of transactions that can be updated relatively quickly (seconds, theoretically) and provably given if the ...
When I set up a lightning channel with a node, have I need to put some bitcoins in it?
Generally, yes. The person who initiates the channel creation process (i.e. the person that says "I want to open a channel with you") is the one who funds the channel.
Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), ...
Grubles has written up a guide for how to set up a blockstream satellite node: https://medium.com/@notgrubles/building-your-own-bitcoin-satellite-node-6061d3c93e7. That should be helpful; it includes links to amazon where you can buy all of the materials required.
The seminal whitepaper on sidechains, "Enabling Blockchain Innovations with Pegged Sidechains," describes modifying Bitcoin's Script to support simplified payment validation (SPV):
To use Bitcoin as the parent chain, an extension to script which can recognise and validate such SPV proofs would be required. At the very least, such proofs would need ...
I know of their work on:
Sidechains and the soon to be released Liquid Sidechain and,
the Lightning Network
They lead these efforts and are close to implement a production sidechain. These contributions are quite impressive.
For the above projects some changes are required to bitcoin-core as well (e.g. OP_CHECKLOCKTIMEVERIFY, OP_CHECKSEQUENCEVERIFY, ...) ...
According to the documentation, anyone running a Liquid node can generate and fund a peg-in transaction. And anyone can run a Liquid node.
You'll need a participant, which can be an exchange, to peg-out and exchange your L-BTC for BTC though.
The peg-in is explained in more details here.
Short answer: yes.
However that depends on the question if liquid supports segwit and creation of a lightning network. I have not looked at the details of liquid but I believe it does.
The lightning network protocol itself is pretty agnostic to the underlaying blockchain. If you look at the channel announcement messages defined in BOLT7 you will see that ...
If an address appears in the vout list, it is incoming for that address.
If the address is in the vin list, it is an outgoing transaction for that address.
Addresses may appear in both the vin and the vout.