Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin

[Jeremy via bitcoin-dev]

Oscar,

Sapio is essentially a 'Compiler toolchain' you run it once and then send
money to the contract. This is like Solidity in Ethereum.

Sapio Studio is a GUI for interacting with the outputs of a Sapio contract.
This is like Metamask/web3.js in Ethereum.

It's really not comparable to Lightning.

recommend starting with learn.sapio-lang.org :)

Cheers,

Jeremy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Autonomous Organizations (DAOs) Will Save Bitcoin

[Oscar Lafarga via bitcoin-dev]

>
> None of this particularly requires CTV, but it does require the type of
> composable and flexible software that I aspire to deliver with Sapio.


 Does this imply that there is some kind of Sapio client to be run
alongside a Bitcoin full node similar to how a Lightning node would
operate? If so, are the computation, bandwidth, and liveness requirements
for someone running Sapio contracts more or less comparable to Lightning?

The implementation approach seems pretty interesting overall and reminds me
of concepts like bitcoin bug bounties (https://bitcoinacks.com/ for
example) but perhaps with the potential for more sophisticated
functionality.

Will try to take a closer look at the https://github.com/sapio-lang/sapio
if that seems like a recommended starting point.

Thanks!

On Wed, Dec 22, 2021 at 10:47 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Devs,
>
> Enjoy! https://rubin.io/bitcoin/2021/12/22/advent-25/
>
> I'm really excited about opportunities for capital formation to happen
> natively in Bitcoin. This is actually a really big deal and something (I
> think) to pay close attention to. This is basically like running a little
> company with shareholders inside of Bitcoin, which to me really helps us
> inhabit the "be your own bank" part of Bitcoin. None of this particularly
> requires CTV, but it does require the type of composable and flexible
> software that I aspire to deliver with Sapio.
>
> business matter:
>
> There are two more posts, and they will both be focused on getting this
> stuff out into the wild more. If you particularly have thoughts on BIP-119
> activation I would love to hear them publicly, or at your preference,
> privately.
>
> If you like or dislike BIP-119 and wish to "soft-signal" yes or no
> publicly, you may do so on https://utxos.org/signals by editing the
> appropriate file(s) and making a PR. Alternatively, comment somewhere
> publicly I can link to, send it to me, and I will make the edits.
>
> edit links:
> - for individuals/devs:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/devs.yaml
> - organizations:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/bizs.yaml
> - miners/pools:
> https://github.com/JeremyRubin/utxos.org/edit/master/data/hashratesnapshot.json
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Oscar Lafarga
https://www.setlife.network

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[Jeremy via bitcoin-dev]

> If you introduce signing into mining, then you will have cases, where
> someone is powerful enough to produce blocks, but cannot, because signing
> is needed. Then, your consensus is no longer "the heaviest chain", but "the
> heaviest signed chain". That means, your computing power is no longer
> enough by itself (as today), because to make a block, you also need some
> kind of "permission to mine", because first you sign things (like in
> signet) and then you mine them. That kind of being "reliably unreliable"
> may be ok for testing, but not for the main network.


this is a really great point worth underscoring. this is the 'key
ingredient' for DCFMP, which is that there is no signing or other network
system that is 'in the way' of normal bitcoin mining, just an opt-in set of
rules for sharing the bounties of your block in exchange for future shares.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Bitcoin Advent Calendar] History and Future of Sapio

[Jeremy via bitcoin-dev]

Hi devs,

This post details a little on the origins of Sapio as well as features that
are in development this year (other than bugfixes).

https://rubin.io/bitcoin/2021/12/23/advent-26/

cheers,

Jeremy

--
@JeremyRubin 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] A Defense of Having Fun (and maybe staying poor)

[Prayank via bitcoin-dev]

Hi Jeremy,

> Eugene just dropped a project he’s been working on, and it’s really freakin’ 
> cool. He basically implemented a human v. chess engine in Solidity that mints 
> beautiful interactive NFTs of representations of the contract’s internal 
> states.

Not sure why NFT is involved here but experiment looks interesting. Maybe 
Eugene should try few things on Lightning as well: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019619.html

> Why isn’t Eugene working on Bitcoin?

There can be many reasons however Eugene can answer this question better.

> Working on Bitcoin is can be fun. But mostly it’s not. My post yesterday? 
> Theone describing new techniques to make Bitcoin more decentralized? I had a 
> lotof fun writing it. And then someone claimed that my work is “very 
> dangerous” toBitcoin.

I don't support what someone said about you in IRC however people do say crazy 
things online which has nothing to do with Bitcoin. Bitcoin can be different 
things for everyone.

