Re: [bitcoin-dev] Height based vs block time based thresholds

Just as an implementation consideration, time basis creates complexity. There are no other reasons to index by time, but many to index by height. The time-based activation window of BIP9 forces nodes to either index by time or scan the chain. e > On Jul 6, 2017, at 10:20 AM, Jorge Timón via bi

Re: [bitcoin-dev] Introducing a POW through a soft-fork

If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qual

Re: [bitcoin-dev] Centralizing mining by force

It is not the case in practice that there exists no incentive to disrupt the market for transaction confirmation. Statism is profitable, and a primary source of revenue is seigniorage. Given Bitcoin's threat to that privilege, its destruction presents a hefty incentive. The security model of Bi

Re: [bitcoin-dev] Introducing a POW through a soft-fork

rule. What matters in the proposal is that people who do adopt it are well aware of its ability to split them from the existing economy. e >> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev >> wrote: >> If a block that would be discarded under previous rules beco

Re: [bitcoin-dev] BIP Idea: Marginal Pricing

On 11/29/2017 10:13 PM, William Morriss via bitcoin-dev wrote: > On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester > wrote: > > Something similar to this has been proposed in this article by Ron > Lavi, Or Sattath, and Aviv Zohar, and discussed in this bitcoin-d

Re: [bitcoin-dev] Why not witnessless nodes?

> On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev > wrote: > > Dear list, > > I find it hard to understand why a full node that does initial block > download also must download witnesses if they are going to skip verification > anyway. Why run a full node if you are not going to v

Re: [bitcoin-dev] Why not witnessless nodes?

You can't know (assume) a block is valid unless you have previously validated the block yourself. But in the case where you have, and then intend to rely on it in a future sync, there is no need for witness data for blocks you are not going to validate. So you can just not request it. However

Re: [bitcoin-dev] Why not witnessless nodes?

But it would >> be a great disservice to the network for nodes intending to serve SPV >> clients to prune this portion of the block history. >> >> >>> On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev >>> wrote: >>> >>> You

Re: [bitcoin-dev] Proposal to reduce mining power bill

The energy cost of mining cannot be reduced, nor is it rational to consider it “too high”. e > On Jan 18, 2018, at 06:34, Enrique Arizón Benito via bitcoin-dev > wrote: > > Thanks "nullius" for your remarks. Notice my first post was not an RFC but > just a blur idea to inspect if something s

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

All other things being equal, the money with the larger network is more useful due to the cost of exchange between them, which can only be eliminated by one absorbing the network of the other. According the Thiers’ law (i.e. in the absence of currency controls), the more useful money will get us

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

This is true but confuses people because obviously miners must commit capital to mining before any block space can exist to have value. The reason for the misunderstanding is that miners don’t simply respond, they anticipate. All production, and therefore capital investment, is the result of ant

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

On 01/22/2018 04:38 PM, Chaofan Li via bitcoin-dev wrote: > Miners are most likely to be  equally distributed between the two almost > same chains. This is irrelevant as miners don't determine the utility of a money, they anticipate it. However you don't have to accept this to recognize the error

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

The OP premise is flawed: https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy as is the idea that side fees are incentive incompatible: https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy e On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote: > Not incentive

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

Miners accept less than the optimal (i.e. highest net fee) set of transactions all the time. The reason is that it takes too much time to compute the optimal set. All other things being equal, the miner who is more efficient at computing a set is more profitable. Intentionally not accepting the mo

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

Your statements contradict each other. This is not a question of whether it is a "huge" cost, but whether there is an problem of incentive compatibility, which there is not. Miners incur the opportunity cost of the space that they mine that does not include the most optimal fees, which is equal in

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

On 01/29/2018 01:22 PM, Gregory Maxwell wrote: > On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev > wrote: >> I'm not sure who cooked up this myth about miners gaining advantage over >> those who buy block space by mining empty space, rejecting higher-fee

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

On 01/29/2018 05:59 PM, Gregory Maxwell wrote: > On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil wrote: >> Block space created by a miner is property that belongs to the miner, it >> can be sold or not sold. > > That case would be stronger when there is no more subsidy, but we > collectively the u

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: > I define a buried deployment as a consensus rule change that affects > validity of blocks that are buried by a sufficiently large number of > blocks in the current valid most-work chain, Sufficient for what, specifically? > but the curr

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

