[bitcoin-dev] Bitcoin Knots "Steel Rope" LTS 21.2.knots20210629 released

[Luke Dashjr via bitcoin-dev]

Bitcoin Knots version 21.2.knots20210629 is now available from:

  https://bitcoinknots.org/files/21.x/21.2.knots20210629/

This Long Term Support (LTS) "Steel Rope" release is based on the unchanged
Bitcoin Knots feature set from 2021 June 29th, with only bug fixes and updated
translations.

Please report bugs using the issue tracker at GitHub:

  https://github.com/bitcoinknots/bitcoin/issues

To receive security and update notifications, please subscribe to:

  https://bitcoinknots.org/list/announcements/join/

For the full release notes and change log, see:

https://github.com/bitcoinknots/bitcoin/blob/v21.2.knots20210629/doc/release-notes.md


signature.asc
Description: This is a digitally signed message part.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Bitcoin Advent Calendar] Part One: Implementing NFTs in Sapio

[Jeremy via bitcoin-dev]

I know NFTs are controversial, but here's my take on them in Sapio:

https://rubin.io/bitcoin/2021/12/16/advent-19/

If you don't like NFTs, don't worry: the results and techniques are
entirely generalizable here and can apply to many other types of things
that aren't stupid JPGs.

E.g.,

- If you squint, Lightning Channels are NFTs: I have a channel with someone
and I can't transfer it to a third party fungibly because both the
remaining side and entering side want to know about the counterparty
reputation.
- DLCs are NFTs because I want to know not just counterparties, but also
which oracles.
- Colored Coins/Tokens, definitionally, are not NFTs, but fractional shares
of an NFT are Colored Coins, so NFT research might yield new results for
Colored Coins.

Advancing the state of the art for NFTs advances the state of the art for
all sorts of other purposes, while letting us have a little fun. This is a
strong callback to https://rubin.io/bitcoin/2021/12/14/advent-17/ and
https://rubin.io/bitcoin/2021/12/03/advent-6/ if you want to read more on
why things like NFTs are cool even if JPGs are lame.

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] Decentralized Coordination Free Mining Pools

[Jeremy via bitcoin-dev]

high level response:

including a small number of block headers (10?) directly as op_return
metadata (or something) doesn't have that high overhead necessarily, but
could be super effective at helping miners participate with lower hashrate.
the reason to include this as on-chain data is so that the mining pool
doesn't require any external network software.

this would balance out the issues if the data is somewhat bounded (e.g., 10
headers). what's nice is this data has no consensus meaning as it's client
side validated by the DCFMP block filter.

interestingly, the participating pools could 'vote' on how difficult shares
should be as a metaparameter to the pool over blocks... but analysis gets
more complex with that.

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 Coordination Free Mining Pools

[Billy Tetrud via bitcoin-dev]

@Jeremy
>   for top-level pool participants there is never any central custody.

I definitely see that. That was actually what I meant when I said the goals
aren't the same as benefits. While your idea definitely satisfies all your
goals in a modular way, the fact that it relies on pools means that unless
the pools can also satisfy the goals, the total system also doesn't satisfy
the goals (even tho the piece of that system you designed does).

> Thus it doesn't "hurt" anyone except for the miners who are taking the
not fully locked in funds risk

True, it only potentially hurts whoever the channel partner is accepting
the unspendable coins. And no one can really stop anyone from taking that
risk if they really want to. But in that case, its not exactly a fully
functional channel, since recourse mechanisms couldn't be performed.
Wouldn't that open such a channel up to a pretty bad theft possibility?

@Bob
> Increased payout regularity does not lower the viable size of mining
pools, because smaller mining pools using this mechanism still have higher
variance.

Yes, smaller mining pools will always have higher variance. However, lower
variance has diminishing benefits. Below a certain amount of variance, less
variance isn't very valuable. So increased payout regularity does indeed
lower the viable size of mining pools because a given low-enough level of
variance can be achieved with less pool hashpower.

> The on-chain footprint is *higher* due to the increased payout regularity.

That's a reasonable point. However, I think there is a difference here
between the regularity of rewards vs payouts. Rewards for each miner can be
more regular without necessarily increasing the number of on-chain payouts.
In fact, theoretically, an individual miner could let their rewards
accumulate in a pool over many rewards and only redeem when they need the
coins for something. The incentive is there for each miner to be judicious
on how much onchain space they take up.

@vjudeu

> how many block headers should be stored per one "superblock"?

I was thinking that this would be a separate blockchain with separate
headers that progress linearly like a normal blockchain. 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). 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. For merge mining, I could
even imagine the data necessary to validate that it has been merge mined
could be put into a taproot script branch (creating an invalid script, but
a valid hash of the superblock).

> we can collect all headers with the same previous block hash, and
distribute block reward between all coinbase transactions in those headers

Exactly.

> we would just have block headers instead of transactions