> Bitcoin development has a bit of a burnout problem, with multiple 
> contributors stepping down their engagement recently. A likely cause is the 
> struggle it takes to ship even the smallest features, not to mention the 
> monumental effort it takes to ship a single large project.

I am not sure if this is the reason for people who will be less active in 
Bitcoin development now. And its a part of life, people will come and go. Show 
must go on. There will always be another developer who is more passionate and 
got more ideas to contribute. Funding in open source projects is an issue which 
exists outside Bitcoin as well and it is being addresses by several individuals 
and organizations.
> It’s hard to tell people, especially younger folk just entering the space, to 
> work on Bitcoin full-time. What I say is as follows:

It is hard but not impossible. I tried recently in a meetup in India. Ethereum 
is not the answer to all the problems in the worlds. If someone has issues with 
Bitcoin development, they can be solved.

> I don’t think I’m going to convince you here to care about NFTs. But I am 
> –hopefully – going to convince you to care about NFTs the phenomenon.

To be honest, its the trend right now and people care about it to get rich. 
There is nothing new or innovative about it. 

> For example, scaling challenge in Ethereum have led to the development of 
> Zero Knowledge Roll-Ups, privacy issues things like Tornado Cash, and more.

Rollups are memes and there are several articles, threads, research etc. to 
read about this. Most of their implementations are not even decentralized. 
Tornado Cash is not good privacy and even became worse after their governance 
token.


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools

[vjudeu via bitcoin-dev]

> Associating signing with proof of stake and thereby concluding that signing 
> is something to avoid sounds like superstitious thinking.
If you introduce signing into mining, then you will have cases, where someone 
is powerful enough to produce blocks, but cannot, because signing is needed. 
Then, your consensus is no longer "the heaviest chain", but "the heaviest 
signed chain". That means, your computing power is no longer enough by itself 
(as today), because to make a block, you also need some kind of "permission to 
mine", because first you sign things (like in signet) and then you mine them. 
That kind of being "reliably unreliable" may be ok for testing, but not for the 
main network.
> A signing scheme with proof of work would clearly not be proof of stake.
It is not that far from Proof of Stake as you may think. In Proof of Stake, you 
sign your whale balance with thousands of BTC, and then you can mine a new 
block, just by putting your coins at stake. In Proof of Work with signing, you 
also make a signature, and even if there is no amount in satoshis for your 
signing key, it is still somehow checked, who can sign a block and how many 
signatures are needed. So, is your private key that allows you to extend the 
chain is really worth zero satoshis, because there is no balance connected with 
your address/public key? Not really, it is worth a lot of coins, because it can 
be used to control the chain.
> The benefit of that over merge mining would be no extra on chain foot print.
Your signatures would be that "extra on chain foot print". In signet, by 
default you have 1-of-2 multisig, so you have one signature for every block. In 
the main chain, there is no need for any foot print, because you can reveal 
taproot public key and hide other things in tapscript, so your foot print is 
present only when people will not cooperate.
On 2021-12-20 18:18:58 user Billy Tetrud  wrote:
> you can assign some minimal difficulty,
 
I was assuming that would be part of the plan.
 
> Signing sounds more like Proof of Stake
 
Associating signing with proof of stake and thereby concluding that signing is 
something to avoid sounds like superstitious thinking. A signing scheme with 
proof of work would clearly not be proof of stake. I would suggest not 
dismissing a design out of hand like that. The benefit of that over merge 
mining would be no extra on chain foot print. What do you think the downsides 
might be?
 
> if you use just hashes, then they could be random.
 