As a soft fork, all preceding rules remain in effect. No rule has been “replaced”. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block. e > On Feb 18, 2018,

Re: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data?

If the new rule is more restrictive the original limit remains. e On Feb 18, 2018, at 11:04, rha...@protonmail.com wrote: >> No rule has been “replaced”. > > It really has been. The code is no longer checks the size of a block, but the > weight of it. For all intents and purposes the block siz

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

On 02/18/2018 10:57 AM, Marco Falke via bitcoin-dev wrote: >> They also do not require software coordination. Therefore, why should there >> be >> BIPs at all? Seems to me that we should instead add these documents to >> https://github.com/bitcoin-core/docs > > Consensus is not trivial. I think d

[bitcoin-dev] version.relay behavior change

/Satoshi:0.15.0/ and later nodes appear to be no longer honoring the version.relay=false flag (BIP37). Could someone familiar with the change please explain the rational? Thanks, e signature.asc Description: OpenPGP digital signature ___ bitcoin-dev

Re: [bitcoin-dev] version.relay behavior change

e, can you provide specific details on how to reproduce? > > Andrew > >> On 03/09/2018 02:50 AM, Eric Voskuil via bitcoin-dev wrote: >> /Satoshi:0.15.0/ and later nodes appear to be no longer honoring the >> version.relay=false flag (BIP37). Could someone familiar

Re: [bitcoin-dev] version.relay behavior change

shi:0.15.0 nodes and not a >>> node that has simply set their user-agent to that (i.e. not a real >>> Satoshi:0.15.0 node)? >>> >>> If what you are seeing is true, it is likely a bug and not an intentional >>> change. In that case, can you provide

Re: [bitcoin-dev] feature: Enhance privacy by change obfuscation

> This would be really expensive for the network due to the bloat in UTXO size, > a cost everyone has to pay for. Without commenting on the merits of this proposal, I’d just like to correct this common misperception. There is no necessary additional cost to the network from the count of unspent

Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?

https://github.com/libbitcoin/libbitcoin/wiki/Other-Means-Principle >> On Mon, Jun 18, 2018 at 11:39 AM Артём Литвинович via bitcoin-dev >> wrote: >> Dilution is a potential attack i randomly came up with in a Twitter >> arguement and couldn't find any references to or convincing arguments of i

Re: [bitcoin-dev] Capping the size of locators [trivial protocol change BIP]

Libbitcoin has implemented a 11 + log2(height) limit since version3 for this reason. This message can be very costly if not constrained. The presumed protocol inherently limits valid locator size for a given recipient. IMO it's worth considering instead describing the expected semantics of the mes

Re: [bitcoin-dev] Building a Bitcoin API and query system.

https://libbitcoin.org > On Aug 28, 2018, at 10:34, Blockchain Group via bitcoin-dev > wrote: > > Thanks, I'll check it out. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-

Re: [bitcoin-dev] Building a Bitcoin API and query system.

The API implementation is not what is centralizing, nor is full indexation non-scalable. The centralization is in not running the API from a node under your own control. This is of course implied by the comment, “without the need for syncing”. In other words it is the deployment cost of the node

Re: [bitcoin-dev] Building a Bitcoin API and query system.

You have created a straw man. And light clients working against the P2P network (anonymous nodes) implies they are not fully validating, so you are contradicting yourself. e > On Aug 29, 2018, at 11:27, Jonas Schnelli wrote: > > >> The API implementation is not what is centralizing, nor is f

Re: [bitcoin-dev] Overhauled BIP151

Without commenting on the other merits of either proposal, the addition of the service flag resolves bip151’s previously-discussed lack of backward compatibility. e > On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev > wrote: > > Hi > > During work on the implementation of BIP151 [1]

Re: [bitcoin-dev] Selfish Mining Prevention

Hash rate cannot get “more uneconomical”. Mining will always seek a return equal to the cost of capital, as does all production, and the energy expended will always be fundamentally a function of the fee level and energy price. Fee level is determined by variable demand for a fixed supply of con

Re: [bitcoin-dev] Selfish Mining Prevention

> Also with merge mining and proof of space we can be quite efficient in the > future. Proof of memory (space) is just proof of work with extra steps. It does not reduce energy consumption. https://github.com/libbitcoin/libbitcoin/wiki/Proof-of-Memory-Facade Merge mining is non-dedicated cost,

Re: [bitcoin-dev] Selfish Mining Prevention