Yeah, I think that would be the way to go. Really, you could even just use
hashes of the block headers. But the size doesn't matter much because it
would be both a small blockchain and an ephemeral one (which can be fully
discarded after all parties have been paid out, or at least their payout
has been committed to on the bitcoin blockchain).

On Thu, Dec 16, 2021 at 1:35 AM  wrote:

> > The missing piece here would be an ordering of weak blocks to make the
> window possible. Or at least a way to determine what blocks should
> definitely be part of a particular block's pay out. I could see this being
> done by a separate ephemeral blockchain (which starts fresh after each
> Bitcoin block) that keeps track of which weak blocks have been submitted,
> potentially using the pow already in each block to secure it. Granted that
> piece is a bit half baked, but it seems quite solvable. Wdyt?
>
> I thought about something like that, but there is one problem: how many
> block headers should be stored per one "superblock"? Currently, we have
> single block header, where the whole coinbase transaction is taken by some
> mining pool or solo miner. But instead, each miner could submit its own
> block header. Then, we can collect all headers with the same previous block
> hash, and distribute block reward between all coinbase transactions in
> those headers. One "superblock" then would be created in a similar way as
> existing blocks, we would just have block headers instead of transactions.
> If most transactions inside those blocks will be the same, then each block
> could be expressed just as a set of transaction hashes, only coinbase
> transactions or custom, non-broadcasted transactions included by miners
> will be revealed, everything else will be known.
>
> > One thing that jumped out at me as not safe is throwing block rewards
> into a channel and being able to spend them immediately. There's a reason
> block rewards aren't spend

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

[vjudeu via bitcoin-dev]

> The missing piece here would be an ordering of weak blocks to make the window 
> possible. Or at least a way to determine what blocks should definitely be 
> part of a particular block's pay out. I could see this being done by a 
> separate ephemeral blockchain (which starts fresh after each Bitcoin block) 
> that keeps track of which weak blocks have been submitted, potentially using 
> the pow already in each block to secure it. Granted that piece is a bit half 
> baked, but it seems quite solvable. Wdyt?
 
I thought about something like that, but there is one problem: how many block 
headers should be stored per one "superblock"? Currently, we have single block 
header, where the whole coinbase transaction is taken by some mining pool or 
solo miner. But instead, each miner could submit its own block header. Then, we 
can collect all headers with the same previous block hash, and distribute block 
reward between all coinbase transactions in those headers. One "superblock" 
then would be created in a similar way as existing blocks, we would just have 
block headers instead of transactions. If most transactions inside those blocks 
will be the same, then each block could be expressed just as a set of 
transaction hashes, only coinbase transactions or custom, non-broadcasted 
transactions included by miners will be revealed, everything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards into a 
> channel and being able to spend them immediately. There's a reason block 
> rewards aren't spendable for a while, and channels don't solve that problem, 
> do they? Why not simply reduce the on chain wait time for spending block 
> rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by 
consensus. It does not matter if there are outputs owned directly by miners, or 
if there is one huge N-of-N taproot multisig for the whole pool, where every 
miner signed the closing transaction. The only option to take coins faster I 
can see is swapping the coins by some LN transaction. But then, the other party 
can check if some deposit to the LN channel is a part of the coinbase 
transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev 
 wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the 
goals you mentioned. As you do mention, this mining pool coordination doesn't 
get rid of the need for mining pools in the first place. So it doesn't satisfy 
item 1 on your goal list afaict.   
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pools, 
and
2. Lower on chain footprint through combining pay outs from multiple pools.
 
Am I missing some?
 
These are interesting benefits, but it would be nice if your post was clearer 
on that, since the goals list is not the same as the list of potential benefits 
of this kind of design.
 
As far as enabling solo mining, what if this concept were used off chain? Have 
a public network of solo miners who publish "weak blocks" to that network, and 
the next 100 (or 1000 etc) nice miners pay you out as long as you're also being 
nice by following the protocol? All the nice optimizations you mentioned about 
eg combined taproot payouts would apply i think. The only goals this wouldn't 
satisfy are 3 and 5 since an extra network is needed, but to be fair, your 
proposal requires pools which all need their own extra network anyways. 
 
The missing piece here would be an ordering of weak blocks to make the window 
possible. Or at least a way to determine what blocks should definitely be part 
of a particular block's pay out. I could see this being done by a separate 
ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps 
track of which weak blocks have been submitted, potentially using the pow 
already in each block to secure it. Granted that piece is a bit half baked, but 
it seems quite solvable. Wdyt?
 
One thing that jumped out at me as not safe is throwing block rewards into a 
channel and being able to spend them immediately. There's a reason block 
rewards aren't spendable for a while, and channels don't solve that problem, do 
they? Why not simply reduce the on chain wait time for spending block rewards 
at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev 
 wrote:
You are hand waving. Attempting to redefine terms to justify your argument is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashrate.
Various suggestions below introduce dangerous new games that might be played by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You