You're right. Nodes would of course need to validate the Bitcoin block headers 
being included, so i concede hashing them doesn't gain you anything.
On Thu, Dec 16, 2021, 22:37  wrote:
> I was thinking that this would be a separate blockchain with separate headers 
> that progress linearly like a normal blockchain.
Exactly, that's what I called "superblocks", where you have a separate chain, 
just to keep block headers instead of transactions.
> A block creator would collect together as many blocks that haven't been 
> collected yet into the next superblock (and maybe receive a reward 
> proportional to how many / how much weight they include).
You cannot "catch them all". If you do, you can end up with a lot of block 
headers, where each of them has difficulty equal to one. You need some limit, 
you can limit amount of blocks, you can assign some minimal difficulty, it does 
not matter that much, but some limit is needed, also because mining on top of 
the latest superblock should be more profitable than replacing someone else's 
reward in the previous superblock by your own reward and getting a bigger share 
in the previous superblock.
> This could be done using merge mining, or it could be done using a signing 
> scheme (eg where the block creator signs to say "I created this superblock" 
> and have mechanisms to punish those who sign multiple superblocks at the same 
> height.
I would pick merge mining, because it is more compatible with existing mining 
scheme. Signing sounds more like Proof of Stake and I am trying to avoid that 
solution. Also, there is no need to sign anything, because you are solo mining 
where you have your own coinbase transaction or you are mining in a pool, where 
you have some shared address, and then you cannot produce any incompatible 
superblock, because the protocol can tell you, which address you should use 
(and if it is N-of-N taproot multisig and you have some closing transaction, 
then you can safely mine it).
> Really, you could even just use hashes of the block headers.
Replacing transactions with block headers will do the same trick. Each 
transaction is first hashed with double SHA-256, in exactly the same way as 
block headers are. If you replace transactions with block headers, you would 
get a superblock header, then varint saying how many block headers are there, 
and then you can place all block headers. During superblock merkle tree 
construction, you will hash all block headers (so you will get 

Re: [bitcoin-dev] [Bitcoin Advent Calendar] Review of Smart Contract Concepts

[Prayank via bitcoin-dev]

Hi Jeremy,

> This post covers some high-level smart contract concepts that different
opcodes or proposals could have (or not).
https://rubin.io/bitcoin/2021/12/04/advent-7/

Interesting post. I love the concept of recursion in programming. There is one 
Indian movie called 'Karthik calling Karthik' which is one of the ways I 
remember this concept. 

> Recursive is pretty much just a fancy way of saying “loops”. This is 
> sometimesalso called “Turing Complete”.

Recently asked one dumb question on Stakexchange after reading a comment on 
reddit, maybe you can add anything new in this:

https://bitcoin.stackexchange.com/questions/111337/loops-in-bitcoin-scripting

> Here, the contract terminates after one canceled request by moving the 
> coinelsewhere.  It’s possible to emulate recursive behavior a limited amount 
> by“unrolling” a loop.

I think this is what I did in the above link where for loop was replaced with 
if-else statements.

> However, unrolling has it’s limits. When choices(action A or B) are 
> introduced, unrolling can be less effective since you haveand exponential 
> blowup (that means unrolling even like 32 steps might be toomany). However, 
> there are some tricks that can be employed by a clever andcareful programmer 
> to reduce this complexity through, for example, memoization.

Agree with limits and possibility of optimization.

> The key difference being that in the fully enumerated case we must know the 
> exact specifics of the contract and how it will execute, and in the open 
> ended contract case there are bits and pieces we can dynamically specify. If 
> Alice is paid 1 BTC by December 25th, 2021 Midnight, then transfer 100 
> tokensto one of Bob’s Address B1, B2, or B3 at Bob’s discretion.

Interesting

> Signing the transaction fee rate as a function of locktime

TIL


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Bitcoin Advent Calendar] What's Smart about Smart Contracts

[Prayank via bitcoin-dev]

Hi Jeremy,

> Here's the day 6 post: https://rubin.io/bitcoin/2021/12/03/advent-6/, the
topic is why smart contracts (in extended form) may be a critical precursor
to securing Bitcoin's future rather than something we should do after
making the base layer more robust.

There are few comparisons in this post and links that I consider misleading or 
incomplete. I had already tweeted this but such discussions are better archived 
here:

Difference between Bitcoin and Ethereum that is not mentioned on the website 
which should be considered while looking at fees: 1. Size of blocks added to 
chain everyday (600 MB) 2. Block limit (500 MB per 10 mins) 3. UTXO vs Account 
model 4. Failed transactions that pay fees (50k per day) 5. Will these fancy 
smart contracts work without nodes? No. Where are these nodes running? AWS and 
Infura has nice articles to highlight their importance 6. Who is paying the 
fees? Stablecoins, DEX, NFT platforms, CEX and VCs

There can be lot of other differences that affect the fee market including lot 
of users in Bitcoin obsessed with supply and hodling. Things that have changed 
in last few years: 1. Darknet markets using Monero 2. Stablecoins stopped using 
Omni and lot of alternatives exist right now 3. Most of the transactions are 
related to exchanges. They have started using their own tokens, less exchanges 
support layer 2 for Bitcoin and users are forced to withdraw some altcoin even 
if they need bitcoin. 4. Newbies are reading influencers like Elon Musk and 
happy with their doggy coins to get rich quick/rekt. 5. Bitcoin users or 
influencers declared DeFi a scam and even sidechains like Liquid, Rootstock do 
not qualify their purity tests. Projects like DLCs are still not used in any 
projects with good volume.


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev