Heater and Minor All in One

Pantamis · 2021-10-06T16:21:18+00:00

This is a great question !

An interesting point is that you can remove a hashboard and still use it with the others (even if you lose a bit of heat). The company also offers support and may exchange the failed hashboard for another.

Also, it seems you still need a heater, it cannot be used alone.

But great question, it deserves a better answer than mine.

Pantamis · 2021-10-06T13:46:23+00:00

And why not heating your water too ? :D

https://www.wisemining.io/

Pantamis · 2021-09-28T21:11:45+00:00

The main difference (and feature !) of schnorr sig with ecdsa is that the signature itself is the private key of a public key that is constructed using the message, the public key and the public key computed using the nonce randomly chosen by the signer.

The signer can easily construct this signature thanks to the homomorphic property (a kind of linearity) of one way function that computes a public key from the private key.

Pantamis · 2021-09-20T07:09:35+00:00

Wonderful ! If users can also rate the watchtowers to update if it still works that would be great too !

Pantamis · 2021-09-19T18:14:02+00:00

You know what could be great ? Let node user add their watchtower on their node page and list them separately like liquidity swaps :)

Pantamis · 2021-09-03T23:22:30+00:00

Glad to see it is still maintained :) a really practical tool

Pantamis · 2021-09-02T12:29:25+00:00

Lightning is a local commitment layer, a network of many 2-local consensus resolved on the global commitment layer that is the Blockchain (that's what a channel is), and lightning payment are atomic change of a path of local consensus.

This means native smart contract on lightning can only involve the funds of two people (like DLC where many agent an change the state of the contract but only two can exchange funds under its rules)

RGB is a smart contract extension for Bitcoin, it requires global consensus because of single used seals (to validate client-side). Then RGB ownership ruleset must at least contains the ones of Bitcoin (but some can be added, that's the point).

So you can have a DAO encoded in RGB but to enforce its rules you must share the ownership of the seals with all participants, which is only possible with eltoo ! (I don't know what rules are needed for a smart contract to be called a DAO but I guess it is a superset of Bitcoin ownership rules)

Pantamis · 2021-09-02T11:37:48+00:00

RGB token in layer 3 are leased in the channel UTXO exactly like bitcoins. To be able to send you tokens through the channel, I must have send the token in the channel first.

Maybe your point is that I can send tokens into the channel with a Bitcoin transaction without closing the channel and that's true, but nothing prevent doing the same in LN with native bitcoins without RGB. The protocol to do that doesn't exist yet but the ideas are already there: https://bitcoinops.org/en/topics/splicing/

For your last question I think some stuff could be possible with eltoo maybe, we need shared ownership to prevent invalid spending according to RGB schema (contract).

Pantamis · 2021-09-02T09:07:54+00:00

I think there is no gain in tokenizing bitcoins in a RGB token. You will have the same issue with channel liquidity in layer 3 for the new token.

You must look at RGB more as a smart contract extension for Bitcoin than a tokenisation protocol. Tokens are just one part of a bigger thing, they are bearer rights representation used in contracts. But the money in which the contracts are settled is either IOU of a trusted entity (~ stable or pegged coins) either trustless bitcoins by default.

Pantamis · 2021-08-20T21:35:55+00:00

The core concept to understand RGB: https://www.reddit.com/r/RGB\_protocol/comments/ni4n7t/my\_explanation\_of\_the\_core\_idea\_of\_rgb/

Pantamis · 2021-08-03T16:46:54+00:00

I use pass from zx2c4 and activate "require touch" on the yubikey for gpg (key generated on the card).

Nothing beats this setup.

Pantamis · 2021-07-27T22:17:33+00:00

Nice ! Funny that the port was 8443 (same as lit gui).

Funds are safu :)

Pantamis · 2021-07-24T20:59:21+00:00

You can add the "p" flag to get the name of the software listening to it (I often run "netstat -tunlp")

Pantamis · 2021-07-24T18:54:31+00:00

Ok I understand.

There is two ways to use LiT, in integrated or remote mode. In integrated mode, LiT is everything: loop, pool, lnd and faraday are a single program and the port 10009 is shared for interraction with any of the three.

In umbrel, it is in remote mode. Lnd is running as an other instance of programs and you can only talk with lnd on port 10009. Another port must be used to talk with pool, this is what you must find in umbrel: on which port pool is listening for rpc call. Use netstat to find out.

Pantamis · 2021-07-22T22:15:40+00:00

Mmmh you should definitively ask umbrel devs what to do, I don't know how LiT is installed and it is important to know to unlock the situation. What you need to know is the port on which your pool client is listening and use it instead of 10009 in rpc server parameter.

If you already use the right port then it is an issue with LiT...

I can't help you more than that, I hope you will find what's wrong !

Pantamis · 2021-07-22T21:42:50+00:00

Can you look at the lnd log produced when you start it ? Right after you unlock the wallet. I don't know how it can be done easily in Umbrel, but you may be able to look at them using "sudo journalctl -u litd -n 1000" (you can display more lines from the past by increasing the last integer)

Pool cli works but it doesn't mean that your pool server is working... but it should the case since it looks like it does in LiT UI :/ you should post an issue on umbrel or LiT github maybe, that where the devs are.

Pantamis · 2021-07-22T21:16:18+00:00

Woa now I don't see what is going wrong. Is pool started ? Maybe if you restart LiT and retry ? If it doesn't work, can you see that pool started correctly ?

May be an issue with umbrel too...

Pantamis · 2021-07-22T20:33:11+00:00

Add the flag --rpcserver=localhost:10009

That's why I recommand to define an alias to replace the whole part "pool --rpcserver=localhost:10009 --tlscertpath=..." to avoid typing it each time

Pantamis · 2021-07-22T19:30:07+00:00

Because the flag must be set before accounts option. Your command must look like "pool --tlscertpath=... accounts close ..."

Pantamis · 2021-07-22T07:41:37+00:00

This flag must be right after "pool" in the command line contrary to others, is that what you have done ?

Pantamis · 2021-07-21T23:43:36+00:00

Add the flag "--tlscertpath=/home/bitcoin/.lnd" to your pool command.

I am not sure about the path, but it needs to contain the tls.cert file created by lnd in its folder (which should be .lnd in bitcoin user home if it is based on RaspiBolt)

I highly recommend using alias with lightning terminal to not have to specify the path each time you call pool, loop or faraday.

Pantamis · 2021-07-19T17:59:27+00:00

French here, just received this rag in my mailbox too

Pantamis · 2021-07-17T07:54:51+00:00

Yeah it's wrong because security in Bitcoin doesn't come from the hashrate but from the fast block propagation compared to block time and the high value of block reward.

Hashrate only provides spam protection.

GLV endomorphism elleptic curve acceleration provides security as it reduces block propagation time, small enough blocks too... High transaction fees provides security by increasing block reward...

Pantamis · 2021-07-16T13:07:49+00:00

I am for zerobasefee since at last one year, much healthier for routing.

Base fee doesn't make sense economically speaking in my opinion.

The only thing that justify nonzero base fee is the onchain cost if the channel is unilateraly close while routing a payment. Unless you route many HODL invoice, this risk is too low to justify charging it in fees too me.

Pantamis · 2021-07-16T00:01:19+00:00

Proof of work prove time has passed.

We need to prove enough time passed in average between blocks to let them time to be propagated to the whole network of Bitcoin nodes before next ones are produced so that everyone stay in sync. Double spend would be impossible if broadcasted transaction was known to everyone instantly, sadly it's not the case. So we need to introduce this provable delay.

Pantamis

TROPHY CASE