<unnamed>

Public Key

npub17w8rw3wtcr03zdsdjhmcj37w0g6l79gsspleltsznexdktv0qw0qd3nc05

Profile Code

nprofile1qqs08r3hgh9uphc3xcxetaufgl885d0lz5ggqlul4cpfunxm9k8s88sprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqtzgdlm

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:08:42 CEST

- reply

📅 Original date posted:2017-12-13
📝 Original message:Hey all,
I am proposing an informational BIP to standardize the term "bits". The
term has been around a while, but having some formal informational standard
helps give structure to how the term is used.
https://github.com/jimmysong/bips/blob/unit-bias/bip-unit-bias.mediawiki
Entire BIP included below (mediawiki format) for convenience.
Best,
Jimmy
----------
<pre>
BIP: ????
Title: Utilization of bits denomination
Author: Jimmy Song <jaejoon at gmail.com>
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2017-12-12
License: BSD-2-Clause
License-Code: BSD-2
</pre>
== Abstract ==
Bits is presented here as the standard term for 100 (one hundred) satoshis
or 1/1,000,000 (one one-millionth) of a bitcoin.
== Motivation ==
The bitcoin price has grown over the years and once the price is past
$10,000 USD or so, bitcoin amounts under $10 USD start having enough
decimal places that it's difficult to tell whether the user is off by a
factor of 10 or not. Switching the denomination to "bits" makes
comprehension easier. For example, when BTC is $15,000 USD, $10.50 is a
somewhat confusing 0.00067 BTC, versus 670 bits, which is a lot clearer.
Additonally, reverse comparisons are easier as 67 bits being $1 is easier
to comprehend for most people than 0.000067 BTC being $1. Similar
comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won
being 0.07 bits and so on.
Potential benefits of utilizing "bits" include:
# Reduce user error on small bitcoin amounts.
# Reduce unit bias for users that want a "whole" bitcoin.
# Allow easier comparisons of prices for most users.
# Allow easier bi-directional comparisons to fiat currencies.
# Allows all UTXO amounts to need at most 2 decimal places, which can be
easier to handle.
== Specification ==
Definition: 1 bit = 1/1,000,000 bitcoin.
Plural of "bit" is "bits". The terms "bit" and "bits" are not proper nouns
and thus should not be capitalized unless used at the start of a sentence,
etc.
All Bitcoin-denominated items are encouraged to also show the denomination
in bits, either as the default or as an option.
== Rationale ==
As bitcoin grows in price versus fiat currencies, it's important to give
users the ability to quickly and accurately calculate prices for
transactions, savings and other economic activities. "Bits" have been used
as a denomination within the Bitcoin ecosystem for some time. The idea of
this BIP is to formalize this name. Additionally, "bits" is likely the only
other denomination that will be needed for Bitcoin as 0.01 bit = 1 satoshi,
meaning that two decimal places will be sufficient to describe any current
utxo.
Existing terms used in bitcoin such as satoshi, milli-bitcoin (mBTC) and
bitcoin (BTC) do not conflict as they operate at different orders of
magnitude.
The term micro-bitcoin (µBTC) can continue to exist in tandem with the term
"bits".
== Backwards Compatibility ==
Software such as the Bitcoin Core GUI currently use the µBTC denomination
and can continue to do so. There is no obligation to switch to "bits".
== Copyright ==
This BIP is licensed under the BSD 2-clause license.
== Credit ==
It's hard to ascertain exactly who invented the term "bits", but the term
has been around for a while and the author of this BIP does not take any
credit for inventing the term.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171213/83d9a519/attachment.html>

2023-06-07 19:59:50 CEST

- reply

📅 Original date posted:2017-04-09
📝 Original message:Jorge,
Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.
I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.
Jimmy
> On 9 Apr 2017 12:26 am, "Jimmy Song" <jaejoon at gmail.com> wrote:
>
>> Jorge,
>>
>> Suppose someone figures out an ASIC optimization that's completely
>> unrelated that gives X% speed boost over your non-ASICBoosted
>> implementation. If you ban ASICBoost, someone with this optimization can
>> get 51% of the network by adding N machines with their new optimization. If
>> you allow ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>
>>> To be more specific, why "being higher will secure the Bitcoin network
>>> better against newer optimizations"?
>>> Or, to be more clear, let's forget about future "optimizations", let's
>>> just think of an attacker. Does asicboost being used by all miners
>>> make the system more secure against an attacker? No, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > Praxeology Guy,
>>> >
>>> >> Why would the actual end users of Bitcoin (the long term and short
>>> term
>>> >> owners of bitcoins) who run fully verifying nodes want to change
>>> Bitcoin
>>> >> policy in order to make their money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/f13e9088/attachment.html>

