Potter QQ [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-06-01 to 2015-06-16
💬 Posted a total of 2 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:38:07

- reply

📅 Original date posted:2015-06-16
📝 Original message:No,Bitcoin
发自我的 iPhone
> 在 2015年6月16日，13:28，justusranvier at riseup.net 写道：
>
>> On 2015-06-16 03:49, Kevin Greene wrote:
>> Hah, fair enough, there is no such thing as the "right" way to do
>> anything. But I still think punishing users who use SPV wallets is a
>> less-than-ideal way to incentive people to run full nodes. Right now
>> SPV is
>> the best way that exists for mobile phones to participate in the
>> network in
>> a decentralized way. This proposal makes the user experience for mobile
>> wallets a little more confusing and annoying.
>
> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who
> would provide the nodes they would need connect to? The decentralization
> fairy?
>
> There's absolutely no reason that paying for connectivity would be any
> more confusing or annoying than transaction fees are.
>
> If some full nodes in the network started offering paid connection
> slots, that would just mean that users who checked the "pay subscription
> fee" box in their wallet configuration would have an easier time
> connecting than the users who did't, just like how your transaction
> might eventually get mined without a fee but paying one makes it faster
> and more probable.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinf

2023-06-07 15:38:07

- reply

2023-06-07 15:36:15

- reply

📅 Original date posted:2015-06-01
📝 Original message:oh my God ...
发自我的 iPhone
> 在 2015年5月27日，19:26，Tier Nolan <tier.nolan at gmail.com> 写道：
>
>
>
>> On Wed, May 27, 2015 at 11:15 AM, Peter Todd <pete at petertodd.org> wrote:
>> The median time mechanism is basically a way for hashing power to show
>> what time they think it is. Equally, the nVersion soft-fork mechanism is
>> a way for hashing power to show what features they want to support.
>
> Fair enough. It means slightly more processing, but the median time could be cached in the header index, so no big deal.
>
>> Block counts are inconvenient for planning, as there's no guarantee
>> they'll actually happen in any particular time frame, forward and back.
>
> I don't think the deadline needs to be set that accurately. A roughly 6 month deadline should be fine, but as you say a majority of miners is needed to abuse the median time and it is already a miner poll.
>
> Perhaps the number of blocks used in the median could be increased to reduce "noise".
>
> The median time could be median of the last 144 blocks plus 12 hours.
>
>> If you assume no large reorganizations, your table of known BIPs can
>> just as easily be a list of block heights even if the median time
>> mechanism is used.
>
> I think it makes it easier to write the code. It reduced the state that needs to be stored per BIP. You don't need to check if the previous bips were all accepted.
>
> Each bit is assigned to a particular BIP for a particular range of times (or blocks).
>
> If block numbers were used for the deadline, you just need to check the block index for the deadline block.
>
> enum {
> BIP_INACTIVE = 0,
> BIP_ACTIVE,
> BIP_LOCKED
> BIP_INVALID_BLOCK,
> }
>
> int GetBIPState(block, bip)
> {
> if (block.height == bip.deadline) // Bit must be set to match locked/unlocked at deadline
> {
> int bipState = check_supermajority(...);
> if (bipState == BIP_LOCKED && (block.nVersion & bip.bit)
> return BIP_LOCKED;
>
> if (bipState != BIP_LOCKED && (block.nVersion & (~bip.bit)))
> return BIP_INACTIVE;
>
> return BIP_INVALID_BLOCK;
> }
>
> if (block.height > deadline) // Look at the deadline block to determine if the BIP is locked
> return (block_index[deadline].nVersion & bip_bit) != 0 ? BIP_LOCKED : BIP_INACTIVE;
>
> if (block.height < startline + I) // BIP cannot activate/lock until startline + implicit window size
> return INACTIVE;
>
> return check_supermajority(....) // Check supermajority of bit
> }
>
> The block at height deadline would indicate if the BIP was locked in.
>
> Block time could still be used as long as the block height was set after that. The deadline_time could be in six months. The startline height could be the current block height and the deadline_height could be startline + 35000.
>
> The gives roughly
>
> start time = now
> deadline time = now + six months
> deadline height = now + eight months
>
> The deadline height is the block height when the bit is returned to the pool but the deadline time is when the BIP has to be accepted.
>
> It also helps with the warning system. For each block height, there is a set of known BIP bits that are allowed. Once the final deadline is passed, the expected mask is zeros.
>
>> On Wed, May 27, 2015 at 11:15 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan at gmail.com> wrote:
>>
>> > Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication?
>>
>> You need 75% to start applying it, 95% to start rejecting blocks that don't apply it.
>
> I think the phrasing is ambiguous. I was just asking for clarification.
>
> "Whenever I out of any W subsequent blocks (regardless of the block itself) have bit B set,"
>
> That suggests that the I of W blocks for the 95% rule must happen after activation. This makes the rule checking harder. Easier to use the current system, where blocks that were part of the 750 rule also count towards the 95% rule.
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/c8bd5163/attachment.html>

2023-06-07 15:36:15

- reply