On Thursday, March 23, 2017 6:27:39 PM Jorge Timón via bitcoin-dev wrote:
> I think it would be clearer to put the "Creation of proofs" section
> before "Proof verification", maybe even before "Proof format" if a
> high level defintion of "full tx size proof" is provided before.
Creation of proofs
Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.
The technical
Potentially miners could create their own private communication
channel/listening port for submitting transactions that they would not relay to
other miners/the public node relay network. Users could then chose who they
want to relay to. Miners would be incentivized to not relay higher fee
tran
BIP: ???
Layer: Consensus (soft fork)
Title: Strong Anti-Replay via Coinbase Transactions
Author: Cameron Garnham
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
Status: Draft
Type: Standards Track
Created: 2017-03-25
Lice
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable time
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable time
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example
I don't think this is a good idea, mempool is different from node to node
and is not a part of the consensus.
Hampus
2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoi
Two concerns:
1) This makes block validity depend on things that aren't in the
blockchain. If you and I have different minrelaytxfee's, we will have
different mempool sizes. Your node will discard a block, but my node will
think it is valid, and our nodes will not come to consensus.
2) This is tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
When the original white paper was written the idea was that nodes
would be miners at same time. That the distribution of mining power
being mostly on par with the distribution of nodes if I understand
correctly. The problem we face now I fear, is the
