Re: [bitcoin-dev] Block solving slowdown question/poll

[Dave Scotese via bitcoin-dev]

I believe this isn't something we need to address.  The fact is that every
byte stored in the blockchain is already valuable to everyone who downloads
the blockchain because of what it allows them to prove - by adding more
bytes to it.  Over time, the value per byte will increase.  Perhaps there
will be holding companies with specialized scripts that cost $500 - $1000
to add to the blockchain and allow those companies to handle transactions
for thousands of customers, kind of like a community lightning channel.

Anyway, yes, your idea is fundamentally broken because a zero block reward
happens because creating even one more satoshi will push the amount of
bitcoin over 21,000,, breaking the meaning of "bitcoin," or, if you
like, creating a fundamental contradiction in our use of the term.

On Mon, Mar 23, 2020 at 5:59 AM Andrew Cann  wrote:

> Hi, noob question here: Is there a long-term plan for if the block reward
> drops
> too low to ensure the security of the network?
>
> IIUC miners only make profit from block rewards and transaction fees, and
> once
> the block reward drop to zero we're merely hoping that transaction fees
> will
> keep mining expensive enough to stop a state actor or someone from buying
> enough hash power to attack the network. If that's the case, should we
> start
> making plans now to change the protocol to allow an adjustable block
> reward?
>
> Here's a half-baked idea I had of how that could work: Since the block
> reward
> dilutes the value of the currency bitcoin holders have an incentive to
> keep the
> reward low. However, since the block reward is also (partly) what
> incentivizes
> mining, bitcoin holders also have an incentive to keep the reward high
> enough
> to keep the network secure. So if bitcoin holders were able to vote to
> decide
> the block reward they "should", hypothetically, reliably choose a value
> that
> balances these two concerns. You could implement this voting by adding an
> optional extra field to every txout that signals what the holder thinks the
> inflation rate should be. If the field is missing you just assume the
> default
> value based on the current protocol. Then, whenever a new block is mined,
> you
> take the median inflation rate of all the pre-existing utxos, weighted by
> the
> utxo value, to calculate the block's reward.
>
> Is this idea fundamentally broken somehow? Or are there already better
> ideas
> for how to tackle this problem (I don't follow this list very closely)? Or
> is
> this actually a non-issue to start with?
>
>  - Andrew
>
>

-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

[Dustin Dettmer via bitcoin-dev]

Excellent write up, thanks for putting it together.

On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:

> When both the HW and the SW are compromised, clearly no security is
> possible,
> as all entities are controlled by the same party in that case.
>
While all SW being compromised can’t be stopped, splitting the SW over two
stages can dramatically increase your security if both HW & SW are
compromised. You can do that by:

1) When you setup your storage solution (whatever it may be), export the
xpub(s) and verify the receiving addresses match xpubs with external
software before receiving.
2) Generate and export withdrawal transactions offline
3) Verify transactions against the same xpub(s) using external software
4) Upload transactions

This mitigates, I believe, all leak vectors besides k/R hacking and
prechosen entropy.

I made an external tool to just that here:
https://github.com/koinkeep/gatekeeper

Would love to add k commitments when (if?) we settle on best practices for
it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev