--
The coins you collect from routing fees can support the expenses/costs of running your Lightning node? Hard to believe, but that's good. [/quote] It's not hard to believe that the fees you collect from forwarding can support your paying fees. You just need to not connect to 4999ppm fees charging peers... Moreover I've no infrastructure cost. And not doing altruistically takes the service or instant non-censurable payments into account  . Plus do you think that Lightning's fee-structure now is in its final form? It won't increase depending on demand? Because it's very hard to assume that it won't if the economic cost is scarce.
I'm not sure so.. I don't know. |
|
|
|
Who among the consistent Lightning users here have been running a node, specialized specifically for routing transactions/providing liquidity, how long have you been running it, and what's the averge cost of running it?
I've been running one (C-lightning) for almost two years now, and it costs me barely nothing : just setup on top of my old computer which already ran core. So it costed me a low end computer which I had for free (I'm in the process of changing it, but I'm not that well connected after all) and electricity cost for an idle computer. The bigger cost is the coins to open channels. Practically speaking, how long, do you believe, can you stake your Bitcoins, and altruistically continue running your node, rebalance channels, to provide liquidity without incentives? I've been doing this for more than a year now, with rebalance fees at my charge. I've stopped doing this by closing channels to peers charging too much fees and connecting to peers charging little fees (which I found thanks to a little plugin I wrote). This way, not only I'm no longer altruistically running my node (since I make use of rebalanced channels) but I can also earn some (milli)sats if I happen to charge less fees than my neighbors. |
|
|
|
C-lightning can run against a pruned node for example, so you can have a full Bitcoin-today setup for 30GB of storage (or even less).
I had been using LND for most of the time; that's why I mostly mention features available only for it. Thanks for bringing it up. Running a pruned node sounds more appealing than experimental software. What other c-lightning features are worth paying attention to? I'd say plugins for extensibility. If you are a regular user, you can choose from a constantly growing list of community-curated C-lightning plugins. If you are a developer, or at least know a bit of Python or other high-level language (there are libs for Python, JS, Go, C, C++), you can script a C-lightning plugin really quickly that fits your needs. The C-lightning server (`lightningd`) will send to plugins notifications about events (like, "an invoice has been paid") or hooks (like, "I got an HTLC, its details are {}, what do I do with it ?"), and allow it to register new RPC commands (for example the summary plugin adds the `summary` command which give a higher level summary of your node's status). Otherwise, not that many features as C-lightning aims to only implement the core functionalities : anything higher-level belongs to plugins. |
|
|
|
The only alternative that comes to my mind is neutrino I know you are talking about LND, but for reference that's not specific to all LN nodes. C-lightning can run against a pruned node for example, so you can have a full Bitcoin-today setup for 30GB of storage (or even less). |
|
|
|
Hi, While 0.9.0 does not support sending MPP (Multi-Path Payments), it does support receiving them. It looks like we will have working MPPs by the end of the year! I've been wondering for a while now how that would work. You don't want one path to be confirmed, and the other paths to get stuck. That would result is a partial payment. It turns out the magic word to solve this problem is "Atomic". I'll only quote the magic part, the full article explains it in depth: If Bob does not receive all of the partial payments, then he cannot generate the base pre-image thus making it atomic. What you describe is a proposal made from Lightning Labs team (namely Olaoluwa and Conner), which is about "mathematical" atomic multi-parts payments. However, what has been merged to the spec and is implemented by LND, C-lightning and Eclair (maybe Rust-Lightning too?) are kind of "economical" multi-parts payments. The receiver won't claim (and thus release the preimage, which is a proof of payment) any part before having all of them. Doing so would be economically irrational as the receiver would accept the payment before receiving it entirely. As such all parts use the same payment hash, thus the same preimage (== proof of payment). Some refs: - Link to the "mathematical" AMP mailing list thread https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html- Link to the "mathematical" AMP spec proposal https://github.com/lightningnetwork/lightning-rfc/pull/658- Link to then "economical" AMP (merged) spec proposal https://github.com/lightningnetwork/lightning-rfc/pull/643 |
|
|
|
Hi, Following scenario: A government would like to destroy Bitcoin. It buys a significant number of ASICs to build up a huge mining farm and carries out a 51% attack.
From my point of view it will not be so easy to buy so many ASICs as once - what do you think?
Absolutely, that's usually the first argument I make when discussing 51%. Is there enough hashrate available so that it surpasses all the hashrate allocated to Bitcoin ? If so, why not mine Bitcoin ? Even if it's for trying to hurt, a one (or two?) block(s) reorg won't affect the network that much (if not at all, for one block). Trying to reorg >2 block becomes really difficult.. Another question: Will it be noticed (how?) that somebody buys a big stack of ASICs and/or are we able to identify such a behavior monitoring the network's hashrate?
If the aim is to 51%, then the hashrate won't be allocated to the Bitcoin network. So, no, not by monitoring the hashrate. |
|
|
|
Hi, Each block has a coingen transaction for the block subsidy - so far so good.
But how does the miner gets the fees of transactions in a block? Is there a "getTransactionFees()" transaction?
Transaction fees are implicit in Bitcoin tranasctions. They are the difference between the sum of the inputs' value and the sum of the outputs' value. All transactions need to have `sum(outputs) <= sum(inputs)` (and not just equal! Which would, by the way not be relayed by most of the nodes). A block generator needs to create a coinbase transaction outputs which value is <= to `block_subsidy + fees` with `fees = sum(inputs_of_all_txs) - sum(outputs_of_all_txs)` for other network (full) nodes to accept it. |
|
|
|
Who among the consistent Lightning users here have been running a node, specialized specifically for routing transactions/providing liquidity, how long have you been running it, and what's the averge cost of running it?
I've been running one (C-lightning) for almost two years now, and it costs me barely nothing : just setup on top of my old computer which already ran core. So it costed me a low end computer which I had for free (I'm in the process of changing it, but I'm not that well connected after all) and electricity cost for an idle computer. The bigger cost is the coins to open channels. |
|
|
|
Hi, I believe most of the people in the world are honest enough to not even try to double spend ( I may be naive, but i prefer to live like this than to consider everyone is a thief)
I don't think so, but we can at least say that it's less risky in-person.. Moreover it's more cumbersome to make a double spend that it's usually implied, and if people are going to Burger King because they don't want to bother cooking... There is a low probability they actually try to make a double spend for a 5 dollars worth transaction if it's not "for the fun" (not considering RBF though). Anyway, I was thinking how easy is it to do a double le spending in this case? Have anyone ever tried?
I've tried and succeeded on a low-hashrate shitcoin I created for a series of workshop I organised. The transaction broadcast is almost instantaneous across all the network. Does broadcast time makes any difference? I believe most wallets won't let you double spend (never tried..)
You need to target miners if you are trying to double spend a final transaction. In the example I was talking about above I cheated because I was the owner of the only source of the hashrate so ... ^^ My question is:
If you have a transaction which is already broadcasted across all full nodes mempool, if you send a other one with a higher fee, will nodes recognize it as a legit transaction?
Not if the transaction is final, but they will accept a block containing the new one. If it is possible, isn't it a good idea to create a BIP proposing to disallow to double spend of a transaction already in mempool? What would be the cons against that?
The block chain is shared across the nodes, everyone has the same. The mempool is not at all, so consensus decisions cannot be made out of it. That said, that's already the behavior of bitcoin-core (for, once again, non final transactions). But another implementation allowing this wouldn't fail out of consensus. Newbie question but I always thought zero confirmation transactions are interesting.
At least as much as is mempool policy  PS: If you're looking for a double spend on Bitcoin, iirc Peter Todd double spent some Reddit Gold some time ago. You could find some interesting stories. |
|
|
|
Proof Of Stake isn't suitable for a "cryptocurrency". To avoid endless quoting and repeating, here is a great summary by Andrew Poelstra about why it is not. |
|
|
|
*Sorry I answered but never clicked on post.....* I'm reading about this, but for example considering SIGHASH_SINGLE "This type of signature signs all inputs, and exactly one corresponding output", in a transaction like this A->B->C, B's unlocking script has the sign but does he signs A's outputs or new generated B's output?
`SIGHASH_SINGLE` signs the input and output at the same index, and partially signs other inputs. I'm not sure of this `A->B->C` transaction you're describing; if this is something like ---------------------------
| A's input | output 0 (C?) |
| B's input | output 1 (C?) |
---------------------------
then A signs the input at index 0 and the output at index 0, and B signs the input at index 1 along with the output at index 1. Could you be more precise about the structure of the transaction you're talking about ? |
|
|
|
Hi, Oh, I see.
So let's say, that there is a multisig transaction, where on the output are 2 addresses. Who can then spend this output? Either one of those two?
No you need to create a transaction (`createrawtransaction`) and sign it with both of the corresponding public keys. Here is a step-by-step that might be useful for you. |
|
|
|
Hi, The meaning of digital signature in Bitcoin can be summarize as "a digital signature can be used to unlock outputs, because it shows that we know the private key of an address"? Where the address refers to the receiver.
"because it satisfies the conditions of a standard script type", but yeah it "shows" that you own the private key without revealing it. The address doesn't refer to the receiver, see it more like "the conditions to satisfy to spend the newly created output". I don't understand in particular these points:
2) Why do we need to sign previous output's pubkey script?
3) and 4) if this is the unlocking script why do we need to sign things for next transactions?
As you broadcast the transaction in an untrusted environment, signing crucial parts certifies that it cannot be tampered. Here tampering, for example, the locking script (scriptpubkey) of the newly created output would change the conditions under which this output is spendable. With a higher level of abstraction it'd "send the coins to another destination". EDIT: For going further, you could give a look to SIGHASHes which dictates which parts of a transaction are signed, leaving some malleability/flexibility for some advanced usage. |
|
|
|
Antiquated? I thought that P2SH is still the only way to do your own "creative" scripts that will be accepted by the network. Like the first implementation of segwit showed.
It's P2WSH, hence the point about BC1 addresses. |
|
|
|
Thanks for clarification. But another question, is p2pkh a smart contract?
The term "smart contract" should be IMO to ban (and the wiki did a good job in renaming it to distributed contract) as it has been attributed too many meanings (and nonsense). All transactions contain "distributed contracts" (scripts), and P2PKH is the name of a standard type of these contracts. |
|
|
|
Sad times  Why ? It's just becoming obsolete (note that binaries for other 32bit architectures (like ARM) are still published). |
|
|
|
Bitcoin-core team is considering dropping support for 32-bit x86 Linux Bitcoin binaries. I'm just relaying here in case someone who's not subscribed to the bitcoin-core-dev mailing list is still relying on it. Quote from MarcoFalke's mail to the list: Now that other major software projects and operating systems dropped support for 32-bit Linux, is there anyone still using the statically compiled i686 Linux gitian binaries? None of the developers are running 32-bit Linux on a daily basis, and testing is getting harder as neither Ubuntu, nor latest Fedora have 32-bit releases of their operating system. Unless someone requires the gitian binaries, I'd suggest to drop them. If anyone remains on a 32-bit Linux platform, they can build (and test!, with `make check` and `./test/functional/test_runner.py`) from source. This is even possible on systems with less then 1GB of RAM, see https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#memory-requirementsand https://github.com/bitcoin/bitcoin/issues/17504 |
|
|
|
Hi, Details of Transactions with python, ideally as REST-API?
Esplora is exactly what you're looking for (but beware of the storage requirements ). I tested it earlier and it's really great. |
|
|
|
Usually P2P exchanges don't allow for volatile payment methods such as credit cards. What about Coinbase, Cex.io or BitPanda. I think all three allow crypto to fiat exchanges assuming the client has gone through KYC. They aren't P2P exchanges, are they ?.. |
|
|
|
|
Show Posts
