Sorry this was meant for the list:
There are only 32 bits in the version field. If you're going to spend a bit
for perpetuity to indicate whether or not a feature is active, you'd better
have a good reason to make that feature optional.
I haven't seen a compelling use case for having BIP 68 be op
Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with more
than one increment? This would leave additional space for future
signaling, or allow, for example, high
A power of 2 would be far more efficient here. The key question is how long
of a relative block time do you need? Figure out what the maximum should be
( I don't know what that would be, any ideas?) and then see how many bits
you have left over.
On Aug 23, 2015 7:23 PM, "Jorge Timón" <
bitcoin-dev@
On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev
wrote:
> On 8/21/2015 5:01 PM, Peter Todd wrote:
>>
>>> I checked the scenario where only the radio is on, and found the car
>>> does not crash.
>> Incidentally, what's your acceptable revenue difference between a small
>> (1% hashing po
On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
wrote:
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> discussion has any thought been given to represent one block with more
> than one increment? This would leave additional space for future
> signaling, or al
On Mon, Aug 24, 2015 at 12:25 AM, Tom Harding via bitcoin-dev
wrote:
> ack no inversion. This can actually allow more direct preservation of
> existing semantics.
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html
I can't follow this logic. Can you help? The existin
ack no inversion. This can actually allow more direct preservation of
existing semantics.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html
On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote:
> I am indifferent on this issue (the bit inversion), but so far on
On 8/21/2015 5:01 PM, Peter Todd wrote:
>
>> I checked the scenario where only the radio is on, and found the car
>> does not crash.
> Incidentally, what's your acceptable revenue difference between a small
> (1% hashing power) and large (%30 hashing power) miner, all else being
> equal? (remember
That guy is going to easily make back his 150 BTC with interest, if he
is short BTC. Should be a clear signal for the market to trend lower,
probably below $180 by the time of the test.
On 23 August 2015 at 19:08, jl2012 via bitcoin-dev
wrote:
> Someone is going to burn 150BTC to create a backlog
While I like the idea of voting on the block size debate... Why is this
vote limited to miners only?
I would prefer to see a vote by owners/holders of bitcoin, not miners of
bitcoin.
If miners with 10%+ hashrate are the only ones who get to vote... bitcoin
development is an oligarchy
My 2cents
Someone is going to burn 150BTC to create a backlog of 30-day in
September.
https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/
However, the money could be spent more wisely by encouraging mining of
the first few big blocks
Assumptions:
1. OP_CSV
Some comments:
"(i) remove any possibility of free transactions unless
associated with basic transaction data;"
I believe it is not possible to prevent free transactions for the
reason that people can pay out of band (via existing banking transfers
to miners) or make payments to addresses belong
I apologize, I'm not familiar with technical details, may be stupid,
only general thoughts:
-overlapped block sizes - two blockchains, uncertainty, unpredictable
results, trust gets down
-non-overlapped - single blockchain, determined growing, everybody
knows the schedule what and when will happen
13 matches
Mail list logo
