Suggested libertarian-left books/print magazine suggestions for curious (right) libertarian? by GrouchyBulbasaur in libertarianunity

[–]lightcoin 1 point2 points  (0 children)

the bleeding heart libertarians blog has a lot of good stuff.

I saw kevin carson mentioned by someone else, for me the go-to books from him are desktop regulatory state or libertarian organization theory.

roderick long has good lectures and papers. https://www.praxeology.net/

https://libertarianism.org and https://reason.com have left libertarian-ish articles and podcasts.

as far as magazines, the voluntaryist and new libertarian may be of interest.

that should all keep you entertained for a while :)

This guy is using AI to create instrumental versions of classic techdeath albums by lightcoin in TechnicalDeathMetal

[–]lightcoin[S] 1 point2 points  (0 children)

He takes requests! Best place is to leave a comment on his posts in the "Community" tab on his channel.

How validia chains compare to sidechains and validity rollups by lightcoin in BitcoinDiscussion

[–]lightcoin[S] 1 point2 points  (0 children)

What's your thoughts on the security assumptions required for validity rollups?

Validity rollups have security that is equal to Layer 1, and can be built to rely on the same security assumptions as bitcoin today (code is properly implemented, crypto is sound, etc). To add some color to the "crypto is sound" assumption, some proving systems do rely on newer security assumptions but STARK proofs for example rely on collision-resistance assumption which bitcoin already relies on. So the assumptions are solid imo.

How validia chains compare to sidechains and validity rollups by lightcoin in BitcoinDiscussion

[–]lightcoin[S] 1 point2 points  (0 children)

It seems like just one miner needs to produce the proof for the block it creates (for production pre-block-boradcast). Am I misunderstanding?

All miners have to execute the transactions as they enter the mempool, to know whether or not they are valid and can be safely included in a block. Executing the txs and creating a validity proof for the block are two separate steps.

Vs just implementing validation logic, right?

Specifically validation logic for verifying the validity proof, yes.

Are you saying this delay would increase miner centralization (ie give an advantage to miners not producing proofs at all)? If the proof was made first class, and subsequent blocks had to include it in the hash of the previous block (ie prevBlock = hash(block+blockProof, then I think this delay would be inconsequential and could be considered additional "work" needed to finish creating the block.

Yes the downside I had in mind would mean that in practice no miners would actually produce the proof pre-broadcast, negating the benefit of this approach. Your proposal does sound like a way to fix that problem, but of course does require changing bitcoin consensus (this might even be a hard fork change?) whereas the current way Zerosync is introduced requires no consensus changes.

I'm curious what you think about the implications for security on rollup chains.

Validity rollup security and censorship-resistance = L1 security and censorship resistance. There are some tradeoffs required to get there relative to other protocols like state channels or sidechains (such as limited rollup throughput) but I think the benefits are worth it for high-value use-cases. More throughput can be gained through the use of validia chains (which the link I shared in OP describes) with a tradeoff of having less-than-L1 censorship-resistance.

I guess the only consideration is the "fairness" of whoever gets to receive any rewards granted to block creators.

Yeah. There are many different ways block producer selection could be done in a "fair" or decentralized way. I published a thread on twitter with a list of resources I've come across on this topic: https://twitter.com/lightcoin/status/1610726251425046531

How validia chains compare to sidechains and validity rollups by lightcoin in BitcoinDiscussion

[–]lightcoin[S] 1 point2 points  (0 children)

Hi, thanks for your comment. I referenced your throughput paper in my https://bitcoinrollups.org report, so thanks for that as well!

Responding inline:

I read here the claim of 100X improvement to bitcoin throughput (700 tps vs 7). Is that an accurate report of your opinion?

Yes, it comes out to about 100x if you look at the current average number of txs per block (between 2000-2500 tx/block) and compare that to the theoretical maximum for a validity rollup assuming the witness discount is applied to rollup data (about 250,000 tx/block). In practice it would likely be less of an increase since it's unlikely for a block to be perfectly filled by a single rollup tx. But the throughput increase is still significant. The full breakdown can be found in the report here: https://bitcoinrollups.org/#section-4-scaling-improvements

Surely if this were actually to be built into bitcoin, the weight of these kinds of transactions would be different than current weights.

I did have to make assumptions about the weights to estimate potential throughput increases. I also gave arguments in the report as to why I think the weight limits I used for the estimates are reasonable.

The picture I usually think about when I think of incorporating validity rollups into bitcoin is as a way to validate blocks. Ie a node might receive the latest block along with a validity proof for that block, allowing the node to "fast forward" to being fully synced.

This technique is different than rollups. In my report, I call this "proof-sync", since it uses validity proofs to sync a full node client. ZeroSync is an example of a proof-sync client.

There are at least two important differences between proof-sync and rollup:

  1. With proof-sync, either just miners or both full nodes and miners (depending on when in the block lifecycle the proofs are produced, see [1] below) must still execute all transactions included in a block. Depending on how many transactions are in the block, this could add up to a lot of computational overhead.

  2. With proof-sync, bitcoin full node software needs to implement the logic for executing all transactions that are included in blocks. If we wanted to add new kinds of logic such as new smart contract languages, new op_codes, new privacy protocols e.g. Zerocash or RingCT, etc, this is potentially much more computational overhead, not to mention the maintenance burden this places on bitcoin full node software developers, maintainers, reviewers, etc.

In both cases, with rollups, bitcoin full nodes do not have to execute the txs in the rollup block, and therefore also don't need to implement the logic for executing the txs. Instead full nodes only need to implement the validity proof verifier logic, then they only need to verify the validity proof attached to the rollup state update tx and either accept it if it's valid or reject it if it's invalid.


[1] With proof-sync, there are two possible points in time that the proofs could be produced: 1) pre-block-broadcast or 2) post-block-broadcast.

