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 choose
I don't think encouraging mining more transactions is a good idea since
it would promote inefficient transaction patterns. It's more efficient
to send transactions with a high number of outputs/inputs instead of
creating long transaction chains as some services do.
You might consider incentivi
-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 re
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 many
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" (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013765.htm
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 pre-veri
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 Stag
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
Hi I'm AJ West, I made a service http://preferredminer.com which is a
proof-of-concept project designed to spur discussion on exactly this issue
of "miners as service providers."
The current status is that Bitcoin end users are looking to support
specific miners, whether that's because they agree
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 of
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 o
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.
>
>
On Sun, Mar 19, 2017 at 11:43:12PM +, muyuu via bitcoin-dev wrote:
> If this was in place I would contribute more and I wouldn't have to create
> throw-away accounts.
>
> This is not a space where you want to be a recognisable target.
>
> Today, BitFury's CEO threatened to sue developers if t
agreed, the 'miner' term has run its course and plays a different role than it
was originally set out to do, esp its original distributed nature. the 'mining
business' has become concentrated too much and resembles today's financial
institutions or simply banks, imho.
still, any form forking h
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 mine-abl
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 co
17 matches
Mail list logo
