<unnamed>

Public Key

npub1287e20y3ple0k202xuas3h9h0yfx6ravfxcycd9jauan8cne9pusj45an7

Profile Code

nprofile1qqs9rlv48jgsluhm984rwwcgmjmhjyndp7kynvzvxjew7wenufujs7gpzpmhxue69uhkummnw3ezuamfdejsjd5hj6

Publishing to

nostr.wine

Last Notes

2023-06-08 01:08:23 CEST

- reply

📅 Original date posted:2022-04-27
📝 Original message:>> we should not let the wealthy make consensus decisions.
>We shouldn't let the wealthy continue to control our governments. However,
bitcoin is not a government. Its a financial network.
>The fact of the matter is that fundamentally, the economic majority
controls where the chain goes. Its very likely that the wealthy
>are disproportionately represented in the economic majority. Attempting to
subvert the economic majority seems like a bad idea.
>The reality of control there will come out one way or another, and being
honest about it is probably the best way to avoid major schisms in the
future.
Yes, the economic majority is important: Who else has more incentive to
protect the security and thus the value embodied in the network than people
who have invested money and time in the network? A group of people with
1/10/100/1000 bitcoins each has more economic incentive to do so than a
similar sized group with 1/10/100/1000 satoshis each. Likewise, it is
significantly easier to mobilize 1 million people "voting" with 100
satoshis each - a total of 1 BTC - vs 10000 people each voting with 100
bitcoins each - a total of 1 million BTC. I don't think anyone would say
that even if those 1 million people, for example, thought that we should
increase the number of bitcoins via perpetual inflation it would be a good
idea to listen to it however the vote was done whether via transaction
flags or something else. Of course they could fork off.
Cheers, :-)
Chris
On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
>
> I feel like I've heard this idea somewhere before. Its an interesting
> idea.
>
> It should be noted that there is a consequence of this: holders wouldn't
> have much say. People that transact a lot (or happen to be transacting a
> lot during the signaling time period) would have a very disproportionate
> ability to pressure miners than people who aren't transacting much. This
> would probably be a pretty good proxy for future mining revenue that
> supports (or is against) a particular thing. However, the network does do
> more than just transact, so I would be a bit worried that such a mechanism
> would bias the system towards things that are good for transactors and bad
> for holders. Things like more coin inflation, larger blocks, etc.
>
> Another consideration is that miners are already incentivized to follow
> the money here. Adding an *additional* incentive might be distorting the
> market, so to speak.
>
> An alternative I proposed was a way to do weighted polling of holders:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html
>
> The polling wouldn't be directly connected to the activation mechanism in
> any way, but would just be a mechanism to gauge some portion of consensus.
> If enough people were involved, theoretically it could be hooked up to
> activation, but I would be pretty wary of doing that directly as well.
>
> > we should not let the wealthy make consensus decisions.
>
> We shouldn't let the wealthy continue to control our governments. However,
> bitcoin is not a government. Its a financial network. The fact of the
> matter is that fundamentally, the economic majority controls where the
> chain goes. Its very likely that the wealthy are disproportionately
> represented in the economic majority. Attempting to subvert the economic
> majority seems like a bad idea. The reality of control there will come out
> one way or another, and being honest about it is probably the best way to
> avoid major schisms in the future.
>
> > Does a scheme like this afford us a better view into consensus than we
> have today?
>
> It does more than provide a view. It directly changes the game theory
> around how activation works. If we wanted to simply get a better view into
> consensus, we could allow the same thing, but allow any block to mine any
> transaction regardless of transaction signaling. Then it would be more
> purely informational.
>
> > Can it be gamed to give us a *worse* view into consensus? How?
> > Does it measure the right thing? If not, what do you think is the right
> thing to measure?
>
> Doesn't seem like it could be gamed, but as I mentioned above, the honest
> mechanics of it might be themselves undesirably distorting.
>
>
>
> On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> You may be interested in these posts on transaction signalling:
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>>
>>
>> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Alongside the debate with CTV right now there's a second debate that was
>>> not fully hashed out in the activation of Taproot. There is a lot of
>>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>>> etc. A significant reason for the breakdown in civility around this debate
>>> is that because we don't have a means of measuring user support for
>>> proposed sof-fork changes, it invariably devolves into people claiming that
>>> their circles support/reject a proposal, AND that their circles are more
>>> broadly representative of the set of Bitcoin users as a whole.
>>>
>>> It seems everyone in this forum has at one point or another said "I
>>> would support activation of ____ if there was consensus on it, but there
>>> isn't". This statement, in order to be true, requires that there exist a
>>> set of conditions that would convince you that there is consensus. People
>>> have tried to dodge this question by saying "it's obvious", but the reality
>>> is that it fundamentally isn't. My bubble has a different "obvious" answer
>>> than any of yours.
>>>
>>> Secondly, due to the trauma of the block size wars, no one wants to
>>> utter a statement that could imply that miners have any influence over what
>>> rulesets get activated or don't. As such "miner signaling" is consistently
>>> devalued as a signal for market demand. I don't think this is reasonable
>>> since following the events of '17 miners are aware that they have the
>>> strong incentive that they understand market demand. Nevertheless, as it
>>> stands right now the only signal we have to work with is miner signaling,
>>> which I think is rightly frustrating to a lot of people.
>>>
>>> So how can we measure User Support for a proposed rule change?
>>>
>>> I've had this idea floating around in the back of my head for a while,
>>> and I'd like to solicit some feedback here. Currently, all forms of
>>> activation that are under consideration involve miner signaling in one form
>>> or another. What if we could make it such that users could more directly
>>> pressure miners to act on their behalf? After all, if miners are but the
>>> humble servants of user demands, this should be in alignment with how
>>> people want Bitcoin to behave.
>>>
>>> Currently, the only means users have of influencing miner decisions are
>>> A. rejection of blocks that don't follow rules and B. paying fees for
>>> transaction inclusion. I suggest we combine these in such a way that
>>> transactions themselves can signal for upgrade. I believe (though am not
>>> certain) that there are "free" bits in the version field of a transaction
>>> that are presently ignored. If we could devise a mapping between some of
>>> those free bits, and the signaling bits in the block header, it would be
>>> possible to have rules as follows:
>>>
>>> - A transaction signaling in the affirmative MUST NOT be included in a
>>> block that does not signal in the affirmative
>>> - A transaction that is NOT signaling MAY be included in a block
>>> regardless of that block's signaling vector
>>> - (Optional) A transaction signaling in the negative MUST NOT be
>>> included in a block that signals in the affirmative
>>>
>>> Under this set of conditions, a user has the means of sybil-resistant
>>> influence over miner decisions. If a miner cannot collect the fees for a
>>> transaction without signaling, the user's fee becomes active economic
>>> pressure for the miner to signal (or not, if we include some variant of the
>>> negative clause). In this environment, miners could have a better view into
>>> what users do want, as would the Bitcoin network at large.
>>>
>>> Some may take issue with the idea that people can pay for the outcome
>>> they want and may try to compare a method like this to Proof of Stake, but
>>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>>> view into what social consensus looks like MUST be sybil resistant:
>>>
>>> - Hashpower
>>> - Proof of personhood (KYC)
>>> - Capital burn/risk
>>>
>>> Letting hashpower decide this is the thing that is currently
>>> contentious, KYC is dead on arrival both on technical and social grounds,
>>> which really just leaves some means of getting capital into the process of
>>> consensus measurement. This mechanism I'm proposing is measurable
>>> completely en-protocol and doesn't require trust in institutions that fork
>>> futures would. Additionally it could be an auxiliary feature of the soft
>>> fork deployment scheme chosen making it something you could neatly package
>>> all together with the deployment itself.
>>>
>>> There are many potential tweaks to the design I propose above:
>>> 1. Do we include a notion of negative signaling (allowing for the
>>> possibility of rejection)
>>> 2. Do we make it such that miner signaling must be congruent with >X% of
>>> transactions, where congruence is that the signal must match any
>>> non-neutral signal of transaction.
>>>
>>> Some anticipated objections:
>>>
>>> 1. signaling isn't voting, no deployment should be made without
>>> consensus first.
>>> - yeah well we can't currently measure consensus right now, so that's
>>> not a super helpful thing to say and is breeding ground for abuse in the
>>> form of certain people making the unsubstantiated claim that consensus does
>>> or does not exist for a particular initiative
>>>
>>> 2. This is just a proposal for "pay to play", we should not let the
>>> wealthy make consensus decisions.
>>> - I agree that wealth should not be able to strong-arm decision making.
>>> But the status quo seems even worse where we let publicly influential
>>> people decide consensus in such a way where not only do they not "lose
>>> ammunition" in the process of campaigning, but actually accrue it, creating
>>> really bad long-term balances of power.
>>>
>>> 3. Enforcing this proposal requires its own soft fork.
>>> - Yes. It does...and there's a certain cosmic irony to that, but before
>>> we consider how to make this happen, I'd like to even discuss whether or
>>> not it's a good idea.
>>>
>>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>>> power over deciding consensus.
>>> - I see this as an improvement over the status quo
>>>
>>> 5. This encourages "spam"
>>> - If you pay the fees, it's not spam.
>>>
>>> The biggest question I'd like to pose to the forum is:
>>> - Does a scheme like this afford us a better view into consensus than we
>>> have today?
>>> - Can it be gamed to give us a *worse* view into consensus? How?
>>> - Does it measure the right thing? If not, what do you think is the
>>> right thing to measure? (assuming we could)
>>> - Should I write a BIP spec'ing this out in detail?
>>>
>>> Cheers,
>>> Keagan
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/815a5da9/attachment-0001.html>