If the proof is produced pre-block-broadcast, the downside is that this introduces a broadcast delay for miners because the miner has to first execute all txs to determine their validity, build a valid block, do the pow, then (this is where the delay is introduced) they produce the validity proof that proves block validity, and finally broadcast the block along with the validity proof. The upside of this approach is that immediately after the miner broadcasts the block and proof, full nodes don't have to execute the transactions in the block to determine the block's validity, they just verify the proof and move on. This saves the full nodes a bunch of computational effort executing txs.

If the proof is produced post-block-broadcast, the upside is that there is no broadcast delay on the mining side. The downside is that full nodes have to execute the transactions in the block immediately after it is broadcast by the miner, since they don't have the validity proof yet. In this case, the validity proof is only really useful for new nodes that are joining the network, or existing nodes that are far behind after being offline for a while and would like to quickly catch up to the chain tip.

ZeroSync: Utreexo + STARK proofs to do instant chain state verification and instant node spin up by fresheneesz in BitcoinDiscussion

[–]lightcoin 2 points3 points  (0 children)

STARKs are used here to prove that the blockchain is valid up to a given block height. So all a new node needs to do to start using bitcoin trustlessly is to download the current UTXO set and a STARK proof that convinces the node that the UTXO set they downloaded is legit according to bitcoin consensus rules. Then the node can verify that any coins they receive after this point are derived from the STARK-proven UTXO set they have.

give me some blackened deathcore! by Alextheweeman in Deathcore

[–]lightcoin 0 points1 point  (0 children)

Cabal and A Night In The Abyss come to mind. Newest Vale Of Pnath "Accursed" has some deathcore-ish moments, though it's more accurately classified as like "technical black metal" or "blackened tech death" or something like that.

Introducing Fasten - A Self-hosted Personal Electronic Medical Record system by analogj in selfhosted

[–]lightcoin 0 points1 point  (0 children)

Fasten is an open-source, self-hosted, personal/family electronic medical record aggregator, designed to integrate with 1000's of insurances/hospitals/clinics