> Once hashrate gets large enough, no new miners (additional hashrate) will want to join since their share of the hashrate is too small to make a profit. The share (hash power) of a miner is proportional to capital investment, not the newness of that investment. The efficiency of a new mine (incl

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

>> On Mar 7, 2019, at 19:09, Wilmer Paulino via bitcoin-dev >> wrote: >> ... >> Nodes on the network can not generally be trusted to send valid ("reject") >> messages, so this should only ever be used when connected to a trusted node. > > Nodes in the network generally rely on the assumption

Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)

On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote: > Proposal: > > >   BIP: ??? >   Layer: Peer Services >   Title: Version 2 Peer-to-Peer Message Transport Protocol >   Author: Jonas Schnelli >   Status: Draft >   Type: Standards Track >   Created: 2019-03-08 >   License: PD > > >

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

Hi Tamas, There are a number of economic assumptions contained herein. While I understand you would like to focus on implementation, the worst bugs are requirements bugs. IMO these should be addressed first. I’ve addressed some possible issues inline. > On Jun 28, 2019, at 01:27, Tamas Blummer

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jun 28, 2019, at 12:21, Tamas Blummer wrote: > > Hi Eric, > > Thank you for your questions as they show what concepts need further > explanation, so you understand the potential of this proposal and how it is > helpful to the ecosystem. > > Riskless zero bond is in fact the most basic c

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jun 30, 2019, at 03:56, Tamas Blummer wrote: > > Hi Eric, > >> On Jun 29, 2019, at 23:21, Eric Voskuil wrote: >> >> What loan? Alice has paid Bob for something of no possible utility to her, >> or anyone else. >> > > Coins encumbered with the described covenant represent temporary con

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins? The meaning in terms of Bitcoin is clear - the “owner” of outputs that represent value (i.e. in the ability to trade them for something else) is recorded publicly and, given Bitco

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

ICO tokens can be traded (indefinitely) for other things of value, so the comparison isn’t valid. I think we’ve both made our points clearly, so I’ll leave it at that. Best, Eric > On Jun 30, 2019, at 12:55, Tamas Blummer wrote: > > >> On Jun 30, 2019, at 20:54, Eric Voskuil wrote: >> >> C

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

It’s an exceedingly poor example. First, value is subjective. It matters not what other people may consider, only those who act. Given that people trade them (ICO tokens), they have value to those people. Second, the scenario would not function given that the value, as with money, is based on th

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 2, 2019, at 00:08, Tamas Blummer wrote: > > >> On Jul 1, 2019, at 20:52, Eric Voskuil wrote: >> >> I said that I would make no further comment given the belief that no new >> ideas were surfacing. However, after giving it some more thought on my own, >> I believe I have found the o

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

Hi ZmnSCPxj, Generalizing a bit this appears to be the same with one exception. The amount of encumbered coin is relevant to an external observer. Of course the effective dust limit is the maximum necessary encumbrance otherwise. In the case of simple tracking, the market value of the coin is n

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 4, 2019, at 12:10, Tamas Blummer wrote: > > Hi Eric, > > there are some other ways to impose cost on use without direct billing, e.g.: > > - Burn Bitcoins to use the service, as you mentioned. This could work and > would benefit remaining Bitcoin owner, but is unsustainable. Burnin

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 4, 2019, at 12:10, Tamas Blummer wrote: > > Hi Eric, > > there are some other ways to impose cost on use without direct billing, e.g.: > > - Burn Bitcoins to use the service, as you mentioned. This could work and > would benefit remaining Bitcoin owner, but is unsustainable. > > -

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 4, 2019, at 21:05, ZmnSCPxj wrote: > > Good morning Eric, > >> As with Bitcoin mining, it is the consumed cost that matters in this >> scenario, (i.e., not the hash rate, or in this case the encumbered coin face >> value). Why would the advertiser not simply be required to burn .1 co

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 5, 2019, at 12:27, Eric Voskuil wrote: > > >> On Jul 4, 2019, at 21:05, ZmnSCPxj wrote: >> >> Good morning Eric, >> >>> As with Bitcoin mining, it is the consumed cost that matters in this >>> scenario, (i.e., not the hash rate, or in this case the encumbered coin >>> face value)

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 5, 2019, at 16:16, ZmnSCPxj wrote: > > Good morning Eric, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, July 6, 2019 3:27 AM, Eric Voskuil wrote: > >>> On Jul 4, 2019, at 21:05, ZmnSCPxj zmnsc...@protonmail.com wrote: >>> Good morning

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 5, 2019, at 17:17, ZmnSCPxj wrote: > > Good morning Eric, > >> But it’s worth noting that early recovery of the UTXO entirely eliminates >> the value of the time lock cost to the ad market. The most obvious example >> is one encumbering the coin to himself, then releasing it with hi

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 5, 2019, at 18:28, Eric Voskuil wrote: > > > >> On Jul 5, 2019, at 17:17, ZmnSCPxj wrote: >> >> Good morning Eric, >> >>> But it’s worth noting that early recovery of the UTXO entirely eliminates >>> the value of the time lock cost to the ad market. The most obvious example >>>

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 6, 2019, at 06:34, Tamas Blummer wrote: > > Hi Eric, > >> On Jul 6, 2019, at 03:28, Eric Voskuil wrote: >> >> >> >>> On Jul 5, 2019, at 17:17, ZmnSCPxj wrote: >>> >>> Good morning Eric, >>> But it’s worth noting that early recovery of the UTXO entirely eliminates the

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