2023-06-07 20:04:55 CEST

- reply

📅 Original date posted:2017-08-22
📝 Original message:The initial message I replied to stated in part, "Okay so I quite like this
idea. If we start removing at height 630000 or 840000 (gives us 4-8 years
to develop this solution), it stays nice and neat with the halving
interval...."
That is less than 3 years or less than 7 years away. Much sooner than it
is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as
to require that early coins start getting "scavenged" at that date seems
unneeded and irresponsible. Besides, your ECDSA is only revealed when you
spend the coins which does provide some quantum resistance. Hal was just
an example of people putting their coins away expecting them to be there at
X years in the future, whether it is for himself or for his kids and wife.
:-)
On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton at gmail.com>
wrote:
> Very true, if Moore's law is still functional in 200 years, computers will
> be 2^100 times faster (possibly more if quantum computing becomes
> commonplace), and so old wallets may be easily cracked.
>
> We will need a way to force people to use newer, higher security wallets,
> and turning coins to mining rewards is better solution than them just being
> hacked.
>
> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
>
>> In any case when Hal Finney do not wake up from his 200years
>> cryo-preservation (because unfortunately for him 200 years earlier they did
>> not know how to preserve a body well enough to resurrect it) he would find
>> that advance in computer technology made it trivial for anyone to steal his
>> coins using the long-obsolete secp256k1 ec curve (which was done long
>> before, as soon as it became profitable to crack down the huge stash of
>> coins stale in the early blocks)
>>
>> I just don't get that argument that you can't be "your own bank". The
>> only requirement coming from this would be to move your coins about once
>> every 10 years or so, which you should be able to do if you have your
>> private keys (you should!). You say it may be something to consider when
>> computer breakthroughs makes old outputs vulnerable, but I say it's not
>> "if" but "when" it happens, and by telling firsthand people that their
>> coins requires moving every once in a long while you ensure they won't do
>> stupid things or come back 50 years from now and complain their addresses
>> have been scavenged.
>>
>> --
>> Thomas
>>
>>
>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>
>> I agree, it is only a good idea in the event of a quantum computing
>> threat to the security of Bitcoin.
>>
>> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> This seems to be drifting off into alt-coin discussion. The idea that
>>> we can change the rules and steal coins at a later date because they are
>>> "stale" or someone is "hoarding" is antithetical to one of the points of
>>> bitcoin in that you can no longer control your own money ("be your own
>>> bank") because someone can at a later date take your coins for some reason
>>> that is outside your control and solely based on some rationalization by a
>>> third party. Once the rule is established that there are valid reasons why
>>> someone should not have control of their own bitcoins, what other reasons
>>> will then be determined to be valid?
>>>
>>> I can imagine Hal Finney being revived (he was cryo-preserved at Alcor
>>> if you aren't aware) after 100 or 200 years expecting his coins to be there
>>> only to find out that his coins were deemed "stale" so were "reclaimed" (in
>>> the current doublespeak - e.g. stolen or confiscated). Or perhaps he
>>> locked some for his children and they are found to be "stale" before they
>>> are available. He said in March 2013, "I think they're safe enough" stored
>>> in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
>>>
>>> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
>>> in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
>>> times since 2010 and still do not agree with the rational that embracing
>>> allowing someone to steal someone else's coins for any reason is a useful
>>> change to bitcoin.
>>>
>>>
>>>
>>>
>>> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Okay so I quite like this idea. If we start removing at height 630000
>>>> or 840000 (gives us 4-8 years to develop this solution), it stays nice and
>>>> neat with the halving interval. We can look at this like so:
>>>>
>>>> B - the current block number
>>>> P - how many blocks behind current the coin burning block is. (630000,
>>>> 840000, or otherwise.)
>>>>
>>>> Every time we mine a new block, we go to block (B-P), and check for
>>>> stale coins. These coins get burnt up and pooled into block B's miner fees.
>>>> This keeps the mining rewards up in the long term, people are less likely
>>>> to stop mining due to too low fees. It also encourages people to keep
>>>> moving their money around the enconomy instead of just hording and leaving
>>>> it.
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/b9c37929/attachment.html>

2023-06-07 20:04:54 CEST

- reply

📅 Original date posted:2017-08-22
📝 Original message:This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
since 2010 and still do not agree with the rational that embracing allowing
someone to steal someone else's coins for any reason is a useful change to
bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Okay so I quite like this idea. If we start removing at height 630000 or
> 840000 (gives us 4-8 years to develop this solution), it stays nice and
> neat with the halving interval. We can look at this like so:
>
> B - the current block number
> P - how many blocks behind current the coin burning block is. (630000,
> 840000, or otherwise.)
>
> Every time we mine a new block, we go to block (B-P), and check for stale
> coins. These coins get burnt up and pooled into block B's miner fees. This
> keeps the mining rewards up in the long term, people are less likely to
> stop mining due to too low fees. It also encourages people to keep moving
> their money around the enconomy instead of just hording and leaving it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/0237425a/attachment.html>

2023-06-07 19:50:34 CEST

- reply

📅 Original date posted:2016-05-10
📝 Original message:The second like "2)" has a link to the paper:
http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
which does discuss the fact that it is "patent-pending". Likewise it
discusses ASIC improvements. Avoiding patents that impact bitcoin and are
not freely licensed, is something that is worthwhile for discussion.
On Tue, May 10, 2016 at 6:17 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Tue, May 10, 2016 at 3:57 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like to
>> make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>>
>> You say that you want to make patented optimization useless, but you
> point to a link that doesn't say anything about ASIC improvements or
> patents, which means that you have been planning to change the protocol
> rules with some miners (but not all the community).
>
> All changes to the protocol should be discussed in public here. If you
> want to make "further similar optimizations useless as well" then maybe you
> should propose a switch to EquiHash.
>
>
>
>>
>> 1)
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>>
>> 2)
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/cd50e919/attachment.html>