>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?
On Sun, Mar 10, 2019
>The problem will be to come up with an address authentication
procedure that will be convenient for users and widely supported, as a
result.
You could locally hash the destination address and from the hash derive a
BIP39 style list of 12 words for visual comparison. I would advise against
using c
Thank you, and my apologies. I should have sent that link just to you and
not put everyone on cc.
On Fri, Sep 14, 2018 at 1:30 PM Andrew wrote:
> (reposting to whole list instead of just him) @Moral Agent:
> Interesting proposal though it introduces some elements
> of proof of stake so it would
You might be interested in an idea I wrote about that is in a similar
spirit here:
https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
>From the article:
When a block is solved, it randomly selects one satoshi from the utxo set
and gives whomever controls that satosh
As you point out, depending on the mempool, sometimes a miner makes more
fee by including A and B, while other times a miner makes more fee by
including C (the replacement for A and B) and D (a hypothetical transaction
that cannot be fit into a block that contains A and B but can be fit into a
bloc
Another way to limit abuse would be to have the fee *rate* be required to
increase, which is kind of the spirit of RBF, applied to this situation.
That is to say, if you wished to replace transactions A and B with C which
spends the same inputs as A and B, then the following must be true before C
Along the same lines, I wonder if unrelated people with tx that are not
confirming could cooperate to merge their disparate tx into a CoinJoin tx
with a higher fee rate?
Perhaps they could even replace old tx with economically equivalent summary
transactions?
The mempool seems like nature's accum
>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct<
approach. It's tidy, systematic and precise.
The SI system is great, but it's nice if you pick a base unit that is easy
for intuition to comprehend.
It is a fact that I weigh approximately .000,000,000,000,000,000,000,01
avatar? Any small change to the text
> input produces a significantly different image.
>
> -Danny
>
> On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If you are going to rely on human verification o
If you are going to rely on human verification of addresses, the best way
might be map it to words.
For example, with a 6000 word list, a 25 byte address (with a checksum)
could be mapped to 16 words like this:
vocally acquireremoved unfounded
euphemismsanctuarysecti
>Instead of there being one altcoin fighting to take hashpower from
bitcoin, there’d now be 2
Yes, there would be 2. One of which would (in the scenario we are
discussing) be producing blocks excruciatingly slowly but be the same in
all other aspects.
>changing the difficulty adjustment algorithm
A more forgiving option would be to have coins past a certain age evaporate
into mining rewards at some rate, rather than all at once. People might
find this approach easier to stomach as it avoids the "I waited 1 block to
many and all of my coins vanished" scenario.
Another approach would to dema
If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.
Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transacti
>Miners who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not. Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.
Here is the text of a post to reddit from Feb 2017, discussing a similar
idea, and wondering if it could reduce the incentive to delay broadcast of
solved blocks:
# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain
# Steps:
1. Soft fork Bitcoin to enable side chains
2. Cr
It would be nice if the detached signer and the normal wallet could both
verify the correctness of generated addresses before you cause coins to be
sent there.
e.g. the hardware wallet could give its master public key to Bitcoin Core
and you can thereafter generate your receiving addresses on Core
If there is concern about the
block-with-valid-header-but-invalid-transactions-spam-attack, I have a
strategy using sync flags that may drastically reduce the problem.
Sync flags documented here:
https://github.com/moral-agent/sync_flags/blob/master/README.md)
The strategy to defeat the above at
locks
> from now will be.
>
>
> On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
> wrote:
> > I posted this to /r/bitcoin yesterday but it got minimal comments. One
> uses
> > suggested I try the mailing list so here it is:
> >
> > The idea pres
I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
suggested I try the mailing list so here it is:
The idea presented here could have the following benefits:
1. Improve mining decentralization
2. Reduce variance in mining profitability
3. Reduce or eliminate SPV mined blo
19 matches
Mail list logo
