Praxeology Guy,
On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
wrote:
> TLDR Unless I'm missing something, your claim that a
> misconfiguration would result in a stop chain is wrong because BIP9
> only works on soft forks.
If our rule change timing is different from changes on the chain with
mo
Praxeology Guy,
Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their money more vulnerable to 51% attack?
>
Certainly, if only one company made use of the extra nonce spac
Jimmy Song,
Why would the actual end users of Bitcoin (the long term and short term owners
of bitcoins) who run fully verifying nodes want to change Bitcoin policy in
order to make their money more vulnerable to 51% attack?
If anything, we would be making policy changes to prevent the use of pa
On Fri, Apr 7, 2017 at 9:14 PM, Tomas wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.
Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protoco
I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/07/2017 02:44 PM, Tomas via bitcoin-dev wrote:
> Hi Eric,
>
> On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
>> Optimization for lower memory platforms then becomes a process
>> of reducing the need for paging. This is the
Hi,
1 comment below
On Fri, 7 Apr 2017 17:52:17 -0300
Sergio Demian Lerner via bitcoin-dev
wrote:
>
> BIP: TBD
> Layer: Consensus
> Title: Inhibiting a covert optimization on the Bitcoin POW function
> Author: Sergio Demian Lerner
> Status: Draft
> Type: Standards Track
> Created
Hi Eric,
On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
> Optimization for lower memory platforms then becomes a process of
> reducing the need for paging. This is the purpose of a cache. The seam
> between disk and memory can be filled quite nicely by a small amount
> of cache
Answering both,
On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev
wrote:
>>
>> I'm still lost on this-- AFAICT your proposals long term resource
>> requirements are directly proportional to the amount of
>> unspent output
>> data, which grows over time at some fraction of the
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert optimization on the Bitcoin POW function
Author: Sergio Demian Lerner
Status: Draft
Type: Standards Track
Created: 2016-04-07
License: PD
==Abstract==
This proposal inhibits the covert use of a known optimization in Bitcoin
P
Hey everyone, This is an idea that I had about Segwit and Gregory's
proposal from yesterday that I wanted to run by everyone on this list. I'm
not at all sure what this would mean for non-upgraded nodes on the network
and would like feedback on that. This is not a formal BIP as it's a
modification
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/07/2017 11:39 AM, Bram Cohen via bitcoin-dev wrote:
> Expanding on this question a bit, it's optimized for parallel
> access, but hard drive access isn't parallel and memory accesses
> are very fast, so shouldn't the target of optimization be a
On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
wrote:
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.
Only with the additional commitment structure such as those
On Apr 6, 2017 6:31 PM, "Tomas via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Bitcrust just uses a *transaction-index*, where outputs can be looked up
regardless of being spent.
A network in which many nodes maintain a transaction index also enables a
class of light node appl
Expanding on this question a bit, it's optimized for parallel access, but
hard drive access isn't parallel and memory accesses are very fast, so
shouldn't the target of optimization be about cramming as much as possible
in memory and minimizing disk accesses?
On Fri, Apr 7, 2017 at 11:18 AM, Grego
On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
wrote:
>As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),
> updates to the protocol addressing the UTXO growth, might not be worth
> considering
Ryan Grant,
TLDR Unless I'm missing something, your claim that a misconfiguration would
result in a stop chain is wrong because BIP9 only works on soft forks.
Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you
want to make a hard fork, there is not much point in waiti
Thank you,
The benches are running in Google Cloud Engine; currently on 8 vCPU
32gb, but I tend to switch hardware regularly.
Roughly, the results are better for Bitcrust with high end hardware and
the difference for total block validations is mostly diminished at 2
vCPU, 7,5 gb.
Note that t
It is *not proof of stake.* when:
a) burn happens regardless of whether you successfully mine.
b) miner cannot know which tx are burns
c) the majority of burns cannot be used for mining and are simply lost
(poisson discovery distribution)
d) burn involves real risk: *every bit as much at stake *
Interesting work.
I was wondering if you could tell us what specs for the machine being used
as preliminary benchmark is here: https://bitcrust.org/results ?
I'd be interested to also see comparisons with 0.14 which has some
improvements for script validation with more cores.
On Fri, Apr 7, 2017
The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.
If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
___
bit
On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no
Thank you Marcos,
Though written in Rust, bitcrust-db is definitely usable as pluggable
module as its interface will be roughly some queries, add_tx and
add_block with blobs and flags. (Bitcrust internally uses a
deserialize-only model, keeping references to the blobs with the parsed
data).
How
shaolinfry,
Not sure if you noticed my comments on your earlier orphaning proposal... but
if you did you should already know that I really like this proposal...
particularly since orphaning valid old blocks is completely unnecessary.
I really like how you pulled out the "lockinontimeout" variab
Daniele Pinna,
Can you please not forget to supply us more details on the claims made
regarding the reverse engineering of the Asic chip?
gmaxwell told me that back even in S7 chips its possible to set the SHA256
midstate/IV instead of just resetting it to the standard SHA256 IV. This
essentia
Hi Tomas,
I've read it and think it is an excellent work, I'd like to see it
integrated into bitcoin-core as a 'kernel module'.
I see there are a lot of proof of concepts out there, IMO every one
deserve a room in the bitcoin client as a selectable feature, to make the
software more flexible and
Random misreadings of your post aside (maybe it's time to moderate this list a
bit more again), I think this is a reasonable model, and certainly more
terminology/understanding is useful, given I and many others have been making
arguments based on these differences.
One thing you may wish to fu
> Can you please not forget to supply us more details on the claims made
> regarding the reverse engineering of the Asic chip?
>
> It is absolutely crucial that we get these independently verified ASAP.
>
Bitmain confirmed that their chips support ASICBOOST and it can be used for
mining:
https://
28 matches
Mail list logo
