Jimmy Song [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-07 to 2019-10-03
💬 Posted a total of 15 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:20:59

- reply

📅 Original date posted:2019-10-03
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191003/36eecd03/attachment.html>

2023-06-07 17:59:55

- reply

📅 Original date posted:2017-04-08
📝 Original message:>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/06b7adc0/attachment.html>

2023-06-07 17:59:54

- reply

📅 Original date posted:2017-04-11
📝 Original message: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 <jtimon at jtimon.cc> wrote:
> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> <bitcoin-dev at 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 at 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 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/20170411/95a10ad4/attachment.html>

2023-06-07 17:59:54

- reply

📅 Original date posted:2017-04-11
📝 Original message: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 at 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 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/20170411/4b967431/attachment.html>

2023-06-07 17:59:50

- 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 17:59:48

- 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>