[bitcoin-dev] PSBT global key for network

[Jimmy Song via bitcoin-dev]

Hey all,

I wanted to propose a new key in the global context for BIP174,
Partially-Signed Bitcoin Transactions.

= Rationale

Each signer should make sure that the inputs being referenced in the PSBT
exist (with the exception of a Proof-of-Reserves input). In order to do
this, it's critical to know which network the coins are on (mainnet or
testnet). This could potentially be extended to other networks should they
want to use something like PSBT, much in the same way that HD keys from
BIP0044 reserved 0' and 1' as coins for mainnet Bitcoin and testnet Bitcoin
respectively.

= Proposal

Add the key 0x03 for network in the global key-value store. Value is a
variable integer with 0x00 indicating Bitcoin mainnet and 0x01 indicating
Bitcoin testnet. Other coins that want to use the PSBT should use the coin
network number from SLIP-0044 with the high bit removed.

---

Best,

Jimmy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

[Jimmy Song via bitcoin-dev]

Hi Russell,

This is probably a dumb question, but I'd like to get some clarity on your
proposal.

OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.
Presumably, the message would then have to get constructed as part of the
Script execution. What would such a message look like? What, in other
words, would you be signing and would that be similar to what signatures
sign now? Would it be a single blob that incorporates all the input/output
information in some hashed manner (like BIP143)? Or would you need separate
signatures for different parts of the transaction? Or is it something more
complicated like aggregating multiple signatures over different parts of
the transaction?

Best,

Jimmy

On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
> OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
> Bitcoin via new Script operations.  However, I think that these proposals
> miss the mark when it comes to how they approach Bitcoin Script and
> language features.
>
> Bitcoin Script appears designed to be a flexible programmable system that
> provides generic features to be composed to achieve various purposes.
> Thus, when we design new language features for Script, we should be
> striving, as much as possible, to similarly build general purpose tools
> which can in turn be used for a variety of purposes.
>
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail
> to achieve these design goals.  They are both are designed with very narrow
> applications in mind, while also going out of their way to extend the
> semantic domain of the interpretation of Bitcoin operations in new ways
> that complicate their specification.  In the case of SIGHASH_ANYPREVOUT,
> the semantic domain is extended by adding new counters to track the use of
> various v0 and v2 signature types.  In the case of
> OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that
> peeks at the value of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT
> and OP_CHECKSIGFROMSTACKVERIFY.  OP_CAT pops two byte arrays off the stack
> and pushes their concatenation back onto the stack.
> OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the
> stack and performs a bip-schnorr verification on the SHA256 hash of the
> message.
>
> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure
> Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply
> by the nature of the construction.
> + Decide if a transaction has exactly one input or not. (etc.)
> + Weak covenants, which can verify output scripts to see if they are among
> a set of predefined values or verify the output hash.
>
> and presumably more applications as well.
>
> For better or for worse, without an OP_PUBKEYTWEEK operation available,
> the more interesting recursive-covenants remain largely out of reach, with
> the exception of a recursive covenant that is only able to send back to its
> own address, possibly abusing its own TXO value as a state variable.
>
> All this is accomplished by two straightforward opcodes whose semantics
> are pure computational operations on stack values.  The only semantic
> side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the
> existing 'sigops_passed' count.  Moreover, I feel that adding these
> operations does not preclude adding more specialized opcodes in the future
> as an optimization for whatever popular constructions come up, once we know
> what those are.
>
> I feel that this style of generic building blocks truly embodies what is
> meant by "programmable money".
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Testnet3 Reest

[Jimmy Song via bitcoin-dev]

Stupid question time:

Why don't we have multiple testnets?

On Thu, Aug 30, 2018 at 3:31 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev
> wrote:
> > Hi,
> >
> > Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
> >
> > Is a testnet reset scheduled in the next release or any reason not to do
> a
> > reset ?
> >
> > Fast onboarding/lower disk overheads would be  very much appreicated for
> > testing purposes
>
> Actually I'd advocate the opposite: I'd want testnet to be a *larger*
> blockchain than mainnet to find size-related issues first.
>
> Note that for testing regtest is often a better alternative, and you can
> setup
> private regtest blockchains fairly easily and with good control over
> exactly
> when and how blocks are created.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

Jorge, I'll be happy to discuss with you more about whether allowing
ASICBoost would actually secure the network more or not, but that's not my
main motivation. My main motivation is to get more miners to accept segwit.

The version bit usage part, I don't believe requires any code changes as
those bits aren't being used by BIP9 anyway, though some cleanup to
restrict them later is probably a good idea.
The requiring witness commitment part would require some changes, but
according to Timo Hanke, that's actually not necessary as overt is so much
more efficient.

