Andrew C [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-21 to 2017-02-06
💬 Posted a total of 14 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 17:56:08

- reply

📅 Original date posted:2017-02-06
📝 Original message:I looked at the discussions about the block size and about Luke-Jr's
proposal on Reddit and Bitcointalk. From what I observed of all of the
discussions is that few users are in favor of the status quo, and even
fewer are in favor of decreasing the block size. The majority of users
favored Segwit because it was a block size increase (that was a commonly
used reason in support of it and in arguments about increasing the block
size).
Discussions about Luke-Jr's proposal indicated that many users disagreed
with the decrease in block size and the time that it took to increase
again to 1 MB. There was not only disagreement but explicit ridicule and
mocking of that aspect of the proposal.
On 2/6/2017 3:28 PM, Thomas Kerin wrote:
> "Many users are of the opposite opinion, that the block size is too
> small." - That is newspeak, the users can speak for themselves.
>
> From whom did you gather feedback from before you changed Luke-Jrs BIP?
>
> If people don't agree with the proposal, changing it an infinite
> number of times light well lead to the same result.
>
> Have the users spoken, in their response to what Luke-Jr proposed?
>
> On 6 February 2017 00:53:03 CET, Andrew C via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 2/5/2017 6:02 PM, Luke Dashjr wrote:
>
> My BIP draft didn't make progress because the community
> opposes any block size increase hardfork ever.
>
> From what I have observed, it seems to be that people are more so
> opposed to a hard fork when there is a comparable soft fork available
> than simply opposed to any block size increase hard fork ever. From the
> various threads discussing your proposal, it seemed that many would
> favor it if it increased over 1 MB sooner or if it never even decreased
> in the first place.
>
> Your version doesn't address the current block size issues
> (ie, the blocks being too large).
>
> Many users are of the opposite opinion, that the block size is too
> small. I understand that the decrease is to allow the blockchain size to
> grow more slowly thereby allowing users to be more likely to run full
> nodes. Unfortunately, I think that we are way past the point of no
> return on that. The blockchain is already 100+ GB. Decreasing the block
> size is not going to make that any smaller and is not going to make it
> any less painful to run a full node. Given that in order to start up a
> new full node will still require downloading at least 100 GB of data, I
> don't think that decreasing the block size will better facilitate full
> node creation. Furthermore, the current trend with ISPs (at least in the
> US) is implementing data and bandwidth caps so users are still unlikely
> to start up new full nodes regardless of any changes that we can
> currently do.
>
> So you've retained the only certain- DOA parts of my proposal,
> and removed the most useful part... I'm not sure the point.
> Also, your version is now EXCLUSIVELY a hardfork, so it makes
> no sense to keep the BIP 9 deployment at all - either it gets
> consensus or it doesn't, but miners have no part in deployment
> of it.
>
> Yes, I know deployment needs to be fixed. I was more proposing this for
> comment on the modified block size schedule. I just kept the deployment
> as it was originally. However, we could use a modified version of BIP 9
> by using one of the top three bits and a longer locked-in period as a
> grace period for all users to upgrade.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via
> bitcoin-dev wrote:
>
> Hello all, Many people have expressed discontent with
> Luke-jr's proposed block size BIP, in particular with the
> decrease in size that would occur if it were to be
> activated prior to 2024. I have decided to modify the
> proposal to instead begin the increase steps at the
> current 1000000 byte limit. The increases and the time
> spam of each increase will remain the same, just that the
> increase begins from 1000000 bytes instead of 300000
> bytes. Furthermore, instead of a fixed schedule from a
> fixed point in time, the increases will instead be
> calculated off of the MTP of the activation block (the
> first block to be in the active state for this fork).
> While this proposal shares many of the same issues with
> the one it modifies, I hope that it will be slightly less
> controversial and can allow us to move forward with
> scaling Bitcoin. The full text of the proposal can be
> found at
> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
> My implementation of it is available at
> https://github.com/achow101/bitcoin/tree/bip-blksize Andrew
> ------------------------------------------------------------------------
> 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
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170206/a67c0b89/attachment-0001.html>

2023-06-07 17:56:02

- reply

📅 Original date posted:2017-02-05
📝 Original message:On 2/5/2017 6:02 PM, Luke Dashjr wrote:
> My BIP draft didn't make progress because the community opposes any block size
> increase hardfork ever.
From what I have observed, it seems to be that people are more so
opposed to a hard fork when there is a comparable soft fork available
than simply opposed to any block size increase hard fork ever. From the
various threads discussing your proposal, it seemed that many would
favor it if it increased over 1 MB sooner or if it never even decreased
in the first place.
> Your version doesn't address the current block size
> issues (ie, the blocks being too large).
Many users are of the opposite opinion, that the block size is too
small. I understand that the decrease is to allow the blockchain size to
grow more slowly thereby allowing users to be more likely to run full
nodes. Unfortunately, I think that we are way past the point of no
return on that. The blockchain is already 100+ GB. Decreasing the block
size is not going to make that any smaller and is not going to make it
any less painful to run a full node. Given that in order to start up a
new full node will still require downloading at least 100 GB of data, I
don't think that decreasing the block size will better facilitate full
node creation. Furthermore, the current trend with ISPs (at least in the
US) is implementing data and bandwidth caps so users are still unlikely
to start up new full nodes regardless of any changes that we can
currently do.
> So you've retained the only certain-
> DOA parts of my proposal, and removed the most useful part... I'm not sure the
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense
> to keep the BIP 9 deployment at all - either it gets consensus or it doesn't,
> but miners have no part in deployment of it.
Yes, I know deployment needs to be fixed. I was more proposing this for
comment on the modified block size schedule. I just kept the deployment
as it was originally. However, we could use a modified version of BIP 9
by using one of the top three bits and a longer locked-in period as a
grace period for all users to upgrade.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
>> Hello all,
>>
>> Many people have expressed discontent with Luke-jr's proposed block size
>> BIP, in particular with the decrease in size that would occur if it were
>> to be activated prior to 2024.
>>
>> I have decided to modify the proposal to instead begin the increase
>> steps at the current 1000000 byte limit. The increases and the time spam
>> of each increase will remain the same, just that the increase begins
>> from 1000000 bytes instead of 300000 bytes.
>>
>> Furthermore, instead of a fixed schedule from a fixed point in time, the
>> increases will instead be calculated off of the MTP of the activation
>> block (the first block to be in the active state for this fork).
>>
>> While this proposal shares many of the same issues with the one it
>> modifies, I hope that it will be slightly less controversial and can
>> allow us to move forward with scaling Bitcoin.
>>
>> The full text of the proposal can be found at
>> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
>> My implementation of it is available at
>> https://github.com/achow101/bitcoin/tree/bip-blksize
>>
>>
>> Andrew
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:56:01

- reply

📅 Original date posted:2017-02-05
📝 Original message:Hello all,
Many people have expressed discontent with Luke-jr's proposed block size
BIP, in particular with the decrease in size that would occur if it were
to be activated prior to 2024.
I have decided to modify the proposal to instead begin the increase
steps at the current 1000000 byte limit. The increases and the time spam
of each increase will remain the same, just that the increase begins
from 1000000 bytes instead of 300000 bytes.
Furthermore, instead of a fixed schedule from a fixed point in time, the
increases will instead be calculated off of the MTP of the activation
block (the first block to be in the active state for this fork).
While this proposal shares many of the same issues with the one it
modifies, I hope that it will be slightly less controversial and can
allow us to move forward with scaling Bitcoin.
The full text of the proposal can be found at
https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
My implementation of it is available at
https://github.com/achow101/bitcoin/tree/bip-blksize
Andrew

2023-06-07 17:56:00

- reply

📅 Original date posted:2017-02-05
📝 Original message:Instead of using vanity addresses, the transactions could just use an
OP_RETURN output and express the signalling there.
However, such a system could be easily gamed by people who simply spam
the network with transactions and by miners who choose what transactions
to include in their blocks.
On 2/2/2017 7:13 PM, John Hardy via bitcoin-dev wrote:
>
> Currently in order to signal support for changes to Bitcoin, only
> miners are able to do so on the blockchain through BIP9.
>
>
> One criticism is that the rest of the community is not able to
> participate in consensus, and other methods of assessing community
> support are fuzzy and easily manipulated through Sybil.
>
>
> I was trying to think if there was a way community support could be
> signaled through transactions without requiring a hard fork, and
> without increasing the size of transactions at all.
>
>
> My solution is basically inspired by hashcash and vanity addresses.
>
>
> The output address of a transaction could basically have the last 4
> characters used to signal support for a particular proposal.
>
> To generate an address with 4 consecutive case-insensitive characters
> should be roughly 34^4 which is just over a million attempts. On
> typical hardware this should take less than a second.
>
> An example bitcoin address that wanted to support the core roadmap
> might be:
>
> 1CLNgjuu8s51umTA76Zi8v6EdvDp8q*CorE*
>
>
> or to signal support for a big block proposal might be:
>
> 1N62SRhBioRFrigS5eJ8kR1WYcfcYr*16mB*
>
>
> Popularity could be measured weighted by fee paid per voting kb.
>
>
> Issues are that this could lead to transactions been censored by
> particular miners for political reasons. Also miners might attempt to
> manipulate the results by stuffing their block with 'fake'
> transactions. Such attempts could be identified if a large number of
> voting transactions were not in the mempool.
>
>
> Despite the limitations, I believe this offers a very accessible way
> to immediately allow the entire economic community to signal their
> support within transactions. The only cost is that of a tiny hashing
> PoW that should tie up a CPU for a barely noticeable amount of time,
> and could be implemented relatively easily into wallet software.
>
>
> For its weaknesses, surely it is better than the existing methods we
> use to assess support from the wider economic community?
>
>
> While it could just be used for signaling support and giving users a
> 'voice' on chain, if considered effective it could also be used to
> activate changes in the future.
>
>
> Any thoughts welcome.
>
>
> Thanks,
>
>
> John Hardy
>
> john at seebitcoin.com
>
>
>
> _______________________________________________
> 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/20170205/a28d872f/attachment.html>

2023-06-07 17:54:11

- reply

📅 Original date posted:2016-10-28
📝 Original message:On 10/27/2016 11:38 AM, Andrew via bitcoin-dev wrote:
> I have been reading recently through the history of soft forks
> provided by Bitcoin Core:
> https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks.
>
> It has led me to think that there is a deceiving notion that soft
> forks do not force Bitcoin users to upgrade software. Yes, it's true
> that the past soft forks still allow old nodes to accept blocks under
> the tighter rules as valid, but what about miners who are still using
> old software? What about users who want to make a transaction using
> the old rules? Those people are no longer able to do those things. And
> if they want to do those things, a hard fork will result.
A soft fork means that a transaction using the old rules will still
work. Look at segwit, you can still make the original style of
transactions with P2PK, P2PKH, and P2SH outputs. There is nothing here
to cause a hard fork.
> Remember what happened when BIP 66 was activated? Luckily, it was
> short lived, but this is just the beginning. If you keep tightening
> the rules, you are building up more and more pressure for a split in
> the network to occur. You can call this split a "hard fork" or just a
> "fork", but it is dangerous either way, and it leads to basically the
> creation of two coins when before we just had one, people instantly
> lose value, and the trust in Bitcoin's store of value dies.
BIP 66's hard fork was not due to the soft fork making transactions
invalid. Rather it was because miners were not properly validating
blocks before building on top of them. That fork was because a
non-upgraded miner created a block invalid under the new rules and
upgraded miners did not check the block and built on top of it. That
invalid block was only invalid because the isSuperMajority mechanism
specified that the new version number must be used otherwise the block
was invalid, and that was what happened: the invalid block had the old
version number. This is not an issue for BIP 9 Versionbits soft forks
because no such rule exists.
>
> Obviously every one can debate about what should be the definition of
> a soft fork, but whatever that is, I think it is unacceptable how
> sloppily the past soft forks have been deployed.
In what way have these forks been sloppily deployed? The fork caused by
previous a soft forks (there was only one that caused that had an actual
chain split issue) was due to the isSuperMajority mechanism which is not
a good mechanism for deployment. It has been superseded by BIP 9
Versionbits. Furthermore, that fork was not due to "sloppy deployment"
by the devs but rather due to greedy miners who were SPV mining.
> I can think of many ways in which we could have these new features
> that the soft forks provided, but without forcing the new rules, and
> simply making them features that can be used on an individual miner or
> transaction signer basis. Is there a document from Bitcoin Core that
> outlines the philosophy of soft forks and why it is acceptable to
> force the tightening of rules and cause such risks? And please give me
> another reason other than "it removes a few if statements from the code".
Can you explain what other risks you think there are with soft forks?
>
> Now that Segregated witness is scheduled to be deployed on November
> 15, we should take a look at this "soft fork" as well. I like the idea
> of Segregated Witness, but from conversations on Reddit and IRC, I see
> people saying that this soft fork will be like the others: requiring a
> hard fork in order to revert it. Is this true?
If you are reading r/btc, you are doing something wrong.
Like with all soft forks, the only way to revert them is by a hard fork.
Soft forks make previously valid things invalid, hard forks make
previously invalid things valid. In order to revert a soft fork which
made something invalid, you need to hard fork to make it valid again.
> I am getting conflicting messages by reading the BIP. It says that if
> all transactions are non-segwit, then a node will validate the block
> as before. But if we pass the threshhold (usually 95 % for 1000
> blocks) will miners mining non-segwit blocks be ignored? This is not
> good... I really think we should make it optional. Miners will have an
> incentive to mine segwit blocks, since it allows for more transactions
> per block, so why force them?
No. This is incorrect. There is no requirement to include the witness
commitment in the coinbase if no transactions in the block contain
witnesses. Because transactions that contain witnesses are considered
non-standard transactions by the old rules, if a miner who did not
upgrade continues to follow those standardness rules, their blocks will
not be invalid and they are not forced to upgrade.
> What if we want to slightly modify the Segwit protocol in the future?
> What if we want to replace segwit with something much different? We
> will be forced to do a hard fork in order to do that.
Not necessarily, it depends on the change. Most changes (such as
sighashing, new opcodes, different scripts, etc.) can be done via
another soft fork because segwit introduces script versioning. A new
script version would be created with the necessary changes and that can
be soft forked in.
>
> Now, we can't go back in time and fix the deployment of the soft
> forks, but I do propose one clean way to fix things: Remove all the
> previously "soft forked" rules for non segwit transactions, and
> require them only for segwit transactions. But make segwit optional!
> In addition to what I talked about above, this may also relieve some
> tensions of people who are not comfortable with segwit and are
> thinking of joining a hard fork like the Bitcoin Unlimited project.
Segwit already is optional. If you don't want to use segwit, you don't
have to. If you don't want to mine segwit blocks, you don't have to.
As for removing all previously soft forked things, then you would be
removing a ton of functionality, various fixes, and potentially break a
large number of transactions that already exists but are not confirmed
yet. This would require a hard fork.
As for what is would be reverted, you would be reverting P2SH (multisig
addresses, you still want those right?), OP_CLTV, OP_CSV, block height
requirement in Coinbase, the value overflow incident, removal of
dangerous opcodes, reduction of block size limit, etc. As you can see, a
lot of functionality and various bug fixes would be lost be reverting
every single soft fork.
>
> Unless people can give me a good explanation as to why we are
> deploying soft forks in such forceful manner,
As I have said throughout this response, soft forks are not deployed in
a forceful manner which forces people to upgrade.
> or Bitcoin Core accepts my proposal, then I will have no choice but to
> create a new client (I'm thinking to call it Bitcoin Authentic), that
> will be just as Bitcoin Core but will always follow the chain with the
> most work regardless of whether soft fork rules are respected, and I
> would put at least CHECKLOCKTIMEVERIFY as mandatory within segwit
> transactions.
Great, go ahead. Honestly, I don't think anyone cares about your
"ultimatum". You are a random person on the internet.
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
>
>
> _______________________________________________
> 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/20161028/72db51a8/attachment-0001.html>

2023-06-07 17:54:06

- reply

📅 Original date posted:2016-10-17
📝 Original message:On 10/17/2016 7:17 AM, Tom Zander via bitcoin-dev wrote:
> As Marek wrote just minutes before your email came in; companies will not
> roll out their updates until it locks in. Peter Todd says the same thing.
> So your assumption that the lock-in time is the END of the upgrading is
> false. Thats only the case for miners.
But again, how does having a longer fallow period make this any safer?
As was mentioned before, a lot of the wallets listed as WIP have code
ready and tested, just not officially released, so not listed as ready.
It doesn't take 2 months to roll out a software update that is already
prepared beforehand.
> The entire point here is that SegWit is much bigger than just full nodes
> (including miner).
> An entire ecosystem of Bitconin will have a need to upgrade.
>
> I understand people saying that non-miners don't *need* to upgrade in order
> to avoid being kicked of the network, but truely, thats a bogus argument.
>
> People want to actually participate in Bitcoin and that means they need to
> understand all of it. Not just see anyone-can-spend transactions.
> I think its rather odd to think that developers on this list can decide
> the risk profile that Bitcoin using companies or individuals should have.
I think it's rather odd that no major Bitcoin companies have raised any
such issues with Segwit and in fact many already have the upgrade in the
works. I think it's rather odd that individuals who are not opposed to
segwit would choose to not upgrade even though it has been actively
discussed for the past year.
> There are a bunch of really large assumptions in there that I disagree with.
> First of all, miners running the latest software doesn't mean the software
> is free from flaws. Everyone makes mistakes. People that see a way to abuse
> the system may have found things and are not reporting it because they want
> to abuse the flaw for their own gains. Which is exactly what happened with
> Etherium.
While flaws can still be found, unlike the DAO, Segwit has been tested
extensively for a much longer period of time. Waiting any longer isn't
likely to help given that so much testing and review has already been
done. Even so, that is a pointless argument as it is impossible to know
whether waiting a little longer would reveal an issue.
>
> The amount of code and the amount of changes in SegWit makes this a very
> dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin
> being changed with it. We don't yet know how they will interact. We can’t.
Really? How so? It's been active on 4 different segwit specific testnets
and it has been active on the Testnet for the past several months.
People have been spamming segwit transactions and extensively testing
Segwit since its deployment on Testnet. I think we know how segwit
transactions and all aspects of the changes work together as it has been
tested as such for several months now.

2023-06-07 17:54:05

- reply

📅 Original date posted:2016-10-16
📝 Original message:On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> Lets get back to the topic. Having a longer fallow period is a simple way to
> be safe. Your comments make me even more scared that safety is not taken
> into account the way it would.
Can you please explain how having a longer grace period makes it any
safer? Once the fork reaches the LOCKED_IN status, the fork will become
active after the period is over. How does having a longer grace period
make this any safer besides just adding more waiting before it goes
active? You said something about rolling back the changes. There is no
mechanism for roll backs, and the whole point of the soft fork
signalling is such that there is no need to roll back anything because
miners have signaled that they are supporting the fork.

2023-06-07 17:53:19

- reply

📅 Original date posted:2016-09-10
📝 Original message:On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote:
> 3. After a few months or so, publish the private key.
Why wait a few months? Why not just publish the key a few days after the
final alert?

2023-06-07 17:53:18

- reply

📅 Original date posted:2016-09-09
📝 Original message:ACK
Armory used to contain code for handling these alerts but that was
removed after the PR removing alerts from Bitcoin Core was merged.
On 9/9/2016 8:42 PM, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
>
> It has been removed completely in Bitcoin Core after being disabled for a while.
>
> While the system had some potential uses, there were a number of
> problems with it.
>
> The alert system was a frequent source of misunderstanding about the
> security model and 'effective governance', for example a years ago a
> BitcoinJ developer wanted it to be used to control fee levels on the
> network and few months back one of Bloq's staff was pushing for a
> scheme where "the developers" would use it to remotely change the
> difficulty-- apparently with no idea how abhorrent others would find
> it.
>
> The system also had a problem of not being scalable to different
> software vendors-- it didn't really make sense that core would have
> that facility but armory had to do something different (nor would it
> really make sense to constantly have to maintain some list of keys in
> the node software).
>
> It also had the problem of being unaccountable. No one can tell which
> of the key holders created a message. This creates a risk of misuse
> with a false origin to attack someone's reputation.
>
> Finally, there is good reason to believe that the key has been
> compromised-- It was provided to MTGox by a developer and MTGox's
> systems' were compromised and later their CEO's equipment taken by the
> Japanese police.
>
> In any case, it's gone now in Core and most other current software--
> and I think it's time to fully deactivate it.
>
> I've spent some time going around the internet looking for all
> software that contains this key (which included a few altcoins) and
> asked them to remove it. I will continue to do that.
>
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
>
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
>
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
>
> Cheers,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:48:05

- reply

📅 Original date posted:2016-01-22
📝 Original message:With 0.12 and opt-in RBF, nSequence will have multiple uses. It can be used
for locktime and now signaling for opting in to RBF. However, there is
nothing that I could find that distinguishes the uses for nSequence.
Spending a time locked output requires setting nSequence to less than
MAX_INT but opting into RBF also requires setting nSequence to less than
MAX_INT. By spending a time locked output, you would also be opting into
RBF, which may not be desired behavior. Since using nSequence to signal a
certain behavior will probably be used in the future, is there any plan to
change nSequence so that the features the transaction is using can be
distinguished? Perhaps something like version bits?
Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160122/790e817d/attachment.html>

2023-06-07 17:48:05

- reply

📅 Original date posted:2016-01-23
📝 Original message:Ahh. I see. Thanks, I must have missed that when going through the BIP.
Guess I need to read more carefully next time.
Thanks,
Andrew
On Fri, Jan 22, 2016 at 11:11 PM David A. Harding <dave at dtrt.org> wrote:
> On Fri, Jan 22, 2016 at 04:36:58PM +0000, Andrew C via bitcoin-dev wrote:
> > Spending a time locked output requires setting nSequence to less than
> > MAX_INT but opting into RBF also requires setting nSequence to less than
> > MAX_INT.
>
> Hi Andrew,
>
> Opt-in RBF requires setting nSequence to less than MAX-1 (not merely
> less than MAX), so an nSequence of exactly MAX-1 (which appears in
> hex-encoded serialized transactions as feffffff) enables locktime
> enforcement but doesn't opt in to RBF.
>
> For more information, please see BIP125:
>
> https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
>
> -Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160123/1fa99b48/attachment.html>

2023-06-07 17:47:58

- reply

📅 Original date posted:2016-01-18
📝 Original message:In the release notes for 0.12, it says that we have moved from using
OpenSSL to libsecp256k1 for signature validation. So what else is it being
used for that we need to keep it as a dependency?
Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160119/2cc15d41/attachment.html>

2023-06-07 17:38:00

- reply

📅 Original date posted:2015-08-27
📝 Original message:I have been reading the pdf and one thing I can't figure out is what you
mean by "most common floor". Is that the smallest block size that has a
vote or the block size with the most votes or something else?
On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik <jgarzik at gmail.com> wrote:
> Great questions.
>
> - Currently working on technical BIP draft and implementation, hopefully
> for ScalingBitcoin.org. Only the PDF is publicly available as of today.
> - Yes, the initial deployment is in the same manner as size votes.
>
>
> On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Is there any client or code that currently implements BIP 100? And how
>> will it be deployed? WIll the initial fork be deployed in the same manner
>> that the max block size changes are deployed described in the bip?
>>
>> Thanks
>>
>> _______________________________________________
>> 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/20150827/84b8f2a1/attachment.html>

2023-06-07 17:38:00

- reply

📅 Original date posted:2015-08-21
📝 Original message:Hi all,
Is there any client or code that currently implements BIP 100? And how will
it be deployed? WIll the initial fork be deployed in the same manner that
the max block size changes are deployed described in the bip?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/b378c5ba/attachment-0001.html>

2023-06-07 15:49:24

- reply

2023-06-07 15:49:24

- reply