Michael Ruddy [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-07-05 to 2015-08-10
💬 Posted a total of 5 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:34:18

- reply

📅 Original date posted:2015-08-10
📝 Original message:Sergio, you raise an interesting question.
I had seen your message to the list related to this idea before [1],
so I went back to research what the viewpoints and conclusions were,
if any.
I didn't find anything too conclusive, but I did find some persuasive
points by Dave Hudson [2] [3] [4] [5] that seem to also favor
increasing the target block creation rate (decreasing the target time
interval between blocks).
Considering that increasing the target block creation rate could
reduce the effect of (but not solve [6]) the fundamental mismatch
between transaction creation and the Poisson process of block
discovery [7] and could reduce miner variance (possibly an aid to
miner decentralization), I think I'd go with option B to answer your
question.
I wonder why this does not seem to ever gain more traction when you
bring it up? The idea does not seem crazy.
[1]: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html
[2]: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07665.html
[3]: https://twitter.com/hashingitcom/status/595615823340908545
[4]: https://twitter.com/hashingitcom/status/605443289379143680
[5]: http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[6]: https://twitter.com/jgarzik/status/595611423151030272
[7]: http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

2023-06-07 17:32:20

- reply

📅 Original date posted:2015-08-03
📝 Original message:Does that not sound like a useful check-and-balance? It does to me.
In a scenario where these network limitations and miner rate
distributions are the same to begin, and the block and transaction
size limits are raised or removed, your observation would seem to
indicate that blocks that are outstandingly large would not be mined
often or at all (due to orphan risk), until at least the network
limitations or rate distributions changed.
Such a scenario could shape up to be a non-event. Miner majority could
choose to not change their policy regarding effective block and
transaction sizes (which includes both the size of the blocks they
create and the size of the blocks that they choose to build upon). To
make it not a total non-event, then the miners might update their
policy to increase the effective sizes a measured amount. They
wouldn't want to go too far because of the risk of spooking the
economic majority, or because of their own technological limitations
(which I'm supposing would remain transport layer limitations).
To me, in absence of these transport layer limitations that have crept
up into the consensus rules layer (clear layer violations), it seems
that one thing that would otherwise naturally bound the upper and
lower limits of effective block and transaction size is the economic
majority feedback loop to miners. Get too far out of line and the
effect on usefulness, or properties of the system, will make people
react by lowering the purchasing power of the block rewards. For
example, attack other miners to drive more mining centralization, or
create blocks that are currently too big for people to validate/use,
and that feedback loop will start to direct negatively.
Why do miners not currently choose policy that favors smaller blocks
and transactions than they do? Laziness/indifference only explains so
much. I submit that they don't because if they make the system less
useful, then people will react by selling off coins and potentially
leaving the ecosystem (they might also just wait on the sidelines to
see if the system self-corrects). If the miners tested those waters,
and found out that they made a mistake, at least they would be free to
correct their actions (and quickly). Not all would be lost. Some value
could be (temporarily) lost. It could also be re-gained if the system
self-corrected.
To follow-up on the layer violation idea that I started on before, I
think a secondary, non-consensus rule layer, indication of what block
and transaction sizes are acceptable to the economic majority would be
found in the transport protocols that they use. For example, the
effective P2P protocol limit that is 2MB or 32MB (depending on version
of the Core client) would be one such indication. Doesn't anyone think
that separating the consensus layer rules from the transport layer
supporting it should be a goal?
On Mon, Aug 3, 2015 at 2:34 AM, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners, it
> is not the Chinese miners that lose, it is all of the non-Chinese miners -
> this is because the Chinese miners have the slight majority of the hashrate.
> The relatively low external bandwidth connecting China to the net is
> actually the problem of the non-Chinese miners problem. Non Chinese miners
> will experience higher orphan rate once Chinese miners cease to build on top
> of blocks that are too large to sync in a timely fashion into China.
>
> Adam

2023-06-07 17:32:06

- reply

📅 Original date posted:2015-08-02
📝 Original message:I think your "hardfork bit" proposal is clever.
It addresses the particular valid concern of re-org facing users of a
fork that a small/near/fluctuating majority, or less, of mining power
supported.
While the "economic majority" argument may be enough on its own in
that case, it still has some aspect of being a hand wave.
This proposal adds support to those economic actors, which makes it
easier for them to switch if/when they choose. That is, it provides a
good fallback mechanism that allows them to make a decision and say,
"we're doing this".
Do you have the latest version up on github, or someplace where it
would be easier to collaborate on the specific text?
On Sat, Aug 1, 2015 at 4:23 PM, <jl2012 at xbt.hk> wrote:
> Although the chance is very slim, it is possible to have multiple hardforks
> sharing the same flag block. For example, different proposals may decide the
> flag time based on voting result and 2 proposals may have the same flag time
> just by chance. The coinbase message is to preclude any potential ambiguity.
> It also provides additional info to warning system of non-upgrading nodes.
>
> If we are pretty sure that there won't be other hardfork proposal at the
> same time, the coinbase message may not be necessary. With some prior
> collaboration, this may also be avoided (e.g. no sharing flag block allowed
> as consensus rules of the hardforks)
>
> The "version 0" idea is not compatible with the version bits voting system,
> so I have this hardfork bit BIP after thinking more carefully. Otherwise
> they are technically similar.

2023-06-07 17:32:05

- reply

📅 Original date posted:2015-08-01
📝 Original message:>> Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP on
>> github in the coinbase?
>
>
> I guess the git hash is not known until the code is written? (correct me if
> I'm wrong) As the coinbase message is consensus-critical, it must be part of
> the source code and therefore you can't use any kind of hash of the code
> itself (a chicken-and-egg problem)
>
I took Tier's comment to mean that the commit hash (taken from git) of
the BIP for the particular hard fork being rolled out via your hard
fork bit mechanism could be used in the coinbase.
The commit for the BIP is separate from the commit for the code
changes implementing it.
By using the commit hash of the BIP, it means that the BIP cannot
specify itself what to put in the coinbase.
I'd suggest that your hard fork bit proposal allows BIP authors to
specify, within a 20 byte limit (to let them ripe160 a message or
something), the unique value to use.
This would be just as well and would allow the specific hard fork BIPs
to be updated without having to make code changes (e.g.- for simple
grammatical updates, post deployment clarification, etc...).
Perhaps more preferable, in order to keep the coinbases small, or, if
you're worried about BIP authors using duplicate values, then just
specify in your proposal that the coinbase message include
"BIP<NUMBER>" as BIP numbers are not going to be reused. All you are
trying to achieve is something that can be uniquely pattern matched.
Are the reasons for your use of the coinbase message 1) to guard
against one or more hard forks piggy-backing on another's flag block,
without prior collaboration, and 2) to have a nicer message in the
alerting system? If so, you might want to spell that out in your
proposal. At first, I was thinking that the coinbase thing was not
entirely necessary since the possibility of multiple hard forks taking
place concurrently is low. Multiple forking changes could be
coordinated to all use the same possible voting mechanisms, median
timestamp, and thus flag block. But if the concern is about competing
hard forks where two or more forks abandon the original chain and
attempt to use the same checkpoint block, then I can see why you'd
need it.
I was reading this proposal alongside another of your messages
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009520.html)
proposing a version 0 or even a >1MB block in the specific case of a
block size limit hard fork. I can see the >1MB flag block creating DoS
banning problems. That's more of a practical issue than a consensus
issue due to the existing mono-culture of full nodes. So, currently a
>1MB flag block is not as appealing as a version 0 or this hard fork
bit proposal. Besides the DoS ban, the >1MB proposal would mean that
older nodes do not have the chance to notice a fork is happening (for
alerting) as they would with a version 0 or hard fork bit.
A version 0 flag block would not be able to contain any transactions
unless the flag block version was assumed to be that of the most
recent version at the time. This is because we'd want to enforce the
rules of the previous soft forks that had been locked in. Other than
that, the version 0 idea seems pretty similar to the hard fork bit
proposal because you need more context than just the block itself to
determine if it's a valid flag block (and this extra context is
probably not great, but I don't have a better idea right now).
Were those reasons part of why you progressed towards this hard fork
bit proposal?

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-04
📝 Original message:I first submitted this idea as an example usage for BIP65.
The feedback was that this might be large enough to be a BIP on its own.
So, I'm submitting here for review and feedback.
In short, this informational BIP describes two Bitcoin script constructs
that utilize the CHECKLOCKTIMEVERIFY opcode to create a smart contract that
allows a specific offer, with flexible expiration time, to be presented and
either accepted (optionally into escrow), or withdrawn/rejected.
The BIP draft can be found at:
https://github.com/mruddy/bips/blob/bip-xx-offer-accept-escrow/bip-offer-accept-escrow.mediawiki
An small example usage implementation can be found at:
https://github.com/mruddy/flexpiration
- Michael Ruddy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/afa1e4fa/attachment.html>