> On Jul 6, 2019, at 03:12, Tamas Blummer wrote: > > >> On Jul 6, 2019, at 01:16, ZmnSCPxj wrote: >> >> Good morning Eric, >> >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil wrote: >> On Jul 4, 2019,

Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve

I have published a summary here: https://github.com/libbitcoin/libbitcoin-system/wiki/Risk-Free-Return-Fallacy Barring any new consequential inputs I’ll refrain from further comment. e ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev > wrote: > > Hi ZmnSCPxj, > > I'm based on the more evolved implementation of PoS that I know, which is PoS > v3.0 and it's currently implemented in several coins: > > http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-pr

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

> On Jul 18, 2019, at 20:45, ZmnSCPxj wrote: > > Good morning Kenshiro, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ >> On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote: >> >> Hi all, >> > A 51% attack under proof-of-work is only possible, in gen

Re: [bitcoin-dev] Burying CSV and segwit soft fork activations

Thanks for adding this to the record. And for the record I’ll reiterate here, as I did with BIP90, that this is a hard fork. e > On Aug 16, 2019, at 12:06, Peter Todd via bitcoin-dev > wrote: > >> On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote: >> Once a consens

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

As this is a P2P protocol change it should be exposed as a version increment (and a BIP), not just as a conditional service. If the intent is to retain this protocol indefinitely, exposing it conditionally, then a service bit would make sense, but it remains a protocol change. BIP61 is explicit

Re: [bitcoin-dev] Trustless hash-price insurance contracts

Hi Lucas, I would question the assumption inherent in the problem statement. Setting aside variance discount, proximity premium, and questions of relative efficiency, as these are presumably already considered by the miner upon the purchase of new equipment, it’s not clear why a loss is assumed

Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)

I agree, thanks. FWIW I’ve never been a fan of the ‘reject’ message, or its implementation. https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 e > On Oct 18, 2019, at 18:46, David A. Harding wrote: > > On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-dev wro

Re: [bitcoin-dev] Trustless hash-price insurance contracts

d this would increase bitcoins > security. > > -JW > > > > > ‐‐‐ Original Message ‐‐‐ >> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev >> wrote: >> >> Hi Lucas, >> >> I would question the assumption inhe

Re: [bitcoin-dev] Trustless hash-price insurance contracts

ntial loss by buying insurance for this >>> possibility. >>> And the existence of attractive insurance contracts would lower the barrier >>> to entry for new competitors in mining and this would increase bitcoins >>> security. >>> -JW >>> ‐‐‐

Re: [bitcoin-dev] Trustless hash-price insurance contracts

if the >> >>> hash rate increases more than he expected. >> >> >> >> This is a restatement of the assumption I questioned. Hash rate increase >> >> does not imply unprofitability. The new rig should be profitable. >> >> >> >> W

Re: [bitcoin-dev] Trustless hash-price insurance contracts

in the >>>> > event of an accident, but if it is cheap enough you would. And there may >>>> > be people that are unwilling to take the risk of a damaged car that >>>> > refrain from becoming drivers until insurance allows them to lower the >&

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev > wrote: > > On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev > wrote: >> In the current draft, witness v1 outputs of length other >> than 32 remain unencumbered, which means that for now such an >> insertion

