<unnamed>

Public Key

npub1vceyhqxfhemlfq82ztdv9gqgc08zq2680yzy4dfuly7h8pqrkwps0xz0wk

Profile Code

nprofile1qqsxvvjtsrymual5sr4p9kkz5qyv8n3q9drhjpz2k570j0tnsspm8qcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsua4ats

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:56:02 CEST

- 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 19:56:01 CEST

- 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 19:56:00 CEST

- 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 19:53:18 CEST

- 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