Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How

Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

Real quick (I've received some off-list replies and do plan to respond to those), want to be clear: this thread is not meant to be interpreted as a proposal to modify Bitcoin (it is not a BIP), it is just, exactly as the subject says, some thoughts I had that I hadn't seen expressed elsewhere, t

[bitcoin-dev] Some thoughts on removing timestamps in PoW

Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect@mastodon.social

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

If the new rule is more restrictive the original limit remains. e On Feb 18, 2018, at 11:04, rha...@protonmail.com wrote: >> No rule has been “replaced”. > > It really has been. The code is no longer checks the size of a block, but the > weight of it. For all intents and purposes the block siz

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

> No rule has been “replaced”. It really has been. The code is no longer checks the size of a block, but the weight of it. For all intents and purposes the block size limits has been replaced in favor of a block weight limit. It's just been designed such that the new rule is more restrictive th

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

As a soft fork, all preceding rules remain in effect. No rule has been “replaced”. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block. e > On Feb 18, 2018,

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

> They also do not require software coordination. Therefore, why should there be > BIPs at all? Seems to me that we should instead add these documents to > https://github.com/bitcoin-core/docs Consensus is not trivial. I think documentation is important, even if it seems simple to some. Personall

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

Effectively yes. The discount on weight applies to the witness data. On Feb 18, 2018 11:42 AM, "CANNON via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I have a question in reference to the increased blockspace enabled > by t

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. So as such, there's not two separate limits or anything. P.S.

[bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have a question in reference to the increased blockspace enabled by the segregated witness upgrade. Is this extra blockspace beyond the legacy 1 MB limit limited to just witness data? - -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Pardon my unproffesional tone in my original comment. But thank you for passing on these corrections. This looks much better. I have a few comments that might lend to making this even more accurate or complete. It is nice to see Bitcoin Cash use the