Re: [bitcoin-dev] Block solving slowdown question/poll

Mining is a lottery. e > On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev > wrote: > >  > There seems to be the real possibility that miners are simply trying to > optimise mining profit by limiting the average hash rate during the > retargeting, saving some electri

[bitcoin-dev] BIP-38 issue and altchain support

In the integration of BIP-38 into libbitcoin we ran into two issues. First, the scenario that justifies the "confirmation code" is flawed. We have implemented full support for this, but have also marked it as deprecated. I am seeking counter arguments, in case there is some scenario that we haven

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote: >> While to many of us that sounds crazy, if you're threat model assumes >> Bitcoin is a legal/regulated service provided by a highly trusted >> mining community it's a reasonable design. > > There is a large, grey area all the way to "legal/reg

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

On 09/19/2015 12:27 AM, NxtChg wrote: >> This is extremely naive. At a minimum, getting popular/successful (and >> regulated) is the formula for regulatory capture. > > Let me give you an example. > > Suppose you are a regular guy, say Peter Todd, and you are faced with 10 > policemen in anti-r

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

On 09/19/2015 12:57 AM, NxtChg wrote:> >> Your vision of censorship resistance is to become such a strong >> central authority that you can resist it in direct physical >> confrontation. If you succeed at this, you are the threat. > > My vision is a strong _decentralized_ system, which is: > > a)

Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote: > ... > Validators: Economically dependent full nodes are an important part of > Bitcoin's security model because they assure Bitcoin security by > enforcing consensus rules. While full nodes do not have orphan > risk, we also dont want mali

Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

ance and security competence of the third >> party: in the simplest case it can reduce their and their users >> security below SPV. >> >> The bigger point however, which Erik explained, was: widespread use of >> APIs as a sole means of interfacing with the blockchain als

Re: [bitcoin-dev] Libconsensus phase 2

Jorge, first, thanks again for your work on this. Without creating and using a public blockchain interface in phase 2, how will you isolate the database dependency from consensus critical code? Is it that the interface will exist but you will recommend against its use? This work presumes that the

Re: [bitcoin-dev] Libconsensus phase 2

On 01/13/2016 12:37 AM, Jorge Timón wrote: > On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote: >> Jorge, first, thanks again for your work on this. >> >> Without creating and using a public blockchain interface in phase 2, how >> will you isolate the database dependency from consensus critical

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

> A 6 month investment with 3 months on the high subsidy and 3 months on low > subsidy would not be made… Yes, this is the essential point. All capital investments are made based on expectations of future returns. To the extent that futures are perfectly knowable, they can be perfectly facto

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

On 03/02/2016 12:08 PM, Paul Sztorc wrote: > On 3/2/2016 2:01 PM, Eric Voskuil via bitcoin-dev wrote: >>> A 6 month investment with 3 months on the high subsidy and 3 months on >> low subsidy would not be made… >> >> Yes, this is the essential point. All capital in

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

On 03/02/2016 03:02 PM, Peter Todd wrote: > On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev wrote: >>> A 6 month investment with 3 months on the high subsidy and 3 months on low >>> subsidy would not be made… >> >> Yes, this is the essenti

Re: [bitcoin-dev] p2p authentication and encryption BIPs

On 03/23/2016 01:36 PM, Tom via bitcoin-dev wrote: > On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > * why would you not allow encryption on non-pre-approved connections? Agree > * we just removed (ssl) encryption from the JSON interface, how do you > suggest > this en

[bitcoin-dev] BIP 151

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it. I understand the use, when coupled with a yet-to-be-devised identity sys

Re: [bitcoin-dev] BIP 151

Hi Jonas, I'll follow up in your second reply as well. Responses inline: > On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > >> I haven't seen much discussion here on the rationale behind BIP 151. >> Apologies if I missed it. I'm trying to understand why libb

Re: [bitcoin-dev] BIP 151

continued from previous post... > On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > > Sorry for not directly addressing your points. No problem. Thanks for the detailed replies. > I try to be more precise in this follow up email: > >> I understand the use, w

Re: [bitcoin-dev] BIP 151

Hi Peter, What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected? e > On Jun 28, 2016, at 8:22 PM, Peter Todd wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: >>> 1) Tran

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: >> Hi Peter, >> >> What in this BIP makes a MITM attack easier (or easy) to detect, or >> increases the probability of one being detected? > > BIP151 gives users the tools to

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 10:36 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: >> >> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: Hi Peter, What in this BIP m

