gladoscc [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-28 to 2016-02-12
💬 Posted a total of 4 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:49:10

- reply

📅 Original date posted:2016-02-12
📝 Original message:Here's a method of fixing block withholding attacks with a soft fork:
We require blocks to choose an arbitrary target, e.g. two bytes. We
redefine the block PoW target to be "less than the difficulty, with the
last two bytes being the target".
We require blocks to include a blinded hash of the target plus some junk
(which blinds it) in the coinbase. The miner cannot arbitrarily switch
targets.
The miner can now send the block header to hashers. Hashers do not know the
target, and hence must submit all shares that matches the first PoW
criteria (below difficulty) and delegate secondary verification to the
miner. With two bytes as the target, there are 65335 false positives for
every valid block.
Finally, we require miners to communicate a proof of their target hash (ie,
the junk they generated) in a non-hashed area of the block. This can be a
protocol extension. The target is already included in the hash as the last
two bytes.
This can be deployed as a soft fork with miner opt in, triggering across
many difficulty cycles. Initially, we soft fork to require the last bit of
the block hash to be zero. The next difficulty cycle, we require the last
two bits to be zero. We do this 16 times to get 2 bytes, and then we
actually activate targets.
By then, nominal difficulty would have been cut by 2^16 (65536), but the
block target makes mining each block 65536 times as hard. We do the
progression over 16 difficulty cycles to minimise increases in block
timings. We can be more specific and progress over even more difficulty
cycles through more clever soft fork rules.
For example, Vitalik detailed "timewalking" attacks that allow effective
granular lowering of the nominal difficulty.
Critique welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/b16be954/attachment.html>

2023-06-07 17:44:22

- reply

📅 Original date posted:2015-11-09
📝 Original message:I think 25% bandwidth savings is certainly considerable, especially for
people running full nodes in countries like Australia where internet
bandwidth is lower and there are data caps.
I absolutely would not dismiss 25% compression. gzip and bzip2 compression
is relatively standard, and I'd consider the point of implementation
complexity tradeoff to be somewhere along 5-10%.
On Tue, Nov 10, 2015 at 8:04 AM, Bob McElrath via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would expect that since a block contains mostly hashes and crypto
> signatures,
> it would be almost totally incompressible. I just calculated compression
> ratios:
>
> zlib -15% (file is LARGER)
> gzip 28%
> bzip2 25%
>
> So zlib compression is right out. How much is ~25% bandwidth savings
> worth to
> people? This seems not worth it to me. :-/
>
> Peter Tschipper via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
> wrote:
> > This is my first time through this process so please bear with me.
> >
> > I opened a PR #6973 this morning for Zlib Block Compression for block
> > relay and at the request of @sipa this should have a BIP associated
> > with it. The idea is simple, to compress the datastream before
> > sending, initially for blocks only but it could theoretically be done
> > for transactions as well. Initial results show an average of 20% block
> > compression and taking 90 milliseconds for a full block (on a very slow
> > laptop) to compress. The savings will be mostly in terms of less
> > bandwidth used, but I would expect there to be a small performance gain
> > during the transmission of the blocks particularly where network latency
> > is higher.
> >
> > I think the BIP title, if accepted should be the more generic, "Support
> > for Datastream Compression" rather than the PR title of "Zlib
> > Compression for block relay" since it could also be used for
> > transactions as well at a later time.
> >
> > Thanks for your time...
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > !DSPAM:5640ff47206804314022622!
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
> _______________________________________________
> 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/20151110/0d844af0/attachment.html>

2023-06-07 17:40:11

- reply

📅 Original date posted:2015-09-14
📝 Original message:I appreciate your interest in Bitcoin, but I trust that you understand your
proposal adds nothing to the current discussion and recommend you read more
emails from this mailing list.
On 14/09/2015 11:47 am, "Jason Livesay via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> After studying the issues I believe that the situation warrants a
> short-term modest blockchain increase. Somewhere between 2mb-5mb, whatever
> the community will swallow. I recommend that happen before the winter
> shopping rush.
>
> Then, because of the fundamental technical limitations of scaling, a new
> system needs to be adopted for fast transactions. To maintain momentum
> etc., the new system ultimately settles with traditional bitcoins.
>
> In order to keep the existing brand momentum, network, and business
> investment, I believe the smoothest path forward is to build a new,
> additional system re-using the bitcoin name. I suggest this new system
> come packaged with the bitcoin core client and be referred to as
> QuickBitcoin or qbtc or something similar. As far as the public is
> concerned it could simply continue to be called bitcoin. The system will
> work on top of traditional bitcoins but have a mechanism for more/faster
> transactions. Exactly what mechanism doesn't have to be perfect, it just
> needs to be reasonably secure/useful and something that the community will
> accept.
>
> I believe this is the best way to scale bitcoin while maintaining the
> strength of its existing network, community, and branding.
>
> _______________________________________________
> 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/20150915/95fe131b/attachment.html>

2023-06-07 17:38:21

- reply

📅 Original date posted:2015-08-28
📝 Original message:There has been discussion of using the genesis block hash to identify
chains in BIP 21 (bitcoin:// URI scheme). However, this does not allow
identification between blockchain forks building upon the same genesis
block. While many see this as undesirable, I think it is inevitable that
this will eventually happen at some point, and think it is best to build
systems redundantly.
I propose identifying blockchains for BIP 21 and any other relevant needs
through:
1) the genesis block hash for a new chain, or
2) a hash of the genesis block hash, concatenated with block hash(es) of
fork point(s) for a fork chain
This would support forks, forks of forks, forks of forks of forks, etc
while preserving a fixed length chain identifier.
If a user wants to specify "whatever chain is the longest with PoW", they
would use (1). In times where multiple chains are coexisting and being
actively mined, a user can use (2) to specifically identify a chain.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/286e722a/attachment.html>