In any case, I'm happy to close this discussion until there's some
indication that more miners would accept segwit as a result of this change.

Jimmy

On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón <jti...@jtimon.cc> wrote:

> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I've changed the proposal so only 8 bits are given to grinding so
> something
> > like 20 bits are available for signaling.
> >
> > I have to say I'm at a loss here as to what's next? Should I make a new
> BIP
> > or try to convince the authors of BIP141 to modify their BIP? Could
> someone
> > inform me on the next part of the process?
>
> See bip2, specifically
> https://github.com/bitcoin/bips/blob/master/bip-0002.
> mediawiki#bip-workflow
>
> "Following a discussion, the proposal should be submitted to the BIPs
> git repository as a pull request. This draft must be written in BIP
> style as described below, and named with an alias such as
> "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
> number (authors MUST NOT self-assign BIP numbers)."
>
> But I think it's kind of late to modify bip141, given that there's
> code out there with the current specification.
> I guess you can propose extensions or alternatives to replace it. I'm
> really not sure what's the next step, but I don't think you have
> provided enough motivation as to why we would want to maintain
> asicboost. You said it makes the network more secure, but that's not
> the case, as explained, not even if all honest miners use it.
>
> > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Tom Zander wrote:
> >>
> >> > The version field is still needed to actually allow future block
> version
> >> > upgrades. We would cut off our road forward if that were to be
> blocked.
> >>
> >> I tend to agree, if all 32 bits were given up to grinding.
> >>
> >> But it's worth pointing out that BIP9 is purely informational, and the
> top
> >> 3 bits are still reserved for other purposes. One of them could perhaps
> be
> >> used to signal for an extended version field somewhere else, leaving the
> >> bottom 29 as entropy?
> >>
> >> Not a direction I prefer, but just a technical possibility perhaps.
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

I've changed the proposal so only 8 bits are given to grinding so something
like 20 bits are available for signaling.

I have to say I'm at a loss here as to what's next? Should I make a new BIP
or try to convince the authors of BIP141 to modify their BIP? Could someone
inform me on the next part of the process?

On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Tom Zander wrote:
>
> > The version field is still needed to actually allow future block version
> upgrades. We would cut off our road forward if that were to be blocked.
>
> I tend to agree, if all 32 bits were given up to grinding.
>
> But it's worth pointing out that BIP9 is purely informational, and the top
> 3 bits are still reserved for other purposes. One of them could perhaps be
> used to signal for an extended version field somewhere else, leaving the
> bottom 29 as entropy?
>
> Not a direction I prefer, but just a technical possibility perhaps.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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" <jaej...@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 <jti...@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 <jti...@jtimon.cc> wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> > <bitcoin-dev@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?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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 <jti...@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 <jti...@jtimon.cc> wrote:
> >
> >
> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
> > <bitcoin-dev@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?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

>
>
> No, it isn't allowed right now. Doing it wouldn't invalidate blocks, but it
> would clearly be an attack on the network and cause harm. The same as if
> miners were to maliciously mine only empty blocks.
>
>
What's your definition of "allowed" then? Because a miner definitely can
mine only empty blocks and a miner definitely can do overt ASICBoost (using
as little as 1 bit of the version field) right now. I thought you meant
allowed in the sense that if a block is allowed, it is a valid block on the
network. It sounds like you mean something else, perhaps, "a block is
allowed if it doesn't cause harm to the network." I'm not sure how you
quantify that as that seems pretty subjective.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

>
> 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 <jaej...@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.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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.


> If anything, we would be making policy changes to prevent the use of
> patented PoW algorithms instead of making changes to enable them.
>

Is that patented in any jurisdiction, all jurisdictions or only certain
jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient
for Bitcoin to change the Proof of Work algorithm? This is a very
subjective judgment based on quasi-legality and I don't think that's a road
that Bitcoin should go down.

Certainly, it would be better if the patent for ASICBoost were
open-sourced, but the legality of such-and-such thing in such-and-such
jurisdiction should not affect Bitcoin policy as that in itself introduces
significant risk to the network. A sufficiently authoritarian government
can then grant a monopoly for various algorithms in their country and
negatively impact Bitcoin.

Indeed, there are already many individuals that disobey the laws of their
country to help the Bitcoin network run. I would expect the same with
patents. Should there come a time when a patent or some other legal
maneuvering gives one network actor a large advantage to the detriment of
the network, I believe that Bitcoin will handle that in the specific case.

In the meantime, I believe such changes increase the odds of Segwit
actually being accepted and activated as per BIP-141.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jimmy Song via bitcoin-dev]

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  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.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev