Jorge, I'll be happy to discuss with you more about whether allowing
ASICBoost would actually secure the network more or not, but that's not my
main motivation. My main motivation is to get more miners to accept segwit.
The version bit usage part, I don't believe requires any code changes as
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
wrote:
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I make
g via bitcoin-dev schreef op ma 10-04-2017 om 20:39 [-0600]:
>
> However, we need to consider the environmental impact of mining, which
> currently consumes a quite exorbitant amount of energy. Any ideas on
> this front?
Everything is relative. Some months ago I did some investigation and
I've changed the proposal so only 8 bits are given to grinding so something
like 20 bits are available for signaling.
I have to say I'm at a loss here as to what's next? Should I make a new BIP
or try to convince the authors of BIP141 to modify their BIP? Could someone
inform me on the next part
Tom Zander wrote:
> The version field is still needed to actually allow future block version
> upgrades. We would cut off our road forward if that were to be blocked.
I tend to agree, if all 32 bits were given up to grinding.
But it's worth pointing out that BIP9 is purely informational, and
Hi,
The link below includes documentation about a proposed CSV-based file format
for fork deployment data (tentative config filename: forks.csv). This is
planned to be used by my reference implementation of bip-genvbvoting (which is
still in development - TBA later).
Other BIP9 improvement
The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:
> It's not the headers/tx-hashes of the blocks that I'm referring to, it
> is the confirmation and spend information relative to all txs and all
> outputs for each branch. This reverse navigation (i.e. utxo
> information) is essential, must be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/11/2017 01:43 AM, Tomas wrote:
> Splitting transactions only happens *on storage* and is just a
> minor optimization compared to storing them in full.
Ok
> Sure, we can still call switching tips a "reorg". And it is indeed
> a trade off as
> I completely agree that it will be in the long term interest of bitcoin to
> migrate, gradually, toward a commoditized POW away from the current mass
> centralization. There is a big problem here though: Hundreds of millions of
> dollars have been spent on the current algorithm, and will be a
On Tue, Apr 11, 2017, at 03:44, Eric Voskuil wrote:
> As I understand it you would split tx inputs and outputs and send them
> independently, and that you intend this to be a P2P network
> optimization - not a consensus rule change. So my comments are based
> on those inferences. If we are
The version field is still needed to actually allow future block version
upgrades. We would cut off our road forward if that were to be blocked.
On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote:
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
>
Makes sense. I would love if GPUs were back as the main hashing tool.
However, we need to consider the environmental impact of mining, which
currently consumes a quite exorbitant amount of energy. Any ideas on this front?
--
Garrett MacDonald
+1 720 515 2248
g...@cognitive.ch
GPG Key
On Apr
13 matches
Mail list logo