On Mon, Mar 27, 2017 at 08:32:07AM -0500, Chris Stewart wrote:
> >I quite agree, and I would add that sometimes making yourself
> recognisable is far more important that merit.
>
> The intent of my original proposal allows you to reveal yourself *after*
> the BIP has been accepted if you so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/27/2017 12:22 PM, Suhas Daftuar via bitcoin-dev wrote:
> Eric Voskuil wrote:
>
>> Given the protocol requirements of the segwit proposal this is
>> not the case. A miner running pre-segwit code will produce
>> blocks that no segwit node will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote:
> For some time now the relation between block size and propagation
> speed has been decoupled. Using xthin/compact blocks miners only
> send a tiny version of a block which then causes the
Just to expand a tiny bit here, while the testnet setup of only a few nodes
acting as "bridges", mainnet already has many systems which act as effective
bridges today - there are several relay networks in use which effectively
bypass the P2P network, including my legacy relay network (which
Hi,
There have been two threads recently that have made references to
peer-to-peer implementation details in Bitcoin Core's Segregated Witness
code that I would like to clarify.
In the thread "Issolated Bitcoin Nodes" (
For some time now the relation between block size and propagation speed has
been decoupled. Using xthin/compact blocks miners only send a tiny version
of a block which then causes the receiving node to re-create it using the
memory pool. Immediately getting double benefits by including
Yes, the terminology is creating a lot of confusion. I would be happy to
contribute to a discourse that helps to clear up the ambiguities and
cringeworthiness of current "standardized terminology".
Robert Keagen developed a perspective on psychological development [1] and
it appears to me that
What you are describing is described here too:
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf (again, at
very draft and somewhere misleading state)
I don't think that the rewards should depend on subsequent chains built
on top of the main one, it should be handled by the main chain
Bitcoin chooses the "best chain" based upon the one that has the most
cumulative proof of work behind it. Are you proposing that the cumulative
proof of work be ignored if two blocks are within a certain threshold of
each others' work and if so, the number of transactions in the block / the
size
Add a preference for mined blocks to be the one with more transactions. This
comes into play when 2 blocks of the same height are found. The first good
block mined would be orphaned if it had less transactions than another.
Optionally, have this rule apply to the current block and the previous
On Sat, Mar 18, 2017 at 07:15:09PM +, Luke Dashjr via bitcoin-dev wrote:
> On Saturday, March 18, 2017 3:23:16 PM Chris Stewart via bitcoin-dev wrote:
> > There is inconvenience added here. You need to make a new email address,
> > you need to make a new github account to submit the BIP.
>
>
Martin:
Re: Miners not relaying unconfirmed txs... I was saying that this was a good
thing from your perspective in wanting to give users the choice on which miners
would get to confirm the tx. So then like we don't need to implement any kind
of special bloated transaction that is only
Le 27/03/2017 à 00:15, Eric Voskuil via bitcoin-dev a écrit :
> On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
>
>
>
> The repeated use of the term "network upgrade" in place of the
> accepted technical term (hard fork) is misleading. This and the
> presupposition that the hard fork is
13 matches
Mail list logo