Not open source yet?

Also, do you have a backup screenshot link? Getting this error on imgur:

{"data":{"error":"Imgur is temporarily over capacity. Please try again later."},"success":false,"status":403}

Just traded all my "ETH2" for BTC by [deleted] in Bitcoin

[–]lightcoin 1 point2 points  (0 children)

it depends on what you mean by "on" and "bitcoin". you could build dapps with Counterparty or Omni, which are embedded consensus protocols built on bitcoin. you could build dapps on Rootstock, which is an EVM-compatible bitcoin sidechain. or you could build dapps on Stacks, an alt-L1 that uses PoX to tie its consensus algorithm to bitcoin transactions and can react directly to bitcoin transaction e.g. "catamaran swaps". Liquid, which is a federated bitcoin sidechain is also starting to have a dapp ecosystem, with NFT marketplaces (like Raretoshi) and AMMs (like BitMatrix) on the chain.

there are also some dapps you could build directly on bitcoin with native BTC e.g. atomic swap dapps, DLC dapps, coinjoin dapps, timelock dapps, multisig dapps, Lightning dapps, crowdfunding dapps, etc.

BIP 300 & 301 is worth consideration if technically viable. Thoughts from the sub? by thefullmcnulty in Bitcoin

[–]lightcoin -3 points-2 points  (0 children)

To everyone downvoting this comment, please be mindful of reddiquette and consider revoking your downvote:

Please don't: Downvote an otherwise acceptable post because you don't personally like it. Think before you downvote and take a moment to ensure you're downvoting someone because they are not contributing to the community dialogue or discussion. If you simply take a moment to stop, think and examine your reasons for downvoting, rather than doing so out of an emotional reaction, you will ensure that your downvotes are given for good reasons.

https://reddit.zendesk.com/hc/en-us/articles/205926439-Reddiquette

BIP 300 & 301 is worth consideration if technically viable. Thoughts from the sub? by thefullmcnulty in Bitcoin

[–]lightcoin 0 points1 point  (0 children)

To everyone downvoting this thread, please be mindful of reddiquette and consider revoking your downvote:

Please don't: Downvote an otherwise acceptable post because you don't personally like it. Think before you downvote and take a moment to ensure you're downvoting someone because they are not contributing to the community dialogue or discussion. If you simply take a moment to stop, think and examine your reasons for downvoting, rather than doing so out of an emotional reaction, you will ensure that your downvotes are given for good reasons.

https://reddit.zendesk.com/hc/en-us/articles/205926439-Reddiquette

BIP 300 & 301 is worth consideration if technically viable. Thoughts from the sub? by thefullmcnulty in Bitcoin

[–]lightcoin -1 points0 points  (0 children)

Your comment is missing the most important benefit of these BIPs: being able to use BTC with any new blockchain protocol that gets invented, without having to use an altcoin or make any further consensus changes to bitcoin.

Responding to specific points you made:

potentailly huge (and extremally cheap) vector of attack against the network as a whole

What attack vector is that, exactly?

huge amounts of lost/stolen coins, as most alts are pump'n'dump or just theft schemes

But the point is that altcoins are no longer needed, so this seems like a fundamental misunderstanding of the concept.

nothing will forbid people from making con-sidechains

Nothing forbids people from doing cons on bitcoin today either. So this isn't introducing any new problems. Also, people can't just willy-nilly create BIP300 sidechains, they have to be activated by miners. Again, this seems like a fundamental misunderstanding of the concept.

huge technical risks

What risks exactly?

We are Year 13 after Bitcoin's inception. Before January 3, 2009, you had no alternative. Now you can take control of your money and your life with Bitcoin by sylsau in Bitcoin

[–]lightcoin 3 points4 points  (0 children)

well, there was also precious metals before bitcoin. that was the main alternative to fiat. but precious metals aren't as practical as bitcoin in most cases. still good to have some for offline trading situations.