As I understand Andrew Chow has a patchset for height based activation
of Speedy Trial, so that it would be great if people could review that
to help increase the review-cycles.
Personally I also somewhat prefer block-height based activation, and
for myself it seems like a mild step backwards to g
Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com).
Another advantage of random access from BIP 32 vs iterated chain is
that if there is a bit-flip or corruption, you don't destroy access to
all future addresses, but only burn one utxo. Empirically not an
entirely theoretical issue.
I think the only thing i'd care about is bloating up the number o
I looked at it and consider the crypto choices reasonable and reusing
existing bitcoin dependencies in library crypto building blocks
mostly.
For myself i think the use-case of having an offline seed manager that
can be backed up once, and support multiple wallets, including ones
created after the
I think the point is to use this proposed extension/standard for a
kind of "seed management" function, set it up on an offline device (an
always offline laptop, or a modified hardware wallet) where you put
the master seed. And then you use this as a kind of seed manager and
transcript the seeds fo
Brands credentials use this single show, and multiple show
credentials. It's based on the representation problem which is the
generalisation to multiple bases where Schnorr is one base, Pedersen
Commitments are two bases, Representation problem is n>2 bases.
The method used would work for Schnorr
On Wed, Jul 11, 2018, 02:42 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Basically you're just replacing addition with interpolation everywhere in
the musig construction
Yes, but you can't do that without a delinearization mechanism to prevent
adaptive public key
Coincidentally I had thought of something similar to what Kalle posted
about a kind of software only time-lock vault, and described the idea
to a few people off-list. Re. Root incompatibility, if the key is
deleted (as it must be) then a delegated signature can not be made
that bypasses the CSV ti
Makwa sites [1] https://bitcointalk.org/index.php?topic=311000.0
Seems like they independently rediscovered it.
Adam
On 23 January 2018 at 05:54, Ondřej Vejpustek via bitcoin-dev
wrote:
>> Yes, this scheme.
>> https://bitcointalk.org/index.php?topic=311000.msg3342217#msg3342217
>
> In addition
True however in principle a soft-fork can also be soft-forked out. Eg say a
publicly known soft-fork done by miners only that user node software did
not upgrade for first by opt-in adoption. If there was consensus against by
users and ecosystem a node/user flag day soft fork could block it's
effect
The pattern used by Felix Weiss' BIP for Confidential Transactions
depends on or is tidier with 0-value outputs.
Adam
On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
wrote:
> As long as an unspendable outputs (OP_RETURN outputs for example) with
> amount=0 are still allowed I don't see i
Separate from scale, there is utility to a hard-fork to fix wish-list
bugs that cant be reasonably fixed via soft-fork. The spoonnet
proposal fixes a good number of interesting bugs. Spoonnet and
several other HF research proposals can be found here
https://bitcoinhardforkresearch.github.io/ Par
On 27 June 2017 at 22:20, Luke Dashjr via bitcoin-dev
wrote:
> On Wednesday 28 June 2017 12:37:13 AM Chris Stewart via bitcoin-dev wrote:
>> BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
>> critical hash is included at the given vout index in the coinbase
>> transacti
Also Jonas Nick gave a fairly comprehensive presentation on privacy
leaks in bitcoin protocol including SPV and bloom query problem
specifics:
https://www.youtube.com/watch?v=HScK4pkDNds
Adam
On 20 June 2017 at 14:08, bfd--- via bitcoin-dev
wrote:
> On 2017-06-20 12:52, Tom Zander via bitcoin-
See this soft-fork proposal from Felix Weiss
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
Adam
On Apr 12, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> (This is a sketch, not a fully-formed proposal, just to ki
I agree with everything Matt said. This "X+Y" "compromise" is not a
new proposal and has been hashed over multiple times in the past
dating back to at least fall 2015, ignores basically all design
considerations and research over the last years, doesn't understand
the real-politic of the delays,
I think this discussion started from the block bloom filter where
there is a bloom filter commitment in the block which can be
downloaded and is much smaller than the block. An SPV node based on
that model would download headers and bloom filters, verify the bloom
filter is committed to, and test
Well I think empirical game-theory observed on the network involves more
types of strategy than honest vs dishonest. At least 4, maybe 5 types of
strategy and I would argue lumping the strategies together results in
incorrect game theory conclusions and predictions.
A) altruistic players (protoco
Hi Gavin
It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?
Do you have a rollback plan in the event the hard-fork triggers via
false voting as
Tricky choice. On the one hand I had spotted this too before and maybe
one or two more exceptions to bitcoin's 128-bit security target and
been vaguely tut-tutting about them in the background. It's kind of a
violation of crypto rule of thumb that you want to balance things and
not have odd weak p
> I guess the same could be said about the softfork flavoured SW implementation
No, segregated witness
https://bitcoin.org/en/bitcoin-core/capacity-increases-faq is a
soft-fork maybe loosely similar to P2SH - particularly it is backwards
and forwards compatible by design.
These firm forks have th
While it is interesting to contemplate moving to a world with
hard-fork only upgrades (deprecate soft-forks), now is possibly not
the time to consider that. Someone can take that topic and make a
what-if sketch for how it could work and put it on the wishlist wiki
if its not already there.
We wan
There are a range of opinions about input assumptions by different
people. In each case, short of misunderstanding, if we have the same
input assumptions we're going to reach the same conclusions. This is
the way of the world in a meritocracy. The interesting point is to
compare the input assump
I think someone, maybe Pieter, commented on this relay issue that it
would be likely very transitory, as a lot of stuff would be fairly
quickly upgraded in practice from previous deployment experience, and
I think anyway there is a huge excess connectivity and capacity in the
p2p network vs having
I think people have a variety of sequences in mind, eg some would
prefer to deploy versionBits first, so that subsequent features can be
deployed in parallel (currently soft-fork deployment is necessarily
serialised).
Others think do seg-witness first because scale is more important.
Some want to
There is a difference between miners signalling intent (as they have
been for various BIPs, which is mostly informational only - they are
mostly not running the code, and in some cases it is not implemented,
so they cant be) there is a difference between that and a 95% miner
majority consensus rule
ation security described under
"Validators" in the OP.
Adam
On 6 November 2015 at 09:05, Chris Priest wrote:
> On 11/5/15, Eric Voskuil via bitcoin-dev
> wrote:
>> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>>> ...
>>> Validators: Economically
Some thoughts, hope this is not off-topic.
Maybe we should summarise the security assumptions and design
requirements. It is often easier to have clear design discussions by
first articulating assumptions and requirements.
Validators: Economically dependent full nodes are an important part of
Bi
About the conflicting spends by the private key holder (self signature
malleability) that is in principle kind of fixable.
You make a new pub key type which is r,Q (where r is the DSA signature
component but chosen at key gen time, Q=xG is the pub key, r is point
compressed R = (r,f(r)) = kG ), r
Does that pre-judge that block interval would never change from
10mins? Eg say with IBLT or fountain codes etc and security arguments
for the current limitations of them are found, such that orphan rates
can remain low in a decentralised way with 1min blocks, then the
locktime granularity would be
Benjamin you may want to read this reddit thread on liquid:
https://www.reddit.com/r/Bitcoin/comments/3ok69l/blockstream_to_launch_first_sidechain_for_bitcoin/
and if you feel your questions are not answered, post them there?
(This list is about bitcoin development so it's not really on topic fo
On 7 October 2015 at 18:26, Jonathan Toomim (Toomim Bros) via
bitcoin-dev wrote:
> On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote:
> If you had a 99% hashpower supermajority on the new version, an attacker
> would still be able to perform this attack once per day.
[ie wait for a non-upgraded mi
Thank you for posting that, most informative, and suggest people
arguing here lately to read it carefully.
May I suggest that people who wish to debate what rough consensus
means, to take it to this reddit thread
https://www.reddit.com/r/Bitcoin/comments/3ntga9/bitcoindev_a_brilliant_post_on_defi
Micha I think you are correct, I dont think extension blocks (or
sidechains for that matter) can allow soft-fork increase of the total
Bitcoins in the system, because the main chain still enforces the 21m
coin cap. A given extension block could go fractional, but if there
was a run to get out, the
See also
https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x
Adam
On 2 October 2015 at 10:20, Jorge Timón
wrote:
>
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev"
> wrote:
>>
>> should an algorithm that guarantees protection from A
On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev
wrote:
>> Have I missed a proposal to change BIP101 to be a real hardfork
>
> There's no such thing as a "real" hard fork - don't try and move the goal
> posts. SPV clients do not need any changes to do the right thing with BIP
> 101, they
I was talking about the versionBits from Rusty's email (pasted below) and
simplifying that by XT adopting the patch as Gavin had seemed agreeable to.
Adam
Rusty wrote:
> Agreed. Unfortunately, a simple "block version >= 4" check is
> insufficient, due to XT which sets version bits 001111.
>
I think from discussion with Gavin sometime during the montreal
scaling bitcoin workshop, XT maybe willing to make things easy and
adapt what it's doing. For example in relation to versionBits Gavin
said he'd be willing to update XT with an updated/improved
versionBits, for example.
It seems more
I wonder what Gavin's views are, he's usually constructive, and see if
he'll include it in XT - I think he may have said he was supportive.
The rationale for soft vs hard-forks is well known, so I wont go over them.
Adam
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
wrote:
> There
Bitcoin security depends on the enforcement of consensus rules which
is done by economically dependent full nodes. This is distinct from
miners fullnodes, and balances miners interests, otherwise SPV nodes
and decentralisation of policy would tend degrade, I think. Therefore
it is important that
Hi
Came across this
https://groups.google.com/forum/m/#!topic/bitcoin-xt/zbPwfDf7UoQ useful
thread discussing Bitcoin threat modelling may reach wider audience on this
list.
Text from Mike Hearn:
think the next stage is to build a threat model for Bitcoin.
This mail starts with background. If
> A selfish mining attack would have to be performed for at least 2000 blocks
> over a period of 4 weeks in order to achieve a meager 10% increase in the
> block size.
You seem to be analysing a different attack - I mean that if someone
has enough hashrate to do a selfish mining attack, then set
The maximum block-size is one that can be filled at zero-cost by
miners, and so allows some kinds of amplification of selfish-mining
related attacks.
Adam
On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
wrote:
> This is true, but miners already control block size through soft caps.
Peter this seems to be a not well thought through course of action,
fun though it maybe informally or philosophically or to tweak various
peoples sensibilities.
Bitcoin is a consensus system that does not work if there are
incompatible versions of consensus code competing on the network.
This is w
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
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.
Adam
On 19 August 2015 at 15:28, Jorge Timón
wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s
It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.
That is not at ALL the case, and is insulting (present company excluded).
It is just that no one else is reckless enough to bypass the review
proces
Thank you Eric for saying what needs to be said.
Starting a fork war is just not constructive and there are multiple
proposals being evaluated here.
I think that one thing that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
Bitcoin full-no
Hi Tamas
Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.
Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?
Adam
On 16 Au
There is a proposal that relates to this, see the flexcap proposal by
Greg Maxwell & Mark Friedenbach, it was discussed on the list back in
May:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.h
t of people who have no
> clue/don't care for decentralization, they just want to send money from A to
> B, like email.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> wrote:
>>
>> I dont think Bitcoin being che
I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin. I think the interesting thing is trustlessness - being able
to transact without relying on third parties.
Adam
On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
wrote:
> The only reason why Bitcoin has grown the
I think everyone is expending huge effort on design, analysis and
implementation of the lowest cost technology for Bitcoin.
Changing parameters doesnt create progress on scalability fundamentals -
there really is an inherent cost and security / throughput tradeoff to
blockchains. Security is quit
In terms of usage I think you'd more imagine a wallet that basically
parks Bitcoins onto channels at all times, so long as they are
routable there is no loss, and the scalability achieved thereby is
strongly advantageous, and there is even the potential for users to
earn fees by having their wallet
On 8 August 2015 at 09:54, Thomas Zander wrote:
> I didn't say off-chain, and gave an example of on-chain usecase with trusted
> middleman.
That's basically the definition of off-chain. When we say MtGox or
coinbase etc are off-chain transactions, that is because a middle man
has the private ke
If you are saying that some people are happy trusting other people,
and so would be perfectly fine with off-chain use of Bitcoin, then we
agree and I already said that off-chain use case would be a
constructive thing for someone to improve scale and interoperability
of in the post you are replying
Please try to focus on constructive technical comments.
On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
wrote:
> What will the backlash be when people here that are pushing for "off-chain-
> transactions" fail to produce a properly working alternative, which
> essentially means we have t
On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
wrote:
> the need an individual has for running a node is a completely different
> concept than the
> need for nodes to exist. And, really, you are describing miners, not nodes.
It's not as simple as trusting miners, Bitcoin security need
On 5 August 2015 at 12:51, Hector Chu wrote:
> The market I am thinking of would be open to all, not just miners. But
> miners would probably be best placed to profit from such a market, as it is
> their business to know about the revenue/costs tradeoff.
This prediction market in block-size seems
On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev
wrote:
> Miners would be uniquely placed to know how best to vary the block size to
> maximize their
> profit resulting from these two prices. [...]
> In that respect a dynamic block size voted on by miners periodically would
> go some way to
Again this should not be a political or business compromise model - we
must focus on scientific evaluation, technical requirements and
security.
But specifically as you asked a group of Chinese miners said they
would not run it:
http://cointelegraph.com/news/114657/chinese-mining-pools-call-for-c
On 3 August 2015 at 09:16, Simon Liu wrote:
> Increasing the block size shouldn't be a problem for Chinese miners.
> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
> already signed a draft agreement indicating they are fine with an
> increase to 8 MB: http://www.8btc.com/blocksi
If block-sizes are increased in a way detrimental to the Chinese miners, it
is not the Chinese miners that lose, it is all of the non-Chinese miners -
this is because the Chinese miners have the slight majority of the
hashrate. The relatively low external bandwidth connecting China to the
net is a
That's all well and fine. But the pattern of your argument I would
say is "arguing security down" ie saying something is not secure
anyway, nothing is secure, everything could be hacked, so lets forget
that and give up, so that what is left is basically no
decentralisation security.
It is not par
I think trust the data-center logic obviously fails, and I was talking
about this scenario in the post you are replying to. You are trusting the
data-center operator period. If one could trust data-centers to run
verified code, to not get hacked, filter traffic, respond to court orders
without no
That's what is nice about proposals, they are constructive and help
move the conversation forward!
On 30 July 2015 at 18:20, Gavin Andresen via bitcoin-dev
wrote:
> Specific comments:
>
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative, and the most likely effe
btw the fact that mining is (or can be) anonymous also makes oligopoly
or cartel behaviour likely unstable. Miners can break ranks and
process transactions others wish to block, or with lower fees than a
cartel would like to charge, without detection.
Anonymous mining is a feature and helps ensur
On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
wrote:
> Does an unlimited blocksize imply the lack of a fee market? Isn't every
> miner able to set their minimum accepted fee or transaction acceptance
> algorithm?
The assumption is that wont work because any miner can break ranks and
do s
I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise
I believe the idea is to replace openSSL with
https://github.com/bitcoin/secp256k1 that Pieter and Greg spent quite
some time rigorously testing and have at this point better confidence
in than *SSL libraries.
I think the lessons learned from it as concluded by Pieter and Greg
are that openSSL and
(Claim of large bitcoin ecosystem companies without full nodes) this
says to me rather we have a need for education: I run a full node
myself (intermittently), just for my puny collection of bitcoins. If
I ran a business with custody of client funds I'd wake up in a cold
sweat at night about the s
71 matches
Mail list logo