Re: [bitcoin-dev] BIP 151

> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > wrote: >> An "out of band key check" is not part of BIP151. > > It has a session ID for this purpose. Passing the session ID out of

Re: [bitcoin-dev] BIP 151

ticated encryption. Force the attackers to > use active attacks. (That are thousands times more costly to couduct). > > Sent from my iPhone > >> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev >> wrote: >> >> On Tue, Jun 28, 2016 at 9:22 PM, Eri

Re: [bitcoin-dev] BIP 151

ication. >> >> It is the implication of widespread authentication that is at issue. Clearly >> there are ways to implement it using a secure side channels. >> >>> However, let's first get unauthenticated encryption. Force the attackers to >>> use activ

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 10:06 PM, Jonas Schnelli wrote: >>> In my opinion, the question should be "why would you _not_ encrypt". >> >> 1) creation of a false sense of security > > False sense of security is mostly a communication issue. > BIP151 does focus on encryption (not trust). > > Are users

Re: [bitcoin-dev] BIP 151

On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev wrote: >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features > > This is a bit of a strawman, you've selected a single narrow usecase which > isn't proposed

Re: [bitcoin-dev] BIP 151

>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote: >> >> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote: >> Passing the session ID out of band is authentication. As this is explicitly >> not part of BIP151 it cannot be that BIP151 provides the tools to detect a >> attack (the point

Re: [bitcoin-dev] BIP 151

On Jun 29, 2016, at 3:01 AM, Gregory Maxwell wrote: > >> On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: >> I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as >> its justifying scenario. > > It cites SPV as an example, doesn't mention bloom filters.. and sure--

Re: [bitcoin-dev] BIP 151

9, 2016, at 1:17 PM, Alfie John wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: >>> then we should definitively use a form of end-to-end encryption between >>> nodes. Built into the network layer. >> >> Widespread application o

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:20 PM, Jonas Schnelli wrote: > > >> Yes, this is exactly what I meant. The complexity of the proposed >> construction is comparable to that of Bitcoin itself. This is not itself >> prohibitive, but it is clearly worthy of consideration. >> >> A question we should ask

Re: [bitcoin-dev] BIP 151

Pieter, these are in my opinion very reasonable positions. I've made some observations inline. > On Jun 30, 2016, at 3:03 PM, Pieter Wuille wrote: > > On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev > wrote: >> The proliferation of node identity is my

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: > The core problem posed by BIP151 is a MITM attack. The implied solution (BIP151 + authentication) requires that a peer trusts that another is not an attacker. >>> >>> BIP151 would increase the risks for MITM attackers. >>>

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 6:52 PM, Peter Todd wrote: > >> On Thu, Jun 30, 2016 at 05:22:08PM +0200, Eric Voskuil via bitcoin-dev wrote: >> >>> On Jun 30, 2016, at 2:43 PM, Jonas Schnelli wrote: >>> >>>>>> The core problem posed by BIP151

Re: [bitcoin-dev] BIP 151

> On Jun 30, 2016, at 9:06 PM, Peter Todd wrote: > > On Thu, Jun 30, 2016 at 08:25:45PM +0200, Eric Voskuil wrote: >>> To be clear, are you against Bitcoin Core's tor support? >>> >>> Because node-to-node connections over tor are encrypted, and make use of >>> onion >>> addresses, which are s

Re: [bitcoin-dev] Completing the retirement of the alert system

ACK libbitcoin defines the message and includes the public key but only for completeness and reference purposes. It has never been used in the node. e > On Sep 9, 2016, at 5:42 PM, Gregory Maxwell via bitcoin-dev > wrote: > > The alert system was a centralized facility to allow trusted parti

Re: [bitcoin-dev] Start time for BIP141 (segwit)

If somebody is not "running their own validation code" then they aren't actually using Bitcoin, so their ease in transition is irrelevant. For all they know they are accepting random numbers. e > On Oct 16, 2016, at 9:35 AM, Gavin Andresen via bitcoin-dev > wrote: > >> On Sun, Oct 16, 2016

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

NACK Horrible precedent (hardcoding rule changes based on the assumption that large forks indicate a catastrophic failure), extremely poor process (already shipped, now the discussion), and not even a material performance optimization (the checks are avoidable once activated until a sufficientl

  1   2   3   >