2023-06-07 19:59:50 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:Jorge,
Suppose someone figures out an ASIC optimization that's completely
unrelated that gives X% speed boost over your non-ASICBoosted
implementation. If you ban ASICBoost, someone with this optimization can
get 51% of the network by adding N machines with their new optimization. If
you allow ASICBoost and assuming this gets a 20% speed boost over
non-ASICBoosted hardware, someone with this optimization would need 1.2N
machines to get 51%. The network in that sense is 20% stronger against this
attack in terms of cost.
Jimmy
On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> To be more specific, why "being higher will secure the Bitcoin network
> better against newer optimizations"?
> Or, to be more clear, let's forget about future "optimizations", let's
> just think of an attacker. Does asicboost being used by all miners
> make the system more secure against an attacker? No, for the attacker
> can use asicboost too.
> What about the case when not all the miners are using asicboost? Then
> the attacker can actually get an advantage by suing asicboost.
>
> Sometimes people compare asicboost with the use of asics in general as
> both providing more security for the network and users. But I don't
> think this is accurate. The existence of sha256d asics makes an attack
> with general purpose computing hardware (or even more specialized
> architectures like gpgpu) much more expensive and unlikely. As an
> alternative the attacker can spend additional resources investing in
> asics himself (again, making many attacks more expensive and
> unlikely).
>
> But as far as I know, asicboost can be implemented with software
> running on general purpose hardware that integrates with regular
> sha256d asics. There is probably an advantage on having the asicboost
> implementation "in the same box" as the sha256d, yet again the
> attacker can invest in hardware with the competitive advantage from
> having asicboost more intergrated with the sha256d asics too.
>
> To reiterate, whether all miners use asicboost or only a subset of
> them, I remain unconvinced that provides any additional security to
> the network (to be more precise whether that makes "tx history harder
> to rewrite"), even if it results on the hashrate charts looking "more
> secure".
>
>
> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> >
> >
> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Praxeology Guy,
> >
> >> Why would the actual end users of Bitcoin (the long term and short term
> >> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> >> policy in order to make their money more vulnerable to 51% attack?
> >
> >
> > Certainly, if only one company made use of the extra nonce space, they
> would
> > have an advantage. But think of it this way, if some newer ASIC
> optimization
> > comes up, would you rather have a non-ASICBoosted hash rate to defend
> with
> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
> secure
> > the Bitcoin network better against newer optimizations.
> >
> >
> > Why?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/9e9e1ff3/attachment.html>

2023-06-07 19:59:48 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:Pavel,
> I agree. I only wanted to make clear, that the impact would be
> significant. Lot of parties would be involved with nonequivalent
> starting positions.
>
>
I agree with you. I believe nonequivalent starting positions are the norm
in mining, not the exception and hence don't believe this to be a problem.
>
> I think the ASICBoost can and should be prevented completely.
>
It certainly can be and from the responses I'm getting, I believe there
would be at least a few people that would enthusiastically support a BIP to
do that. That is, however, a separate issue than my proposal. My proposal
aims to bring ASICBoost out into the open *while it is still possible*. A
BIP to prevent ASICBoost completely is in that sense compatible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/06fbf04c/attachment.html>

2023-06-07 19:59:47 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:Pavel,
Until all miners update (firmware or hardware), the change encourages
> large difference in mining efficiency. And IMO it gives another
> advantage to large mining operations in general.
>
Certainly, there would have to be changes for stratum, pool software, etc.
But the monetary incentives align to all the changes needed.
Remember, overt ASICBoost can get something like a 12.5% efficiency boost
from toggling a single bit in the version (equivalent to 2 colliding work
items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4%
from 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf).
In lieu of an explicit allowance of overt ASICBoost, the monetary
incentives lead to odd BIP9 signaling, especially if 4 or more proposals
signal at once. There really isn't a practical way to block overt ASICBoost
without forcing the version bits to be some value.
In other words, the question isn't about allowing/disallowing ASICBoost at
this point. The question is whether we want ASICBoost open or hidden.
> You make a strong assumption that the new optimization is not
> compatible with overt ASICBoost. If it is compatible, ASICBoost
> doesn't help you with "defending against" the new optimization at all.
> And it can be the case that the new optimization is based on ASICBoost
> so you can make the situation "worse" by allowing it.
>
This would only be the case if overt ASICBoost were not possible at all. It
is currently possible to use overt ASICBoost, so optimizations based on
overt ASICBoost would also be possible unless something were done to
actively block it.
> Certainly, if only one company made use of the extra nonce space, they
> would have an advantage.
>
> Can you explain why the reality should be significantly different? In
> sufficiently near future.
Market incentives, I would imagine. How quickly that would be is not
something I'm qualified to answer.
> We don't have to deal with any such theoretical situation now. You
> proposal goes in opposite direction, by adding support for patented
> algorithm. I don't know myself what the possible legal implications
> are (maybe only for a subset of miners) so I consider it as an
> unnecessary risk. At least before some conclusive legal analysis says
> differently.
>
I'm not adding support as much as explicitly allowing what's implicitly
allowed. Whatever risks you imagine for this proposal exist on the network
currently, with unmodified BIP-141 and with modified BIP-141. The
difference in adding the modification is that overt ASICBoost is explicitly
allowed in the modified BIP-141 as to not hide it.
Jimmy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/14268b35/attachment.html>

2023-06-07 19:59:46 CEST

- reply

📅 Original date posted:2017-04-08
📝 Original message:>
> I think it might be important that the mandatory commitment expire as in
> Greg's proposal - when we do eventually hardfork, it will be simpler to do
> in
> a safe manner if such a commitment in the fake "old block" is not required.
>
OK, that makes sense. I'll modify my proposal this way:
Beginning block X and until block Y the coinbase transaction of
each block MUST contain a BIP-141 segwit commitment
> I don't like your proposal because it allows ASICBoost. ASICBoost
> effectively
> makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of
> entry to
> new mining chip manufacturers, and gives a larger advantage to the miners
> able
> to make use of it. Instead, IMO we should fix the vulnerability exploited
> by
> ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change
> the
> PoW to an algorithm that is more ASIC-friendly.
>
Overt ASICBoost is allowed on the network already. Until a proposal
explicitly blocking overt ASICBoost as a soft fork is activated, this seems
to be better than the current state which is that overt ASICBoost is
allowed, but at a cost to BIP9 signals.
Jimmy
> That being said, I don't think I would oppose the proposal if it gained
> notably better support than Segwit currently has (as yet another
> compromise),
> and the above concerns were addressed (eg, Bitfury and Canaan state they
> can
> compete using ASICBoost and the patents are licensed freely to everyone).
>
> Luke
>
>
> On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> > I've gotten feedback from Adam Back that you actually don't need all 32
> > bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
> > the 32-bit version field, bits 16 to 23 are reserved for miners, the
> > witness commitment stays as defined in BIP-141 except that it's now
> > required. BIP9 then is modified so that bits 16 to 23 are now no longer
> > usable.
> >
> > On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon at gmail.com> wrote:
> > > Hey everyone, This is an idea that I had about Segwit and Gregory's
> > > proposal from yesterday that I wanted to run by everyone on this list.
> > > I'm not at all sure what this would mean for non-upgraded nodes on the
> > > network and would like feedback on that. This is not a formal BIP as
> > > it's a modification to a previously submitted one, but I'm happy to
> > > formalize it if it would help.
> > > ----------------------------------------
> > > MotivationOne of the interesting aspects of Gregory Maxwell’s proposal
> is
> > > that it only precludes the covert version of ASICBoost. He specifically
> > > left the overt version alone.
> > >
> > > Overt ASICBoost requires grinding on the version bits of the Block
> header
> > > instead of the Merkle Root. This is likely more efficient than the
> Merkle
> > > Root grinding (aka covert ASICBoost) and requires way less resources
> > > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> > >
> > > If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add
> a
> > > slight modification, this should, in theory, make ASICBoost a lot more
> > > useful to miners and appeal to their financial interests.
> > > The Modification
> > >
> > > Currently, the version bits (currently 4 bytes, or 32 bits) in the
> header
> > > are used for BIP9 signaling. We change the version bits to a
> nonce-space
> > > so the miners can use it for overt ASICBoost. The 32-bits are now moved
> > > over to the Coinbase transaction as part of the witness commitment. The
> > > witness commitment goes from 38 bytes to 42 bytes, with the last 4
> bytes
> > > being used as the version bits in the block header previously. The
> > > witness commitment becomes required as per Gregory Maxwell’s proposal.
> > > Reasoning
> > >
> > > First, this brings ASICBoost out into the open. Covert ASICBoost
> becomes
> > > much more costly and overt ASICBoost is now encouraged.
> > >
> > > Second, we can make this change relatively quickly. Most of the Segwit
> > > testing stays valid and this change can be deployed relatively quickly.
> > >
> > > Note on SPV clients
> > >
> > > Currently Segwit stores the witness commitment in the Coinbase tx, so
> > > lightweight clients will need to get the Coinbase tx + Merkle proof to
> > > validate segwit transactions anyway. Putting block version information
> in
> > > the Coinbase tx will not impose an extra burden on upgraded light
> > > clients.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/0b4e08ad/attachment.html>

2023-06-07 19:59:45 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:Hey everyone, This is an idea that I had about Segwit and Gregory's
proposal from yesterday that I wanted to run by everyone on this list. I'm
not at all sure what this would mean for non-upgraded nodes on the network
and would like feedback on that. This is not a formal BIP as it's a
modification to a previously submitted one, but I'm happy to formalize it
if it would help.
----------------------------------------
MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
that it only precludes the covert version of ASICBoost. He specifically
left the overt version alone.
Overt ASICBoost requires grinding on the version bits of the Block header
instead of the Merkle Root. This is likely more efficient than the Merkle
Root grinding (aka covert ASICBoost) and requires way less resources (much
less RAM, SHA256 calculations, no tx shuffling, etc).
If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
slight modification, this should, in theory, make ASICBoost a lot more
useful to miners and appeal to their financial interests.
The Modification
Currently, the version bits (currently 4 bytes, or 32 bits) in the header
are used for BIP9 signaling. We change the version bits to a nonce-space so
the miners can use it for overt ASICBoost. The 32-bits are now moved over
to the Coinbase transaction as part of the witness commitment. The witness
commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
as the version bits in the block header previously. The witness commitment
becomes required as per Gregory Maxwell’s proposal.
Reasoning
First, this brings ASICBoost out into the open. Covert ASICBoost becomes
much more costly and overt ASICBoost is now encouraged.
Second, we can make this change relatively quickly. Most of the Segwit
testing stays valid and this change can be deployed relatively quickly.
Note on SPV clients
Currently Segwit stores the witness commitment in the Coinbase tx, so
lightweight clients will need to get the Coinbase tx + Merkle proof to
validate segwit transactions anyway. Putting block version information in
the Coinbase tx will not impose an extra burden on upgraded light clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/93c88127/attachment.html>

2023-06-07 19:59:45 CEST

- reply

📅 Original date posted:2017-04-07
📝 Original message:I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 then is modified so that bits 16 to 23 are now no longer
usable.
On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon at gmail.com> wrote:
> Hey everyone, This is an idea that I had about Segwit and Gregory's
> proposal from yesterday that I wanted to run by everyone on this list. I'm
> not at all sure what this would mean for non-upgraded nodes on the network
> and would like feedback on that. This is not a formal BIP as it's a
> modification to a previously submitted one, but I'm happy to formalize it
> if it would help.
> ----------------------------------------
> MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
> that it only precludes the covert version of ASICBoost. He specifically
> left the overt version alone.
>
> Overt ASICBoost requires grinding on the version bits of the Block header
> instead of the Merkle Root. This is likely more efficient than the Merkle
> Root grinding (aka covert ASICBoost) and requires way less resources
> (much less RAM, SHA256 calculations, no tx shuffling, etc).
>
> If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
> slight modification, this should, in theory, make ASICBoost a lot more
> useful to miners and appeal to their financial interests.
> The Modification
>
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space so
> the miners can use it for overt ASICBoost. The 32-bits are now moved over
> to the Coinbase transaction as part of the witness commitment. The witness
> commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
> as the version bits in the block header previously. The witness commitment
> becomes required as per Gregory Maxwell’s proposal.
> Reasoning
>
> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> much more costly and overt ASICBoost is now encouraged.
>
> Second, we can make this change relatively quickly. Most of the Segwit
> testing stays valid and this change can be deployed relatively quickly.
>
> Note on SPV clients
>
> Currently Segwit stores the witness commitment in the Coinbase tx, so
> lightweight clients will need to get the Coinbase tx + Merkle proof to
> validate segwit transactions anyway. Putting block version information in
> the Coinbase tx will not impose an extra burden on upgraded light clients.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/8f71b5b3/attachment.html>