Dave Scotese [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-24 to 2022-07-11
💬 Posted a total of 72 messages
📚 Participated in the following categories: bitcoin-dev, BIP Draft, BIP/Draft, Pre-BIP, bitcoin-discuss
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8

Profile Code

nprofile1qqs28pre2vgvagvn0hdy6q0w3u2v5u6tnfatvrrzz999v4nsdc27glcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjz7ve4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8

Show more details

Last Notes

2023-06-08 01:11:26

- reply

📅 Original date posted:2022-07-11
📝 Original message:I believe it's foolish to attempt objective definitions of things that we
define collectively, like "Bitcoin." The best any one of us can do is to
be consistent with a subjective personal definition. I believe most people
do that with the term "Bitcoin" and that the capped supply is intrinsic to
their subjective definitions. It is to mine. Leading bodies, such as the
Bitcoin core team, the Ethereum foundation, and every government, are
constantly in danger of confusing objective reality with their own
decisions. Since people have autonomy, the best a leading body can do is
recommend their decisions. The common error is one made by governments,
where they react violently to defiance of the definitions they make.
Shadows of that error show up in nongovernmental leading bodies as
ostracism, criticism, and even sometimes illegal activity against such
defiance of decisions. What I mean here is that John is right in a sense
(" removing this limit results in something that can no longer be called
Bitcoin. "), but I don't think the way he expressed it is as helpful as it
could be. There are many who will not call it Bitcoin, and I am among them.
On Sat, Jul 9, 2022 at 8:13 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jul 09, 2022 at 04:57:57PM +0200, John Tromp via bitcoin-dev wrote:
> > > New blog post:
> > >
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
> >
> > A Tail Emission is best described as disinflationary; the yearly
> > supply inflation steadily decreases toward zero.
>
> _Apparently_ inflation. True monetary inflation includes lost coins - both
> intentionally and accidentally lost. It's quite possible that even with
> tail
> emission Monero is currently a monetarily deflationary coin, as the lost
> coin
> rate might be higher than the 0.8% apparent tail emission rate.
>
> We just don't know. Doubly so in the case of monero where its privacy
> features
> hide coin activity.
>
> > > If an existing coin decides to implement tail emission as a means to
> fund security, choosing an appropriate emission rate is simple: decide on
> the maximum amount of inflation you are willing to have in the worst case,
> and set the tail emission accordingly.
> >
> > Any coin without a premine starts with infinite inflation. Bitcoin in
> > its first 4 years had yearly inflation rates of inf, 100%, 50%, and
> > 33%. So deciding on a maximum amount of inflation is deciding on a
> > premine.
>
> Hence why I specified an *existing* coin.
>
> > While in the long term, a capped supply doesn't meaningfully differ
> > from un uncapped supply [1], the 21M limit is central to Bitcoin's
> > identity, and removing this limit results in something that can no
> > longer be called Bitcoin.
>
> Personally I think basing your identity on a technical point that isn't
> even
> correct is stupid. And I suspect than when push comes to shove, if in ~10
> years
> or whatever Bitcoin turns out to be unstable without a reward, the market
> as a
> whole will be happy to redefine Bitcoin to remove the 21M limit. Whether
> or not
> it can do that fast enough to avoid Bitcoin dying first is an open
> question.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/d60506ee/attachment.html>

2023-06-08 00:56:35

- reply

📅 Original date posted:2021-07-05
📝 Original message:At https://github.com/bitcoin/bitcoin/issues/22404#issuecomment-874168305
no explanation is given for a peculiar rule about estimating fees, that "you
have to wait around for a couple of blocks *after* being synced before fee
estimation will work." The rule is true, but it needn't be true, and the
software would be more useful if it were not true. If it does seem
impossible to break this rule, perhaps some brainstorming is in order. I
estimate fees quite often on my own, although I am trusting the block
explorers in their reporting of the fees for the most recent blocks. The
software doesn't need to trust anything once it has been synced.
If this is simply a matter of priorities, it would be useful to point that
out.
Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210705/cd63d653/attachment.html>

2023-06-07 20:23:28

- reply

📅 Original date posted:2020-03-22
📝 Original message:The software currently allows up to a two hour difference between the
system clock and the time implied by a fresh block's timestamp (if I
remember correctly). This reliance on realtime system clocks can be used
in a much weaker form to justify a plan for a difficulty adjustment to be
built into the software for when the expected block production rate is far
enough behind its expected value.
We would have to agree on how far behind mining should be to justify
expediting the adjustment. The sooner we decide on and implement this
second difficulty adjustment trigger, the better. It cuts off a nightmare
scenario made possible by collusion between states through regulation and
fiat, as well as any other external factors. I propose that miners
detecting that the expected 2016 blocks have not been mined after twice the
expected wait time (4032 * 10 minutes = 28 days) ought to signal their
recognition in any block they produce, to be rejected by any miner whose
clock disagrees (after taking into account the 2-hour leeway), and that any
block produced on top of one with such a signal should reflect an expedited
difficulty adjustment (and also include the signal), which is then in
effect for the rest of the 2016 blocks and the entire following difficulty
period. Every block from there until the modulo 2016 block should have the
same signal, which not only indicates that a difficulty adjustment was
expedited, but also that the next modulo 2016 block should not make one,
but rather turn off the signal.
If anyone thinks it's a good enough idea for a BIP, I will consider writing
one unless someone else wants to.
Dave.
On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mining is a lottery.
>
> e
>
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> 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 electricity but poorly considering the overall
> situation where they give opportunity to other miners probably raising the
> hashrate for the next period. It is far more profitable for the ecosystem
> considering the whole to hold a lottery for minig as has been discussed
> elsewhere some time ago.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on
> behalf of David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Sunday, 22 March 2020 6:54 PM
> *To:* Dave Scotese <dscotese at litmocracy.com>; Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll
>
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons. I'm
> > curious to know if anyone has ideas on how this might be handled
>
> There are only two practical solutions I'm aware of:
>
> 1. Do nothing
> 2. Hard fork a difficulty reduction
>
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
>
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200322/dde91e34/attachment-0001.html>

2023-06-07 20:23:27

- reply

📅 Original date posted:2020-03-21
📝 Original message:It seems that many on this list think deeply enough to imagine the scenario
where we have few days left before a difficulty adjustment comes up but we
also see mining power dropping off at a rate that suggests the few days
might become a few weeks, and then, possibly, a few months or even the
unthinkable, a few eons. I'm curious to know if anyone has ideas on how
this might be handled because I'm sure we're not going to let it happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200321/ba94cdf9/attachment-0001.html>

2023-06-07 20:17:25

- reply

📅 Original date posted:2019-04-14
📝 Original message:No piece of data that does have significance to the Bitcoin consensus can
be memorable because it occurs (about) every ten minutes. In order to get
something memorable to provide sanity (let's say, anti-sybil-attack)
checking, it has to be rare, but recurrent. The opportunity is actually
already there, but it usually goes by without providing the benefits.
For example, I found this blog post
<http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html>
by Ken Shirriff who describes artifacts that can be found in the
blockchain. These artifacts are not intimately tied to their location in
the blockchain, so anyone building an alternative blockchain can relatively
easily add the artifacts with the same timestamp and at the same height,
masking the counterfeit. In order to prevent that, the memorable thing has
to be intimately tied to work-intensive results, like the ratio of the hash
to the target. Nelson Mandela's image appearing in the blockchain does NOT
prove to me it's the blockchain I can see at blockchain.com right now, but
if the smallest block hash in that blockchain, on 12/13/13, after all the
zeroes, starts with 3da1 (144 * 65536 times as much work) and is one of the
three block hashes from that day that have two occurrences of a double-e
(about 256 times more work), then it will. The problem is that I'll
probably forget most of those details - but not that Mandela's image went
in the blockchain near the end of 2013.
On Sat, Apr 13, 2019 at 12:09 PM Peter Todd <pete at petertodd.org> wrote:
> On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > Every block's hash is smaller than the difficulty at that time. Block
> > 569927's hash was VERY small (started with 21 zeros). The ratio of block
> > hash to difficulty requirement (0xffffffff - difficulty, I think) could
> be
> > used to identify blocks as "special," thus providing the opportunity to
> > popularize unimportant but memorable-and-therefore-useful details. How
> can
> > they be useful if they are unimportant? They are useful for sanity
> > checking. For example, if the drunken bishop walk (or some other popular
> > randomart) produced by block 569927's hash looked like a face, that would
> > be memorable: "The block with the smallest hash in 2019 (maybe ever?)
> looks
> > like a face after the drunken bishop walk."
>
> As hashest smaller than the target have no significance to the Bitcoin
> consensus I'd suggest not basing any features on that property. It's just
> as
> arbitrary as picking whole decimal number block heights, yet has the
> additional
> downsides of being harder to compute, and being likely to confuse people
> as to
> how the Bitcoin consensus works.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190414/36a84972/attachment.html>

2023-06-07 20:17:23

- reply

📅 Original date posted:2019-04-03
📝 Original message:Every block's hash is smaller than the difficulty at that time. Block
569927's hash was VERY small (started with 21 zeros). The ratio of block
hash to difficulty requirement (0xffffffff - difficulty, I think) could be
used to identify blocks as "special," thus providing the opportunity to
popularize unimportant but memorable-and-therefore-useful details. How can
they be useful if they are unimportant? They are useful for sanity
checking. For example, if the drunken bishop walk (or some other popular
randomart) produced by block 569927's hash looked like a face, that would
be memorable: "The block with the smallest hash in 2019 (maybe ever?) looks
like a face after the drunken bishop walk."
If a few of these showed up each year, then Bob and/or Alice would have a
good chance of seeing that something was wrong if and when they checked.
It would not be surprising, given Ethan's assumption that the invalid block
Bob found contributed to Alice's UTXOs, that at some point, the history one
of them has would be missing the memorable things beginning at some block
height because, clearly, one of them has been forked.
Luke's comment that it could "lead to users trusting third parties (like
developers) way too much" is pertinent too, but I think an honest abatement
of that concern is impossible without teaching everyone C++. "Developers"
as an open group (anyone can fork the github repo, find a problem, and make
an issue) deserve the trust we put in them, and that's because they're
accountable (any such error found in the repo will have been put there by
someone). The same thing goes for making it possible to download (*not
just the compiled software*, but) the entire UTXO Set if a commitment of it
is hardcoded into the software, as James suggests. We all trust
"developers" like that, and it's okay. No one holds the "ring of power."
On Wed, Apr 3, 2019 at 8:39 AM Ethan Scruples via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Jonas,
>
> If we can get mandatory UTXO commitments soft forked into Bitcoin, we get
> the advantage of a non-growing IBD, which I think everyone would agree is a
> benefit that, uh, grows over time. The thing I do not see people noticing
> is that we actually pay little to no security price for this benefit.
>
> To see this, consider Alice, who starts from a UTXO snapshot made at
> current height - 50,000 and Bob who validates from genesis.
>
> After her partial validation, Alice is satisfied that she is in possession
> of the UTXO set-- she is in consensus with the rest of the network peers.
>
> However, Bob realizes that there is actually an invalid block at current
> height - 50,001.
>
> Three things to notice:
>
> 1. This scenario essentially cannot happen. There is no way that the
> miners are going to stack 50,000 blocks on top of an invalid block without
> the economic majority abandoning the invalid chain.
>
> 2. If this scenario DOES happen, Bob has learned about it too late for it
> to matter to Bob. The blockchain Bob wants to be on is the one that
> everyone has been using for the last year, whether or not it is besmirched
> by an invalid block.
>
> 3. If this scenario DOES happen, and Bob DOES want to reject the last
> 50,000 mined blocks as invalid, he may discover to his dismay that in the 1
> year since the invalid block, mischievous entities have enough time to mine
> equally weighted alternative histories from the Genesis block forward to
> the invalid block, meaning that Bob has no way to use POW to come to
> consensus with other Bobs out there.
>
> On Wed, Apr 3, 2019 at 3:33 AM Jonas Schnelli via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Thanks James for the post.
>>
>> I proposed a similar idea [1] back in 2016 with the difference of signing
>> the UTXO-set hash in a gitian-ish way.
>>
>> While the idea of UTXO-set-syncs are attractive, there are probably still
>> significant downsides in usability (compared to models with less security),
>> mainly:
>> * Assume the UTXO set is 6 weeks old (which seems a reasonable age for
>> providing enough security) a peer using that snapshot would still require
>> to download and verify ~6048 blocks (~7.9GB at 1.3MB blocks,… probably
>> CPU-days on a phone)
>> * Do we semi-trust the peer that servers the UTXO set (compared to a
>> block or tx which we can validate)? What channel to we use to serve the
>> snapshot?
>>
>> If the goal is to run a full node on a consumer device that is also been
>> used for other CPU intense operations (like a phone, etc.), I’m not sure if
>> this proposal will lead to a satisfactory user experience.
>>
>> The longer I think around this problem, the more I lean towards accepting
>> the fact that one need to use dedicated hardware in his own environment to
>> perform a painless full validation.
>>
>> /jonas
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html
>>
>> > Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org>:
>> >
>> > Hi,
>> >
>> > I'd like to discuss assumeutxo, which is an appealing and simple
>> > optimization in the spirit of assumevalid[0].
>> >
>> > # Motivation
>> >
>> > To start a fully validating bitcoin client from scratch, that client
>> currently
>> > needs to perform an initial block download. To the surprise of no one,
>> IBD
>> > takes a linear amount time based on the length of the chain's history.
>> For
>> > clients running on modest hardware under limited bandwidth constraints,
>> > say a mobile device, completing IBD takes a considerable amount of time
>> > and thus poses serious usability challenges.
>> >
>> > As a result, having fully validating clients run on such hardware is
>> rare and
>> > basically unrealistic. Clients with even moderate resource constraints
>> > are encouraged to rely on the SPV trust model. Though we have promising
>> > improvements to existing SPV modes pending deployment[1], it's worth
>> > thinking about a mechanism that would allow such clients to use trust
>> > models closer to full validation.
>> >
>> > The subject of this mail is a proposal for a complementary alternative
>> to SPV
>> > modes, and which is in the spirit of an existing default,
>> `assumevalid`. It may
>> > help modest clients transact under a security model that closely
>> resembles
>> > full validation within minutes instead of hours or days.
>> >
>> > # assumeutxo
>> >
>> > The basic idea is to allow nodes to initialize using a serialized
>> version of the
>> > UTXO set rendered by another node at some predetermined height. The
>> > initializing node syncs the headers chain from the network, then
>> obtains and
>> > loads one of these UTXO snapshots (i.e. a serialized version of the
>> UTXO set
>> > bundled with the block header indicating its "base" and some other
>> metadata).
>> >
>> > Based upon the snapshot, the node is able to quickly reconstruct its
>> chainstate,
>> > and compares a hash of the resulting UTXO set to a preordained hash
>> hard-coded
>> > in the software a la assumevalid. This all takes ~23 minutes, not
>> accounting for
>> > download of the 3.2GB snapshot[2].
>> >
>> > The node then syncs to the network tip and afterwards begins a
>> simultaneous
>> > background validation (i.e., a conventional IBD) up to the base height
>> of the
>> > snapshot in order to achieve full validation. Crucially, even while the
>> > background validation is happening the node can validate incoming
>> blocks and
>> > transact with the benefit of the full (assumed-valid) UTXO set.
>> >
>> > Snapshots could be obtained from multiple separate peers in the same
>> manner as
>> > block download, but I haven't put much thought into this. In concept it
>> doesn't
>> > matter too much where the snapshots come from since their validity is
>> > determined via content hash.
>> >
>> > # Security
>> >
>> > Obviously there are some security implications due consideration. While
>> this
>> > proposal is in the spirit of assumevalid, practical attacks may become
>> easier.
>> > Under assumevalid, a user can be tricked into transacting under a false
>> history
>> > if an attacker convinces them to start bitcoind with a malicious
>> `-assumevalid`
>> > parameter, sybils their node, and then feeds them a bogus chain
>> encompassing
>> > all of the hard-coded checkpoints[3].
>> >
>> > The same attack is made easier in assumeutxo because, unlike in
>> assumevalid,
>> > the attacker need not construct a valid PoW chain to get the victim's
>> node into
>> > a false state; they simply need to get the user to accept a bad
>> `-assumeutxo`
>> > parameter and then supply them an easily made UTXO snapshot containing,
>> say, a
>> > false coin assignment.
>> >
>> > For this reason, I recommend that if we were to implement assumeutxo,
>> we not
>> > allow its specification via commandline argument[4].
>> >
>> > Beyond this risk, I can't think of material differences in security
>> relative to
>> > assumevalid, though I appeal to the list for help with this.
>> >
>> > # More fully validating clients
>> >
>> > A particularly exciting use-case for assumeutxo is the possibility of
>> mobile
>> > devices functioning as fully validating nodes with access to the
>> complete UTXO
>> > set (as an alternative to SPV models). The total resource burden needed
>> to start a node
>> > from scratch based on a snapshot is, at time of writing, a ~(3.2GB
>> > + blocks_to_tip * 4MB) download and a few minutes of processing time,
>> which sounds
>> > manageable for many mobile devices currently in use.
>> >
>> > A mobile user could initialize an assumed-valid bitcoin node within an
>> hour,
>> > transact immediately, and complete a pruned full validation of their
>> > assumed-valid chain over the next few days, perhaps only doing the
>> background
>> > IBD when their device has access to suitable high-bandwidth connections.
>> >
>> > If we end up implementing an accumulator-based UTXO scaling
>> design[5][6] down
>> > the road, it's easy to imagine an analogous process that would allow
>> very fast
>> > startup using an accumulator of a few kilobytes in lieu of a multi-GB
>> snapshot.
>> >
>> > ---
>> >
>> > I've created a related issue at our Github repository here:
>> > https://github.com/bitcoin/bitcoin/issues/15605
>> >
>> > and have submitted a draft implementation of snapshot usage via RPC
>> here:
>> > https://github.com/bitcoin/bitcoin/pull/15606
>> >
>> > I'd like to discuss here whether this is a good fit for Bitcoin
>> conceptually. Concrete
>> > plans for deployment steps should be discussed in the Github issue, and
>> after all
>> > that my implementation may be reviewed as a sketch of the specific
>> software
>> > changes necessary.
>> >
>> > Regards,
>> > James
>> >
>> >
>> > [0]:
>> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
>> > [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
>> > [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116
>> CPU @ 2.10GHz
>> > [3]:
>> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
>> > [4]: Marco Falke is due credit for this point
>> > [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
>> > [6]: Boneh, Bunz, Fisch on accumulators:
>> https://eprint.iacr.org/2018/1188
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/d942b813/attachment-0001.html>

2023-06-07 20:17:16

- reply

📅 Original date posted:2019-04-01
📝 Original message:I think EXACTLY ONE YEAR is the perfect time. Well, a year and a day for
me because I'm on the wrong side of the date line, apparently.
On Sun, Mar 31, 2019 at 6:04 PM Ricardo Filipe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> one year seems too long. i think with the BIP-148 experience you have
> we could easily get there in 6 months at most.
>
> Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> escreveu no dia segunda, 1/04/2019 à(s) 01:33:
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
> >
> > The BIPs are here, as well as included at the bottom of this email for
> > convenience:
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
> >
> > A reference implementation is here:
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
> >
> > Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
> >
> > Luke
> >
> >
> > <pre>
> > BIP: ?
> > Layer: Applications
> > Title: Signed USD Price Indicator
> > Author: Luke Dashjr <luke+bip at dashjr.org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> > for transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > This problem can be fixed by setting a global minimum price for bitcoins.
> > Unfortunately, today, the consensus protocol is completely oblivious to
> the
> > price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> > transactions to indicate their price.
> >
> > ==Specification==
> >
> > ===New field and legal implication===
> >
> > A new field is added to Bitcoin transactions. This field, if present,
> must
> > represent the honest and true USD/BTC rate used for the transaction. By
> > signing the transaction, the sender legally affirms this is the
> valuation of
> > bitcoins used for the transaction.
> >
> > For the avoidance of doubt: when the transaction is valued in a currency
> other
> > than USD, any reasonable exchange rate may be used to come up with the
> USD
> > valuation.
> >
> > ===Serialisation===
> >
> > When serialising the transaction for any purpose, including signing,
> weight
> > calculation, and so on, the output count must be incremented by one.
> Prior to
> > the first real output, the following bytes must be inserted:
> >
> > * Constant: 00 00 00 00 00 00 00 00
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * Constant: 6a 04 55 53 44 24
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * The USD/BTC rate used for the transaction, in standard signed integer
> > serialisation, with all leading zeros removed (except as necessary to
> > preserve the sign bit).
> >
> > ==Backwards compatibility==
> >
> > ===Consensus===
> >
> > The new price field is serialised as a dummy output, with a value of
> zero, and
> > a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will
> ignore
> > this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> > is never considered spendable.
> >
> > Therefore, current nodes will ignore the new field entirely, and accept
> > transactions using it.
> >
> > ===Wallets===
> >
> > Existing wallets do not typically generate price indicators as specified.
> > Under this BIP, this absence of the field is perfectly acceptable.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
> >
> > <pre>
> > BIP: ?
> > Layer: Consensus (soft fork)
> > Title: $50k USD/BTC Minimum Price
> > Author: Luke Dashjr <luke+bip at dashjr.org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > Requires: usdprice
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP defines a minimum price of $50k USD/BTC for Bitcoin
> transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > bip-usdprice defines a new field to indicate the price of transactions.
> Using
> > this, we can softfork to require a minimum transaction price.
> >
> > ==Specification==
> >
> > Beginning with block height 622370 (expected approximately 2020 April
> 1), a
> > block is reject as invalid unless all transactions it contains both
> declare a
> > USD/BTC price (as defined in bip-usdprice) and specify a price that is
> at a
> > minimum $50k USD/BTC.
> >
> > ==Backwards compatibility==
> >
> > As a soft fork, older nodes will continue to accept the blockchain
> without
> > modification. Non-upgraded nodes, however, will not validate the minimum
> > price requirement, and may accept invalid blocks if miners choose to make
> > them. Since transactions not declaring a price are at this time still
> > common-place, the softfork activation has been set a full year into the
> > future to ensure time to upgrade both nodes and wallet software.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190331/6f6bb0ce/attachment.html>

2023-06-07 20:15:31

- reply

📅 Original date posted:2018-12-03
📝 Original message:The last difficulty change took about 20% longer than expected. How large
does the time between difficulty changes have to get for us to make
changes? In other words, if, at some point, block confirmation times are
averaging, say, hours or days, will we hardfork to speed things up?
One option is NO. When enough economic interests align to amass the
computing power to get important bitcoin transactions into a block, then
they will work out a way to get that block confirmed. This allows other
cryptocurrencies and technologies like LN to fill in.
There may be a group that will fork the code in order to adjust the
difficulty more rapidly, and bitcoin holders will put a value on
bitcoin-FDA ("Faster-Difficuly-Adjustment"), which is fine with me. We can
learn how to fork peacefully from what we learned when BCH was born, and
what we learned when it split.
I think some insight into how core developers will handle increasing
demands to use faster difficulty adjustments (if they respond at all) will
be helpful, and this is why I'm asking.
Dave Scotese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181203/9ca5ce6b/attachment-0001.html>

2023-06-07 20:14:49

- reply

📅 Original date posted:2018-09-21
📝 Original message:I've been working on an idea that relieves full nodes of storing the entire
blockchain. Open source software generally relies on the fact that "enough"
people agree that it's secure. Bitcoin software works that way too. So if
you understand enough to see that a UTXO set is valid at a certain block
height, and there are enough other people who agree and that set is
recognizable by humans, then we can use that UTXO set and ditch the
blockchain that existed up to that point. It would save a lot of storage
and make it a lot easier to run a full node.
Have you reviewed the source code from which your wallets were compiled?
At some point, we all trust third parties, but generally (at least among
people who understand Bitcoin) they are large composite groups so that no
small group or individual can profit from cheating.
I look forward to answering any concerns and also to any offers of help. I
used block 542324 of the Bitcoin blockchain to make a memorable experience
using the game of life. I wrote a script for the open-source Game-of-Life
software Golly and shared it in the paste at https://pastebin.com/k5Ssc0qk.
It produces the image at https://imgur.com/a/rwIQuVz. If someone can tell
me how to get a UTXO Set from the bitcoin client, I'll send them $50 of
bitcoin. Then I could get the SHA256 hash of that set and try to make a
recognizable checkpoint for the Bitcoin blockchain. If someone runs Golly
and shares a video of the game playing out (into the apron-shaped image),
I'll send them $50 of bitcoin too.
In a few decades when the blockchain has grown to a few terabytes and the
UTXO Set is still just a few gigabytes, I'd like to see more people start
running full nodes without the hassle of a long wait and loads of storage
space. That's what stops me from running one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180921/90e3c480/attachment.html>

2023-06-07 20:12:22

- reply

📅 Original date posted:2018-05-21
📝 Original message:Our wetware memory is faulty at details, but a rendering that provides
features at which it isn't faulty makes it a decent backup in situations
where technology has been used to hide important differences from us. Some
of us may recall being in a situation where something seems off, and we
start to investigate, and then we discover that something was off. April
Fools jokes are good examples, as well as satire and news reports from The
Onion.
The point of storing the entire blockchain history is to prevent any of
that history being changed in a way that illicitly alters the UTXO Set.
Whenever a memorable enough rendering of the UTXO Set is produced (which
has happened exactly once - when Bitcoin started, it was empty, and after
that, it just looks like a bunch of random computer data), the risk of
altering the history before it goes up, even if you have the computing
power to make subsequent block headers follow all the rules (and even to
successfully execute a 51% attack!). In this announcement
<http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-July/026693.html>,
the first item under "new features" has this, which follows the same
principle as my idea:
Introduce experimental SSH Fingerprint ASCII Visualisation to ssh(1) and
> ssh-keygen(1). Visual fingerprinnt display is controlled by a new
> ssh_config(5) option "VisualHostKey". The intent is to render SSH host keys
> in a visual form that is amenable to easy recall and rejection of changed
> host keys. This technique inspired by the graphical hash visualisation
> schemes known as "random art[*]", and by Dan Kaminsky's musings at 23C3 in
> Berlin.
>
On Sat, May 19, 2018 at 10:12 PM, Damian Williamson <willtech at live.com.au>
wrote:
> I do understand your point, however, 'something like stuxnet' cannot be
> used to create valid data without re-doing all the PoW. Provided some valid
> copies of the blockchain continue to exist, the network can re-synchronise.
>
>
> Unrelated, it would seem useful to have some kind of deep blockchain
> corruption recovery mechanism if it does not exist; where blocks are
> altered at a depth exceeding the re-scan on init, efficient recovery is
> possible *on detection*. Presumably, it would be possible for some
> stuxnet like thing to modify blocks by modifying the table data making
> blocks invalid but without causing a table corruption. I would also suppose
> that if the node is delving deep into the blockchain for transaction data,
> that is would also validate the block at least that it has a valid hash
> (apart from Merkle tree validation for the individual transaction?) and
> that the hash of its immediate ancestor is also valid.
>
>
> Regards,
>
> Damian Williamson
>
>
> ------------------------------
> *From:* bitcoin-discuss-bounces at lists.linuxfoundation.org <
> bitcoin-discuss-bounces at lists.linuxfoundation.org> on behalf of Dave
> Scotese via bitcoin-discuss <bitcoin-discuss at lists.linuxfoundation.org>
> *Sent:* Sunday, 20 May 2018 11:58 AM
> *To:* Scott Roberts
> *Cc:* Bitcoin Discuss
> *Subject:* Re: [bitcoin-discuss] Checkpoints in the Blockchain.
>
> I wouldn't limit my rendering to words, but that is a decent starting
> point. The richer the rendering, the harder it will be to forget, but it
> needn't all be developed at once. My goal here is to inspire the creation
> of art that is, at the same time, highly useful and based on randomness.
>
> Anyway, I asked what "premise that this is needed" you meant and I still
> don't know the answer.
>
> "The archive is a shared memory" - yes, a shared *computer* memory, and
> growing larger (ie more cumbersome) every day. If something like stuxnet is
> used to change a lot of the copies of it at some point, it seems likely
> that people will notice a change, but which history is correct won't be so
> obvious because for the *humans* whose memories are not so easily
> overwritten, computer data is remarkably non-memorable in it's normal form
> (0-9,a-f, whatever). If we ever want to abandon the historical transaction
> data, having a shared memory of the state of a recent UTXO Set will help to
> obviate the need for it. Yes, of course the blockchain is the perfect
> solution, as long as there is *exactly one* and everyone can see that
> it's the same one that everyone else sees. Any other number of archives
> presents a great difficulty.
>
> In that scenario, there's no other way to prove that the starting point is
> valid. Bitcoin has included a hardcoded-checkpoint in the code which
> served the same purpose, but this ignores the possibility that two versions
> of the code could be created, one with a fake checkpoint that is useful to
> a powerful attacker. If the checkpoint were rendered into something
> memorable at the first opportunity, there would be little question about
> which one is correct when the difference is discovered.
>
> On Sat, May 19, 2018 at 5:22 PM, Scott Roberts <wordsgalore at gmail.com>
> wrote:
>
> I just don't see the point of needing to know it any different from the
> hex value. Or maybe I should say I can't imagine it being useful because I
> can't imagine what you're after is possible. There might be a theoretical
> proof that what you're after is impossible. Hard to forget is almost the
> opposite of many options and what we're trying to do is decide between many
> options. I'll assume English because it's the only starting point I have
> that's even in the ballpark of being possible. You might need to constrain
> the word selection and the structure in which you put it. I can only
> imagine that you are talking about putting the words into some sort of
> story. The only kind of story that would be hard to forget is one that
> fits into an overall structure that we are familiar with but those types of
> structures are few compared to the possibilities that we're trying to
> encode. "Hard to deny" is a type of "hard to forget". Besides trying to
> connect it to external reality or history that we can all agree on there is
> also an internal consistency that could be used like a checksum such as the
> structure I mentioned. The only thing that seems to fit the bill is the
> blockchain itself. It's on everyone's computer so it's impossible to forget
> and it has internal consistency. Is the only shared memory we have that
> can't be subject to a Sybil attack or other hijacking of our memory of the
> true history. Our translation of the hash into words and a story could
> potentially be subject to hijacking if it's not done perfectly correct. It
> just seems best to me to use the hash itself. They archived existence of
> the prior parts of the blockchain are what make that particular hash hard
> to forget. Supposedly it can't be forged to reference a fake history. The
> archive is a shared memory that fits the encoding rules.
>
> On Sat, May 19, 2018, 4:30 PM Dave Scotese <dscotese at litmocracy.com>
> wrote:
>
> Did you mean the premise that we have "the need to retain the full
> blockchain in order to validate the UTXO Set"?
>
> I hadn't thought of just making it *easier* to remember, as your
> suggestion does (12-13 words), and that's a great idea. I have passphrases
> of that kind, but I noticed a kind of mandela effect
> <https://www.snopes.com/news/2016/07/24/the-mandela-effect/> just with
> myself. For example, I one of the words I chose was like "olfactory" but
> after a few months, what I remembered was like "ontology". The solution I
> came up with is to couple the data with far more items than we normally
> do. Every ten minutes, we get a new set of 256 bits that can be used to
> create something potential *very difficult* to forget, and that's what
> I'm after.
>
> An algorithm could be used to do this with the Bip39 word list. If we
> categorized the words according to parts of speech, the bits could be used
> to determine which word goes next in a kind of ad-lib, but this creates a
> phrase that is only memorable in the language for which the algorithm is
> developed. As a thought experiment, I'll try adjective noun verb(as past
> tense) noun preposition adjective adjective noun: Stuff would come out like
> "Able abstract abused accident across actual adult affair." not memorable
> at all, but sense can be made of it and sometimes the sense will be
> remarkable. As it is, I will have forgotten it in an hour or two.
>
> On Thu, May 17, 2018 at 4:29 PM, Scott Roberts <wordsgalore at gmail.com>
> wrote:
>
> I disagree with your premise that this is needed, I like the question.
> Humans are experts at language and I don't think we have another repository
> at hand that we can categorize for memory that is better than words. Using
> words is a common way of doing what you're thinking about. If the
> checkpoint could be a hash that meets a difficulty target the possibilities
> are 2^182 at the current hashrate instead of 2^256. So we need only 12 or
> 13 common words with their various possible endings (30,000). I would find
> it easier to insert a letter and 3 numbers after every 2 words so there
> would be only 8 words used. There are probably other tricks people have
> figured out but there can't be any kind of advanced encoding because it
> wouldn't benefit more than one word. There might be a way to convert the
> words into something that almost sounds like English sentences but it would
> probably come out a cost of at least doubling the number of words.
>
> On Thu, May 17, 2018, 12:13 PM Dave Scotese via bitcoin-discuss <
> bitcoin-discuss at lists.linuxfoundation.org> wrote:
>
> I got the idea that a SHA256 hash could be rendered into something
> difficult to forget. The rendering would involve using each of the 256
> bits to specify something important about the rendering - important in an
> instinctive human-memory way.
>
> Let's assume such a rendering is possible, and that at any time, any
> person can execute the rendering against the SHA256 hash of a consistent
> representation of the UTXO Set. Sometimes, someone will execute the
> rendering and discover that it is remarkable in some way (making it even
> more memorable), and therefore will publish it.
>
> The published, memorable rendering now becomes a kind of protection
> against any possible re-writing of the blockchain from any point prior to
> that UTXO Set. When everyone involved in Bitcoin recognizes this
> protection, it relieves us of the need to retain the full blockchain in
> order to validate the UTXO Set at that point, because enough people will
> recognize it, and it can be validated without reference to any kind of
> prior computer record.
>
> This does leave open the possibility that an attacker could create a more
> favorable UTXO Set that happens to have a rendering similar enough to fool
> people, or one that has exactly the same SHA256-hash, but that possibility
> is remote enough to ignore (just as we all ignore the possibility that
> whatever creates the master seed for our HD wallet will create a unique
> master seed).
>
> I've been working on how such a rendering could happen. It could describe
> music, characters, colors, plot points, memorable elements of characters,
> etc.
>
> Dave Scotese
>
> _______________________________________________
> bitcoin-discuss mailing list
> bitcoin-discuss at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180521/649dd8e4/attachment-0001.html>

2023-06-07 19:56:44

- reply

📅 Original date posted:2017-02-25
📝 Original message:I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a
PUBLIC key (msg) into a bitcoin address, so yeah, you could identify
ANOTHER (or the same, I guess - how would you know?) public key that has
the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see
how that has any effect on anyone. Maybe I'm restating what Peter wrote.
If so, confirmation would be nice.
On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote:
> > On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev
> > > wrote:
> > > > >SHA1 is insecure because the SHA1 algorithm is insecure, not because
> > > > 160bits isn't enough.
> > > >
> > > > I would argue that 160-bits isn't enough for collision resistance.
> > > Assuming
> > > > RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle),
> > > collisions
> > >
> > > That's something that we're well aware of; there have been a few
> > > discussions on
> > > this list about how P2SH's 160-bits is insufficient in certain
> use-cases
> > > such
> > > as multisig.
> > >
> > > However, remember that a 160-bit *security level* is sufficient, and
> > > RIPEMD160
> > > has 160-bit security against preimage attacks. Thus things like
> > > pay-to-pubkey-hash are perfectly secure: sure you could generate two
> > > pubkeys
> > > that have the same RIPEMD160(SHA256()) digest, but if someone does
> that it
> > > doesn't cause the Bitcoin network itself any harm, and doing so is
> > > something
> > > you choose to do to yourself.
> > >
> >
> > Be aware that the issue is more problematic for more complex contracts.
> > For example, you are building a P2SH 2-of-2 multisig together with
> someone
> > else if you are not careful, party A can hand their key over to party B,
> > who can may try to generate a collision between their second key and
> > another 2-of-2 multisig where they control both keys. See
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-January/012205.html
>
> I'm very aware of that, in fact I think I may have even been the first
> person
> to post on this list the commit-reveal mitigation.
>
> Note how I said earlier in the message you're replying to that "P2SH's
> 160-bits
> is insufficient in certain use-cases such as multisig"
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/6b3b227c/attachment-0001.html>

2023-06-07 19:55:54

- reply

📅 Original date posted:2017-02-02
📝 Original message:There are two ideas here for "on-chain" voting, both of which require
changes to the software. I agree with David that on-chain solutions
complicate things. Both proposals can be effected without any software
changes:
Those who wish to use proof of stake can provide a service for making
vanity addresses containing some indicator of the proposal to be supported
- 1bigblock or 12mbblk or whatever - based on a supporter-provided secret
key, and then supporters can move their bitcoin into their own vanity
address and then whoever wants to can create a website to display the
matching addresses and explain that this is the financial power in the
hands of supporters and how to add your "financial power vote."
Those who simply want to "buy votes" can use their funds in marketing
efforts to promote the proposal they support.
This second method, of course, can be abused. The first actually requires
people to control bitcoin in order to represent support. Counting actual,
real people is still a technology in its infancy, and I don't think I want
to see it progress much. People are not units, but individuals, and their
value only becomes correlated to their net worth after they've been alive
for many years, and even then, some of the best people have died paupers.
If bitcoin-discuss got more traffic, I think this discussion would be
better had on that list.
notplato
On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Strongly disagree with buying "votes", or portraying open standards as a
> voting process. Also, this depends on address reuse, so it's fundamentally
> flawed in design.
>
> Some way for people to express their support weighed by coins (without
> losing/spending them), and possibly weighed by running a full node, might
> still be desirable. The most straightforward way to do this is to support
> message signatures somehow (ideally without using the same pubkey as
> spending), and some [inherently unreliable, but perhaps useful if the
> community "colludes" to not-cheat] way to sign with ones' full node.
>
> Note also that the BIP process already has BIP Comments for leaving textual
> opinions on the BIP unrelated to stake. See BIP 2 for details on that.
>
> Luke
>
>
> On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:
> > Please comment on this work-in-progress BIP.
> >
> > Thanks,
> >
> > - t.k.
> >
> > ----------------------
> > BIP: ?
> > Layer: Process
> > Title: Community Consensus Voting System
> > Author: t.khan <teekhan42 at gmail.com>
> > Comments-Summary: No comments yet.
> > Comments-URI: TBD
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-02-02
> > License: BSD-2
> > Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example,
> don’t
> > send to this!)
> >
> > Abstract
> > Community Consensus Voting System (CCVS) will allow developers to measure
> > support for BIPs prior to implementation.
> >
> > Motivation
> > We currently have no way of measuring consensus for potential changes to
> > the Bitcoin protocol. This is especially problematic for controversial
> > changes such as the max block size limit. As a result, we have many
> > proposed solutions but no clear direction.
> >
> > Also, due to our lack of ability to measure consensus, there is a general
> > feeling among many in the community that developers aren’t listening to
> > their concerns. This is a valid complaint, as it’s not possible to listen
> > to thousands of voices all shouting different things in a crowded
> > room—basically the situation in the Bitcoin community today.
> >
> > The CCVS will allow the general public, miners, companies using Bitcoin,
> > and developers to vote for their preferred BIP in a way that’s public and
> > relatively difficult (expensive) to manipulate.
> >
> > Specification
> > Each competing BIP will be assigned a unique bitcoin address which is
> added
> > to each header. Anyone who wanted to vote would cast their ballot by
> > sending a small amount (0.0001 btc) to their preferred BIP's address.
> Each
> > transaction counts as 1 vote.
> >
> > Confirmed Vote Multiplier:
> > Mining Pools, companies using Bitcoin, and Core maintainers/contributors
> > are allowed one confirmed vote each. A confirmed vote is worth 10,000x a
> > regular vote.
> >
> > For example:
> >
> > Slush Pool casts a vote for their preferred BIP and then states publicly
> > (on their blog) their vote and the transaction ID and emails the URL to
> the
> > admin of this system. In the final tally, this vote will count as 10,000
> > votes.
> >
> > Coinbase, Antpool, BitPay, BitFury, etc., all do the same.
> >
> > Confirmed votes would be added to a new section in each respective BIP
> as a
> > public record.
> >
> > Voting would run for a pre-defined period, ending when a particular block
> > number is mined.
> >
> >
> > Rationale
> > Confirmed Vote Multiplier - The purpose of this is twofold; it gives a
> > larger voice to organizations and the people who will have to do the work
> > to implement whatever BIP the community prefers, and it will negate the
> > effect of anyone trying to skew the results by voting repeatedly.
> >
> > Definitions
> > Miner: any individual or organization that has mined at least one valid
> > block in the last 2016 blocks.
> >
> > Company using Bitcoin: any organization using Bitcoin for financial,
> asset
> > or other purposes, with either under development and released solutions.
> >
> > Developer: any individual who has or had commit access, and any
> individual
> > who has authored a BIP
> >
> > Unresolved Issues
> > Node voting: It would be desirable for any full node running an
> up-to-date
> > blockchain to also be able to vote with a multiplier (e.g. 100x). But as
> > this would require code changes, it is outside the scope of this BIP.
> >
> > Copyright
> > This BIP is licensed under the BSD 2-clause license.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170202/b5c28eed/attachment-0001.html>

2023-06-07 19:53:51

- reply

📅 Original date posted:2016-10-10
📝 Original message:I sent my previous email ONLY to bitcoin-discuss at lists.linuxfoundation.org
and it waited in the moderation queue. I don't know when moderation was
added to this list, but it seems to me that it's a misstep.
On Mon, Oct 10, 2016 at 12:38 AM, Henning Kopp via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I totally agree with the assessment of the situation. Previously I
> learned a lot about bitcoin on this list. There were a lot of great
> ideas regarding the protocol and the surrounding ecosystem. Now there
> is mainly talk about code and BIPs, which is the main purpose of a
> developer list.
> I do not feel that we should clog bitcoin-dev again with
> non-development talk but rather find a way to get bitcoin-discuss
> going. My impression is that bitcoin-discuss has not reached a
> critical mass of contributors. The question is how we can change that.
>
> All the best
> Henning
>
> On Sun, Oct 09, 2016 at 12:26:07PM +0200, Jeremy via bitcoin-dev wrote:
> > Hi bitcoin-dev,
> >
> > I'm well aware that discussion of moderation on bitcoin-dev is
> > discouraged*. However, I think that we should, as a year of moderation
> > approaches, discuss openly as a community what the impact of such policy
> > has been. Making such a post now is timely given that people will have
> the
> > opportunity to discuss in-person as well as online as Scaling Bitcoin is
> > currently underway. On the suggestion of others, I've also CC'd
> > bitcoin-discuss on this message.
> >
> > Below, I'll share some of my own personal thoughts as a starter, but
> would
> > love to hear others feelings as well.
> >
> > For me, the bitcoin-dev mailing list was a place where I started
> > frequenting to learn a lot about bitcoin and the development process and
> > interact with the community. Since moderation has begun, it seems that
> the
> > messages/day has dropped drastically. This may be a nice outcome overall
> > for our sanity, but I think that it has on the whole made the community
> > less accessible. I've heard from people (a > 1 number, myself included)
> > that they now self-censor because they think they will put a lot of work
> > into their email only for it to get moderated away as trolling/spam.
> Thus,
> > while we may not observe a high rate of moderated posts, it does mean the
> > "chilling effect" of moderation still manifests -- I think that people
> not
> > writing emails because they think it may be moderated reduces the rate of
> > people writing emails which is a generally valuable thing as it offers
> > people a vehicle through which they try to think through and communicate
> > their ideas in detail.
> >
> > Overall, I think that at the time that moderation was added to the list,
> it
> > was probably the right thing to do. We're in a different place as a
> > community now, so I feel we should attempt to open up this valuable
> > communication channel once again. My sentiment is that we enacted
> > moderation to protect a resource that we all felt was valuable, but in
> the
> > process, the value of the list was damaged, but not irreparably so.
> >
> > Best,
> >
> > Jeremy
> >
> >
> > * From the email introducing the bitcoin-dev moderation policy,
> "Generally
> > discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical
> > bitcoin issues, rehashing settled topics without new data, moderation
> > concerns."
> >
> >
> > --
> > @JeremyRubin <https://twitter.com/JeremyRubin>
> > <https://twitter.com/JeremyRubin>
>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161010/b30db2b1/attachment.html>

2023-06-07 19:53:35

- reply

📅 Original date posted:2016-09-23
📝 Original message:If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid
paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob
complains about getting paid faster, Alice can let him know that Fred
essentially stole his coins and that when she is certain he (and she) can't
get them back, she will send a different four coins to Bob. If she can
establish trust with Bob (She'd trust Bob to pay her back if he gets back
the coins Fred stole), then she can pay him again. Bob could also make a
transaction to send the first input from Alice back to her (since he
doesn't have those coins anyway), sign it, and send that to her. She can
then keep it instead of having to use the new opcode.
Or she can let her wallet use the new opcode so that the logic is built in,
if we add this opcode. Wallet makers who want to help solve this problem
can either implement the new opcode, or they can offer people like Bob the
ability to refund orphaned transactions so that they can be duplicated in
the valid chain without any risk to the original sender.
With the opcode, Alice can solve the problem by herself. Without it, Bob
can solve it for Alice.
While the opcode adds complexity, it enables victims of double-spends to
pay untrusted creditors (Bob) without the risk that orphaned chains create
of paying them twice. I'm not sure the added complexity is worth the
reward. The reward is to protect Bitcoiners (Alice) from people we'd call
"untrusted creditors" (Bob) and I think that might be a mistake. Getting a
refund transaction signed and sent back to Alice is similar to how the LN
will work (where wallets hold transactions that they don't broadcast).
Am I understanding this correctly?
On Fri, Sep 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's transfer
> to
> Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is
> possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO 3 which
> would result in her giving Bob a total of 8 BTC rather than merely 4 BTC.
> Even if Alice waits until Fred's UTXO 1-B confirms 10 blocks deep, it is
> not
> impossible for a reorganization to reverse those 10 blocks and confirm
> UTXO 1
> again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that it
> is
> valid only in the blockchain where Fred's UTXO 1-B has confirmed. This
> way, if
> that block is reorganized out, UTXO 3 is invalid, and either Bob receives
> only
> the original UTXO 2, or Alice can create a UTXO 3-B which is valid in the
> reorganized blockchain if it again confirms the UTXO 1-B double-spend.
>
> Luke
>
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> coins
> > > they spend have been conflicted/double-spent.
> > >
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Can you walk us through a real live usecase which this solves? I read it
> > and I think I understand it, but I can't see the attack every giving the
> > attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160923/a0d9fa2b/attachment-0001.html>

2023-06-07 19:49:44

- reply

📅 Original date posted:2016-03-08
📝 Original message:I think a BIP is a good idea, but rather than making such a specific
proposal as "Let's use bit 4 to indicate communication of thin blocks," how
about a more general one like "Let's use bit(s?) 4(-5?) as user-agent
specific service bits so that if you customize your user-agent string, you
can use them for whatever you want"? That way, other clients can choose to
follow suit by saying so, or simply recognize the meaning (or lack thereof)
of those bits based on the user-agent setting. This relieves future
development from the burden of agreeing on where to put what, and allows
time and utility to show when such a user-agent-specific service bit should
be moved into the protocol section of service bits.
PS I am not well versed in the creation of standards, but the reservation
of digital real estate for self-identified customization (bits, bytes, or
whatever that will never be used by the standard) such as what I'm
proposing seems like something that probably has a standard name. "Public
provisioning" or something like that?
On Mon, Mar 7, 2016 at 12:51 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The Bitcoin Unlimited client needs a services bit to indicate that the
> node
> > is capable of communicating thin blocks. We propose to use bit 4 as
> AFAIK
> > bit 3 is already earmarked for Segregated Witness.
>
> Does this functionality change peer selection? If not, the preferred
> signaling mechanism is probably the one in BIP 130.
>
> Otherwise, I think the standard method for getting numbers has been to
> write a BIP documenting the usage. I don't know if that is intentional
> or just how things have previously happened; and I don't have much of
> an opinion on it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160307/d29951b7/attachment-0001.html>

2023-06-07 19:49:31

- reply

📅 Original date posted:2016-03-03
📝 Original message:It makes sense to me that there might be objective conditions under which
we would want to use a number smaller than 2016. A good example would be a
mean time between blocks of more than 20 minutes over the last 144 blocks
(one - two days). If such an occurrence ever happened, and the software
then cut the retarget interval to 1008 (triggering an immediate retarget if
the counter is over 1008), the only problem I see is how to measure the
mean time between blocks.
In fact, has anyone examined the potential problems of reducing the
retarget period, even to one? Not Really.
<http://bitcoin.stackexchange.com/questions/9305/why-not-retarget-on-every-block>
That question includes a suggestion of retargeting on every block, but
using the same 2016 block window for the calculation, so difficulty changes
would be very smooth, and still as unpredictable and how long till we find
the next block.
On Wed, Mar 2, 2016 at 3:02 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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 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 factored in. This is why inflation in
> Bitcoin is not a tax, it’s a cost. These step functions are made continuous
> by their predictability, removing that predictability will make them --
> unpredictable.
>
> You know, I do agree with you.
>
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same
> UTXO set as Bitcoin as a means of initial coin distribution.
>
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those
> coins. We may choose not to, but if 95% of the hashing power decides to
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000004d430e1daab776bc1c194589b0326924220faa00efc50cf
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/c1a8954e/attachment.html>

2023-06-07 19:48:22

- reply

📅 Original date posted:2016-02-02
📝 Original message:The section that starts "Should two software projects need to release"
addresses issues that are difficult to ascertain from what is written
there. I'll take a stab at what it means:
Would bitcoin be better off if multiple applications provided their own
implementations of API/RPC and corresponding application layer BIPs?
- While there is only one such application, its UI will be the obvious
standard and confusion in usability will be avoided.
- Any more than a single such application will benefit from the
coordination encouraged and aided by this BIP and BIP 123.
"To avoid doubt: comments and status are unrelated metrics to judge a BIP,
and neither should be directly influencing the other." makes more sense to
me as "To avoid doubt: comments and status are intended to be unrelated
metrics. Any influence of one over the other indicates a deviation from
their intended use." This can be expanded with a simple example: "In other
words, a BIP having the status 'Rejected' is no reason not to write
additional comments about it. Likewise, overwhelming support for a BIP in
its comments section doesn't change the requirements for the 'Accepted' or
'Active' status."
Since the Bitcoin Wiki can be updated with comments from other places, I
think the author of a BIP should be allowed to specify other Internet
locations for comments. So "link to a Bitcoin Wiki page" could instead be
"link to a comments page (strongly recommended to be in the Bitcoin
Wiki)". Also, under "Will BIP comments be censored or limited to
particular participants/"experts"?" You could add:
- The author of a BIP may indicate any commenting URL they wish. The
Bitcoin Wiki is merely a recommendation, though a very strong one.
On Mon, Feb 1, 2016 at 2:53 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've completed an initial draft of a BIP that provides clarifications on
> the
> Status field for BIPs, as well as adding the ability for public comments on
> them, and expanding the list of allowable BIP licenses.
>
>
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status (along with
> BIP
> 123) a month after initial revisions have completed. Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160201/b5dacb35/attachment.html>

2023-06-07 19:46:59

- reply

📅 Original date posted:2015-12-29
📝 Original message:There have been no decent objections to altering the block-selection
mechanism (when two block solutions appear at nearly the same time) as
described at
http://bitcoin.stackexchange.com/questions/39226
Key components are:
- Compute BitcoinDaysDestroyed using only transactions that have been in
your mempool for some time as oBTCDD ("old BTCDD").
- Use "nearly the same time" to mean separated in time by your guess of
the average duration of block propagation times.
- When two block solutions come in at nearly the same time, build on the
one that has the most oBTCDD, rather than the one that came in first.
The goal of this change is to reduce the profitability of withholding block
solutions by severely reducing the chances that a block solved a while ago
can orphan one solved recently. "Came in first" seems more easily gamed
than "most oBTCDD". As I wrote there, "*old coins* is always a dwindling
resource and *global nodes willing to help cheat* is probably a growing
one."
I will write a BIP if anyone agrees it's a good idea.
On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Far more concerning is network propagation effects between large and
>> small miners. For that class of issues, if you are in an environemnt
>> where selfish mining is possible - a fairly flat, easily DoS/sybil
>> attacked network topology - the profitability difference between small
>> and large miners even *without* attacks going on is a hugely worrying
>> problem. OTOH, if you're blocksize is small enough that propagation time
>> is negligable to profitability, then selfish mining attacks with <30%
>> hashing power aren't much of a concern - they'll be naturally defeated
>> by anti-DoS/anti-sybil measures.
>>
>
> Let's agree that one factor in mining profitability is bandwidth/network
> reliability/stability. Why focus on that vs electricity contracts or
> vertically integrated chip manufacturers? Surely, sufficient network
> bandwidth is a more broadly available commodity than <$0.02/kwh
> electricity, for example. I'm not sure that your stranded hydroelectric
> miner is any more desirable than thousands of dorm room miners with access
> to 10gbit university connections and free electricity.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151229/654898a2/attachment.html>

2023-06-07 19:46:36

- reply

📅 Original date posted:2015-12-19
📝 Original message:A couple observations:
- The consensus block limit is different than the disk space required to
do validation. Some participants are worried about one and some about the
other, and sometimes they feel what amounts to an imaginary contention
because they perceive these two different things as the same. They are
both addressed by scaling solutions, but to different degrees. This is the
most concrete I can get about my impression whenever someone writes "not
correct." Less concrete is my usual impression, "you're both right."
- "Kicking the can" has value, but no one has connected the value to the
phrase, so here it is: The more time we have to make changes, the better
the changes will be. Of course it's a trade-off (because we suffer through
that extra time with the unsolved problem), but using (or thinking of)
"kicking the can" as bad is a mistake.
- Whether or not there is a massive campaign targeting *current
bitcoiners* has a very strong effect on upgrade rates.
It seems that a hardfork to a 2MB limit on 5/5/16 is a tad more than one
LOC, since we want an if-then around it so it doesn't happen til the agreed
date. But I still support it.
On Fri, Dec 18, 2015 at 11:50 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Not entirely correct, no. Edge cases also matter. Segwit is described as
> 4MB because that is the largest possible combined block size that can be
> constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you
> have to be confident that an 8MB relay size would be acceptable, even if a
> block full of actual transactions would be closer to 3.5MB.
>
> On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Anthony,
>>
>>
>> On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev
>>> wrote:
>>> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
>>> > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is
>>> already
>>> > > equivalent to the 2-4-8 "compromise" proposal [...]
>>> > isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.
>>>
>>> Segwit as proposed gives a 75% *discount* to witness data with the
>>> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
>>> of 650kB of base block data plus 1.4MB of witness data; where 650kB +
>>> 1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus
>>> 2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit.
>>>
>>> > 4x is theoric gain you get in case of 2-2 multisig txs.
>>>
>>> With segregated witness, 2-2 multisig transactions are made up of 94B
>>> of base data, plus about 214B of witness data; discounting the witness
>>> data by 75% gives 94+214/4=148 bytes. That compares to about 301B for
>>> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
>>> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
>>> to get the numbers above.
>>>
>>> You get further improvements with, eg, 3-of-3 multisig, but to get
>>> the full, theoretical 4x gain you'd need a fairly degenerate looking
>>> transaction.
>>>
>>> Pay to public key hash with segwit lets you move about half the
>>> transaction data into the witness, giving about a 1.6x improvement by
>>> my count (eg 1.6MB = 800kB of base data plus 800kB of witness data,
>>> where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is
>>> a reasonable expectation to have for the proposed segwit scheme overall.
>>>
>>>
>> many thanks for the explanation.
>>
>> so it should be fair to say that BIP 102 + SW would bring a gain between
>> 2*1.6 and 2*2.
>>
>> Just for the sake of simplicity if we take the middle of the interval we
>> could say
>> that BIP102 + SW will bring us a max block (virtual) size equal to 1MB *
>> 2 * 1.8 = 3.6
>>
>> Is it right?
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/367b6d92/attachment.html>

2023-06-07 19:46:26

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
I'm not a core dev, so maybe I have the power to change the consensus
rules. No one has that power, actually, at least not legitimately. All we
can do is build it and hope enough people find it acceptable to adopt. Who
doesn't want to hard fork to 2MB blocks on May 5th and why not?
I have a bitcoin to be split up among all those who suffer from a May 5,
2016 hardfork to 2MB blocks if they can prove it to me, or prove it to
enough engineers that I succumb to peer pressure. I would have to respect
the engineers though.
There!
Now that we've agreed to have a hard fork on May 5th, 2016, we might decide
to implement some other methods of avoiding the FFM, like braiding the
blockchain or flexcap, or just let anyone mining on top of a block make one
that is a five or ten Kb larger.
notplato
On Wed, Dec 16, 2015 at 2:27 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 1:36 PM, jl2012 <jl2012 at xbt.hk> wrote:
>
>> 4. In the miners round table on the second day, one of the devs mentioned
>> that he didn't want to be seen as the decision maker of Bitcoin. On the
>> other hand, Chinese miners repeatedly mentioned that they want several
>> concrete proposals from devs which they could choose. I see no
>> contradiction between these 2 viewpoints.
>>
>
> This was a very interesting dynamic, and seems fair (menu).
>
>
>
>> 6. I believe we should avoid a radical "Economic Change Event" at least
>> in the next halving cycle, as Bitcoin was designed to bootstrap the
>> adoption by high mining reward in the beginning. For this reason, I support
>> an early and conservative increase, such as BIP102 or 2-4-8. 2MB is
>> accepted by most people and it's better than nothing for BIP101 proponents.
>> By "early" I mean to be effective by May, at least 2 months before the
>> halving.
>>
>
> That was precisely my logic for picking May 5 as the hard fork date. Some
> buffer before halving, enough for caution and iteration in the meantime.
>
>
>
>
>
>
>>
>> (c) My most optimistic guess is SW will be ready in 6 months, which will
>> be very close to halving and potential tx volume burst. And it may not be
>> done in 2016, as it does not only involve consensus code, but also change
>> in the p2p protocol and wallet design
>>
>
> Not just wallet design -- you have to game through the standard steps of:
> update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app +
> release cycle, for most actors in the ecosystem, on top of the Bitcoin Core
> roll out.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/73119590/attachment.html>

2023-06-07 19:46:24

- reply

📅 Original date posted:2015-12-19
📝 Original message:I've already publicly declared that I offer one bitcoin to "those who
suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way
too sloppy. Here's a better idea that transmits the economic power of
merchants and customers (well, anyone with bitcoin) to the miners on whom
they must rely for confirmations:
The bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be
pledged to a miner. Here is how that miner earns the reward:
1. Wait until a core dev signs a release of bitcoin core in which the
limit is double it's current level.
2. Use the new release to mine, but use a soft limit on the blocksize to
produce only blocks that are valid according to the old software.
3. Wait until May 5th, 2016.
4. Remove the soft limit on blocksize.
5. Create a block that breaks the old limit and is valid according to
the new signed release.
6. Wait for the new large block to be orphaned.
Hopefully, the reward will be greater than 25 bitcoins and therefore cover
the transaction fees. Of course, if they wait until after the halving in
step 3, then they will get twice the (new, 12.5 btc) reward if they can
arrange for the orphaning of their own block.
Any core dev could do this but I guess it would be playing with fire. So
maybe Satoshi will do it. He played with fire (right?) and look how that
worked out. Come on, someone, be a hero. Mike and Gavin tried, but I
think they went a little overboard.
Another way to do this is to identify the position in each binary where the
hard limit is stored, and write a little script that will (check the date
first, and then) alter the data at that position so that currently running
bitcoin software can be hot-patched on May 5th without the help of any core
devs (if that would work). Obviously, the little script should be signed
by a competent programmer whom the user trusts, a slightly less stringent
requirement than being an actual core dev.
notplato
On Fri, Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Dec 18, 2015 2:13 AM, "sickpig at gmail.com" <sickpig at gmail.com> wrote:
> > 1.75 x 0.5 + 1 x 0.5 = 1.375
> >
> > after six month.
> >
> > An hard-fork on the others side would bring 1.75 since the activation,
> am I right?
>
> Yes.
>
> However, SW immediately gives a 1.75 capacity increase for anyone who
> adopts it, after the softfork, instantly. They don't need to wait for
> anyone else.
>
> A hard fork is an orthogonal improvement, which is also needed if we don't
> want to be stuck with a constant maximum ultimately.
>
> Hardforks can however only be deployed at a time when all full node
> software can reasonably have agreed to upgrade, while a softfork can be
> deployed much earlier.
>
> They are independent improvements, and we need both. I am however of the
> opinion that hard forks need a much clearer consensus and much longer
> rollout timeframes to be safe (see my thread on the security of softforks).
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/81c76c41/attachment.html>

2023-06-07 19:45:27

- reply

📅 Original date posted:2015-12-03
📝 Original message:Emin's email presents to me the idea of dictionaries that already contain
the data we'd want to compress. With 8 bytes of indexing data, we can
refer to a TxID or a Public Key or any existing part of the blockchain.
There are also data sequences like scripts that contain a few variable
chunks and are otherwise identical. Often, the receiver has the
blockchain, which contains a lot of the data that is in the message being
transmitted.
First, the receiver must indicate that compressed data is preferred and the
height of latest valid block it holds, and the sender must express the
ability to send compressed data. From this state, the sender sends
messages that are compressed. Compressed messages are the same as
uncompressed messages except that:
1. Data read is copied into the decompressed message until the first
occurrence of 0x00, which is discarded and is followed by compressed data.
2. Compressed data can use as a dictionary the first 16,777,215 blocks,
or the last 4,244,635,647 ending with the block at the tip of the
receiver's chain, or it can specify a run of zero bytes. The sender and
receiver must agree on the *receiver's* current block height in order to
use the last 4B blocks as the dictionary.
3. Within compressed data, the first byte identifies how to decompress:
1. 0xFF indicates that the following three bytes are a block height
with most significant byte 0x00 in network byte order.
2. 0xFE indicates that the following byte indicates how many zero
bytes to add to the decompressed data.
3. 0xFD is an error, so compressed messages are turned off and the
recipient fails the decompression process.
4. 0x00 indicates that the zero byte by itself should be added to the
decompressed data, and the data following is not compressed
(return to step
1).
5. All other values represent the most significant byte of a number
to be subtracted from the receiver's current block height to identify a
block height (not available until there are least 16,777,216
blocks so that
this byte can be at least 0x01, since 0x00 would indicate a single zero
byte, end compressed data, and return to step 1).
4. If decompression has identified a block height (previous byte was not
0xFD, 0x00, or 0xFE), then the next four bytes identify a *size *(one
byte) and a byte index into the block's data (three bytes), and *size *bytes
from that block are added to the decompressed data.
5. Steps 3 and 4 process a chunk of compressed data. If the next byte
is 0xFD, then decompression goes back to step 1 (add raw bytes until it
hits a 0x00). Otherwise, it proceeds through steps 3 (and maybe 4) again.
In Step 3.3, 0xFD causes an error, but it could be used to indicate a
parameterized dictionary entry, for example 0xFD, 0x01 followed by eight
more bytes to be interpreted according to steps 3.1 or 3.5 could mean
OP_DUP OP_HASH160 (20 bytes from the blockchain dictionary) OP_EQUALVERIFY
OP_CHECKSIG, replacing that very common occurrence of 24 bytes with 10
bytes. Well, 11 if you include the 0x00 required by step5. But that only
works on addresses that have spent inputs. Or 0xFD, 0x02 could be
shorthand for the four zeroes of lock_time, followed by Version (1),
followed by 0x01 (for one-input transactions), turning nine bytes into two
for the data at the end of a normal (lock_time = 0) Txn and the beginning
of a single-input Txn. But I left 0xFD as an error because those gains
didn't seem as frequent as the others.
Dave.
On Wed, Dec 2, 2015 at 3:05 PM, Peter Tschipper via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 30/11/2015 9:28 PM, Matt Corallo wrote:
>
> I'm really not a fan of this at all. To start with, adding a compression library that is directly accessible to the network on financial software is a really, really scary idea.
>
> Why scary? LZO has no current security issues, and it will be
> configureable by each node operator so it can be turned off completely if
> needed or desired.
>
> If there were a massive improvement, I'd find it acceptable, but the improvement you've shown really isn't all that much.
>
> Why is 15% at the low end, to 27% at the high end not good? It sounds
> like a very good boost.
>
> The numbers you recently posted show it improving the very beginning of IBD somewhat over high-latency connections, but if we're throughput-limited after the very beginning of IBD, we should fix that, not compress the blocks.
>
> I only did the compression up to the 200,000 block to better isolate the
> transmission of data from the post processing of blocks and determine
> whether the compressing of data was adding to much to the total
> transmission time.
>
> I think it's clear from the data that as the data (blocks, transactions)
> increase in size that (1) they compress better and (2) they have a bigger
> and positive impact on improving performance when compressed.
>
> Additionally, I'd be very surprised if this had any significant effect on the speed at which new blocks traverse the network (do you have any simulations or other thoughts on this?).
>
> From the table below, at 120000 blocks the time to sync the chain was
> roughly the same for compressed vs. uncompressed however after that point
> as block sizes start increasing, all compression libraries peformed much
> faster than uncompressed. The data provided in this testing clearly shows
> that as block size increases, the performance improvement by compressing
> data also increases.
>
> TABLE 5:
> Results shown in seconds with 60ms of induced latency
> Num blks sync'd Uncmp Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
> --------------- ----- ------ ------ ------- ---------
> 120000 3226 3416 3397 3266 3302
> 130000 4010 3983 3773 3625 3703
> 140000 4914 4503 4292 4127 4287
> 150000 5806 4928 4719 4529 4821
> 160000 6674 5249 5164 4840 5314
> 170000 7563 5603 5669 5289 6002
> 180000 8477 6054 6268 5858 6638
> 190000 9843 7085 7278 6868 7679
> 200000 11338 8215 8433 8044 8795
>
>
> As far as, what happens after the block is received, then obviously
> compression isn't going to help in post processing and validating the
> block, but in the pure transmission of the object it most certainly and
> logically does and in a fairly direct proportion to the file size (a file
> that is 20% smaller will be transmited "at least" 20% faster, you can use
> any data transfer time calculator
> <http://www.calctool.org/CALC/prof/computing/transfer_time> for that).
> The only issue, that I can see that required testing was to show how much
> compression there would be, and how much time the compression of the data
> would add to the sending of the data.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151202/c8405e2f/attachment.html>

2023-06-07 19:45:13

- reply

📅 Original date posted:2015-11-24
📝 Original message:What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and be
a signature of some kind of message to that effect. I imagine the cost of
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email makes
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> **OP_CHECKWILDCARDSIGVERIFY**
>
>
> Some (minor) discussion of this idea in -wizards earlier today starting
> near near "09:50" (apologies for having no anchor links):
> http://gnusha.org/bitcoin-wizards/2015-11-24.log
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151124/0b0a26f2/attachment.html>

2023-06-07 19:43:17

- reply

📅 Original date posted:2015-10-13
📝 Original message:It was about 360MB (30 minutes ago?), but is now about 460MB. I'm sure it
won't keep going up that fast.
{
"size" : 3413,
"bytes" : 41892350
}
On Tue, Oct 13, 2015 at 5:08 PM, Jonathan Toomim (Toomim Bros) <j at toom.im>
wrote:
> 16 million divided by 1085 transactions is almost 15Kb per transaction =
> unlikely, right?
>
>
> The recent spam was about 15 kB per transaction, so that part sounds right.
>
> The anomalous thing that I saw was that the total bitcoind process usage
> was about 50-100x higher than I would have expected if the mempool was the
> main determinant of memory usage scaling. Can you tell me how much memory
> Task Manager is reporting your bitcoin process as using both today and
> tomorrow?
>
> On Oct 13, 2015, at 4:52 PM, Dave Scotese via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> {
> "size" : 1085,
> "bytes" : 16151768
> }
> It has been running about a day. I'll report tomorrow too. This is a
> Windows 8.1 box.
> 16 million divided by 1085 transactions is almost 15Kb per transaction =
> unlikely, right?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/65f7f6f1/attachment-0001.html>

2023-06-07 19:43:16

- reply

📅 Original date posted:2015-10-13
📝 Original message:{
"size" : 1085,
"bytes" : 16151768
}
It has been running about a day. I'll report tomorrow too. This is a
Windows 8.1 box.
16 million divided by 1085 transactions is almost 15Kb per transaction =
unlikely, right?
On Tue, Oct 13, 2015 at 4:14 PM, Jonathan Toomim (Toomim Bros) <j at toom.im>
wrote:
>
> On Oct 13, 2015, at 3:49 PM, odinn <odinn.cyberguerrilla at riseup.net>
> wrote:
>
> Signed PGP part
> It would also help to know what operating system(s) you are
> using for both the oldie and the freshie.
>
>
> Linux feather 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3
> (2015-08-04) x86_64 GNU/Linux
> Linux server 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
> Linux prime 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux
>
> This excessive memory consumption was seen on 3 machines, all of which run
> Debian. All three machines run p2pool as well as bitcoind. Two run XT, one
> runs Core.
>
> You should compare this to having set up a node on a completely clean
> computer.
>
>
> I can't afford to do that. All of the servers I have are being used for
> something. Also, I'm not sure what it is you're trying to test for with
> that suggestion. The numbers I'm reporting are for bitcoind's resident set,
> not for the whole server's memory usage. I don't see how other processes
> running on the same machine are relevant unless you are suggesting that RPC
> calls (e.g. getblocktemplate) might be somehow responsible.
>
> Also, dump your XT, is poo.
>
>
> Not relevant. I addressed this message to both the Core and XT lists
> because the issue appears to affect both forks. Let's keep blocksize and
> governance debates to their own threads, please.
>
> Repeating request: Has anyone else seen something similar? Can you report
> your mempool size and total bitcoind resident set size for your running
> full nodes?
>
> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/696b36c5/attachment.html>

2023-06-07 19:42:47

- reply

📅 Original date posted:2015-10-05
📝 Original message:I prefer the hard fork because the complexity introduced by soft forks
scares me.
At
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html
Gregory wrote: "Security requires a bit of vigilance, inherently." and
[A non-upgraded miner will end up] "*> producing invalid blocks forever
until** the owner shuts it down and upgrades. * This is the outcome
guaranteed for absentee miners with a hard fork, but it is not guaranteed
for a soft fork."
It seems that the main benefit of a soft-fork is that it allows
participants on the network to keep participating even if they aren't
vigilant enough to notice and upgrade when that is safest. Are there other
reasons that might entice me if that one by itself is not enough?
Gregory provided two more: [Using soft-forks] "radically lowers (in most of
our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization which
is harmful to decentralization promoting software diversity."
I understand these benefits. The cost in complexity is still too high for
me, and I think most of the pain in "cost of deployment", "industry-wide
flag days," and "tight release synchronization," as well as the
centralizing effect of those things can be minimized with waiting periods.
The promotion of software diversity offered by soft-forks is pretty cool,
but that gets close to messing with fungibility.
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/fdb2dc46/attachment-0001.html>

2023-06-07 19:41:31

- reply

📅 Original date posted:2015-09-28
📝 Original message:Why are they called soft forks when they are really hidden forks? Isn't
the point of a soft fork to prevent old clients from rejecting what they
don't have the code to validate? That seems dangerous.
notplato
On Mon, Sep 28, 2015 at 2:12 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> And still no movement on BIP 63...
>
> https://bitcointalk.org/index.php?topic=1083961.20
>
> Apart from that,
>
> All my prior objections to XT still hold as expressed on this list.
> XT is not acceptable.
>
> On the topic of consensus:
>
> Reaching consensus, I hope, is something that developers can
> accomplish by refining and adjusting the BIPS and coming to agreement
> upon them. This should be something that can be done in a few months
> time, before the end of the year.
>
> Cheers,
>
> - - O
>
> Adam Back via bitcoin-dev:
> > 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
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> There is no consensus on using a soft fork to deploy this
> >> feature. It will result in the same problems as all the other
> >> soft forks - SPV wallets will become less reliable during the
> >> rollout period. I am against that, as it's entirely avoidable.
> >>
> >> Make it a hard fork and my objection will be dropped.
> >>
> >> Until then, as there is no consensus, you need to do one of two
> >> things:
> >>
> >> 1) Drop the "everyone must agree to make changes" idea that
> >> people here like to peddle, and do it loudly, so everyone in the
> >> community is correctly informed
> >>
> >> 2) Do nothing
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev
> >> mailing list bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJWCa0jAAoJEGxwq/inSG8CuCUIALiRt6cE3b+9f+l9m6aMTjIR
> vTEIM/7B4dIZW9eatXmkxyd44uz5YoN93SlZtV62c90HCqqpFRBCfyXRyXzQ11E7
> 0i70or5LnWDOqrD1bSsCEdrQxPIpAQnv101UHe3iyn/uHAVBiz/HfqvGMruNt0r1
> 4sMecp+LedWpy6/p9c6iMHV1rhtYRfmRfJHj+9KlSn+in5PQKx2kieWqpfqjmlNs
> J/UNoLvRuF0YxDcqEdp2BAaI0s+NyXBo3YDi4R77U9YPRj/cYuWHh/yPKAvFW+2K
> 0d9NNuKSKEY/m4uW3ghPEJL7OxlGbOoNWFS3kcKYr+BanfsPTov7yHQhBuRBRPw=
> =hd0W
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/fd9d5a38/attachment.html>

2023-06-07 19:41:00

- reply

📅 Original date posted:2015-09-19
📝 Original message:It seems there should be a practical limit to the size of a re-org - I mean
a practical limit that is smaller than the current height. Vincent's
proposal suggests that a year's worth of blocks is such a practical limit.
I agree. There are probably lower limits that are practical too, but I
like an entire year just to be conservative. As Vincent points out, "An
attacker will need to have hidden hashing power to overwrite a years worth
of blocks."
TL;DR for the rest of this: Txns that lose confirmations from a reorg and
then show up in the mempool but not in any of the next few blocks indicate
malicious mining.
I see a blind spot here. We are seeing the rule that says the longest
chain is the valid chain as impossible to break, but it isn't. We broke it
to fix the BerkelyDB problem. The code itself would have prevented us from
doing that IF 51% of the hashpower had been used to build on the wrong
chain, but it wasn't.
Justus' question about what malicious means is key here. The blind spot is
a bit more complex than just viewing the longest chain as impossible to
break except with more than 51% of the hash power. The blind spot is our
inability to distinguish between malicious blocks and honest blocks.
Rune suggests that empty blocks indicate malice. I like that (which is why
I advocate using BitcoinDaysDestroyed to decide between blocks at the same
height that appear at nearly the same time, rather than first-seen). There
are other methods we can use to distinguish between malicious blocks and
honest ones. I'm inventing one right now, but I'm sure better ones can be
found.
Here's mine: Once a transaction has been confirmed, its originator
generally takes on the responsibility of re-broadcasting it if it gets
re-org'd out of its confirmation(s). Many mempools will see that
re-broadcast, *if it happens*. Any malice in a 51% attack would come in
the form of failing to include such transactions. If we have a history of
orphaned blocks, then we can check to see which ones have been included in
non-orphaned blocks since they got reorg'd out. Such transactions should
be top-priority after a reorg, even if they have zero fees. When there is
a transaction that doesn't appear in a new block within a couple hours of a
reorg, that indicates dishonesty, usually in the sender (but that could be
negligence), but possibly in the miner. Looking at the mempool would
determine which, wouldn't it?
notplato
On Sat, Sep 19, 2015 at 1:11 PM, Rune K. Svendsen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> An honest miner is a miner that supports the network by building on top of
> the best valid chain. A malicious miner is one who wants to disrupt the
> Bitcoin network, not support it, for example by executing a 51% attack
> which mines empty blocks on top of the best chain.
>
>
> /Rune
>
> > Den 19/09/2015 kl. 19.19 skrev Justus Ranvier <
> justus at openbitcoinprivacyproject.org>:
> >
> >> On 19/09/15 10:45, Rune Kjær Svendsen wrote:
> >> We need to distinguish between two different things here:
> >>
> >> 1) A 51% attack, where the majority of mining power is *malicious*
> (hence “attack”)
> >
> > What does "malicious" mean?
> >
> > In other words, If miner A is mining honestly, and miner B is mining
> > maliciously, what are some of the possible difference in their behaviour
> > we would observe?
> >
> >
> > --
> > Justus Ranvier
> > Open Bitcoin Privacy Project
> > http://www.openbitcoinprivacyproject.org/
> > justus at openbitcoinprivacyproject.org
> > E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
> > <0xEAD9E623.asc>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/43bfbb1d/attachment-0001.html>

2023-06-07 19:40:37

- reply

📅 Original date posted:2015-09-20
📝 Original message:Mike wrote:
... Obama would like to restrict guns, but can't, because they are too
popular (in the USA).
... Governments tolerate this sort of abuse [black markets] only because
they believe, I think correctly, that Bitcoin can have great benefits for
their ordinary voters and for now are willing to let the tech industry
experiment.
Those two reasons must be recognized for their differences. What does it
mean that something is "too popular" if the ultimate goal of government is
"great benefits for their ordinary voters"? It means the government
assumes that some things are bad for people even though they are popular.
Crystal meth and heroin come to mind. This is a natural concern of all
decent parents for their children, and the reason that cultures for
millennia have had rites of passage, wherein the child takes on the
responsibility of determining for him or her self whether or not a popular
thing provides great benefits. That responsibility is the birthright of
every human being. Why is there an institution that usurps it? How do the
people within that institution benefit from being part of it?
Some history to study and answer these questions includes:
- The origination of public schooling as motivated by Johann Fichte's
public letters to his king in response to Prussia's loss to Napolean at
Jena.
- Franz Oppenheimer's book, The State, tracing the origination of the
idea of a state, or group of people who make up and enforce laws.
- Carroll Quigley's history book, Tragedy and Hope.
- Larken Rose's book, Kicking the Dragon.
- The Republic, by Plato, but only once you understand those other books.
- If you want a shortcut, John Taylor Gatto did a five-hour interview
which is now titled "The Ultimate History Lesson with John Taylor Gatto."
It is heavily sourced by its producer in case anyone wants to verify the
information he provides.
I'm "notplato" for a reason.
notplato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150920/540fc23e/attachment.html>

2023-06-07 19:40:32

- reply

📅 Original date posted:2015-09-19
📝 Original message:phm got most of this, but...
On Sat, Sep 19, 2015 at 2:53 PM, phm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mike Hearn via bitcoin-dev wrote:
>
> >
> > * Most governments can easily spend enough money to do a 51% attack,
> > especially if they can compel chip fabs to cooperate for free.
> > This attack works regardless of how decentralised Bitcoin is.
> >
> > * Any government can end Bitcoin usage in its territory by jailing
> > anyone who advertises acceptance/trading of bitcoins, or prices in
> > BTC. Because merchants /must/ advertise in order to alert
> > customers that trades in BTC are possible, this is an attack which
> > is unsolvable. If ordinary people can find such merchants so can
> > government agents.
> >
>
Pot is used as money, and they do jail people for it, but it doesn't have
the effect to which you refer. It has the opposite effect, partially
because it enriches suppliers.
The 51% attack is a good point, but they would be taking a huge risk.
Ideas don't die, just people. For example, they got Ross Ulbricht, not DPR.
Government is the group of people that does things that are not acceptable
if anyone else does them, and that is because people cheer for them when
they do those things, rather than pointing out that they are not
acceptable. The movie "The Deep Web" shows how bitcoin helps to turn this
misfortune around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/02521925/attachment.html>

2023-06-07 19:40:27

- reply

📅 Original date posted:2015-09-18
📝 Original message:"But if a metric were chosen that addressed my concerns (worst case
propagation and validation time), then I could be in favor of an initial
bump that allowed a larger number of typical transactions in a block."
+1. A ratio is much more valuable than a simple metric. It seems clearly
difficult to identify a reasonable limit to block size, but the ratio
between any one of several possible metrics and bytes in a block would work
well and may already have a very good reasonable expected range.
I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to
compute, then it need only be computed for all blocks less than or equal in
size to the average size of the largest 200 or so blocks in the previous
difficulty period. To exceed that limit, a miner would have to ensure that
the block has enough BTCDD per byte. "Enough" could be hardcoded in each
release, or if it's simple enough, use the ratio as computed over all the
blocks in the previous difficulty period as the lower limit.
notplato
On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Correction of a correction, in-line:
>
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > - Many interested or at least willing to accept a "short term bump", a
>> > hard fork to modify block size limit regime to be cost-based via
>> > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year
>> > were debated and seemed "in range" with what might work as a short term
>> > bump - net after applying the new cost metric.
>>
>> I would be careful to point out that hard numbers were deliberately NOT
>> discussed. Though some general things were thrown out, they were not
>> extensively discussed nor agreed to. I personally think 2-4 is "in
>> range", though 8 maybe not so much. Of course it depends on exactly how
>> the non-blocksize limit accounting/adjusting is done.
>>
>> Still, the "greatest common denominator" agreement did not seem to be
>> agreeing to an increase which continues over time, but which instead
>> limits itself to a set, smooth increase for X time and then requires a
>> second hardfork if there is agreement on a need for more blocksize at
>> that point.
>>
>
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
>
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined with
> net-UTXO in a way that will allow us to reach consensus.
>
> As a further example, I also am quite concerned about 2-4-8MB with either
> block size or net-UTXO as the base metric. As you say, it depends on how
> the non-blocksize limit accounting/adjusting is done... But if a metric
> were chosen that addressed my concerns (worst case propagation and
> validation time), then I could be in favor of an initial bump that allowed
> a larger number of typical transactions in a block.
>
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While being
> conservative with respect to exponentials, I would very much like to make
> sure that there is a long-term growth curve as part of any proposal. I am
> willing to accept a hard-fork if the adopted plan is too conservative, but
> I do not want to be kicking the can down the road to a scheduled 2nd hard
> fork that absolutely must occur. That, I feel, could be a more dangerous
> outcome than an exponential that outlasts conservative historical trends.
>
> I commend Jeff for writing a Chatham-rules summary of the outcome of some
> hallway conversations that occurred. On the whole I think his summary does
> represent the majority view of the opinions expressed by core developers at
> the workshop. I will caution though that on nearly every issue there were
> those expressed disagreement but did not fight the issue, and those who
> said nothing and left unpolled opinions. Nevertheless this summary is
> informative as it feeds forwards into the design of proposals that will be
> made prior to the Hong Kong workshop in December, in order that they have a
> higher likelihood of success.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/5700f8e2/attachment.html>

2023-06-07 19:40:01

- reply

📅 Original date posted:2015-09-12
📝 Original message:>
> From the Bitcoin wiki page on transaction fees
> <https://en.bitcoin.it/wiki/Transaction_fees#Technical_info>:
>
> Transaction priority is calculated as a value-weighted sum of input age,
> divided by transaction size in bytes: priority =
> sum(input_value_in_base_units * input_age)/size_in_bytes
>
If I read that correctly, that is directly proportional to BTCDD, so
whatever effect concerns you has already been built into the code.
On Fri, Sep 11, 2015 at 3:21 PM, Vincent Truong <
vincent.truong at procabiak.com> wrote:
> Would this alter the way txns will be prioritised in order to try to win?
> You would always pick txns with the best BTCDD to maximize your chances of
> being the block to build on.
>
> I see this as potentially being a bad outcome for bitcoin's fungibility.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150912/3d8a53d4/attachment.html>

2023-06-07 19:40:00

- reply

📅 Original date posted:2015-09-11
📝 Original message:Yes, this proposal is a policy that everyone would be free to ignore. I
should have introduced the situation in which this *unenforceable* policy
makes sense to me. Here it is:
Every miner is listening for valid block solutions but might receive two
valid blocks and then they have to decide which one to use. Choosing the
one you saw first is the default behavior. In that situation, we'd all
like everyone to choose the same block. I propose that a better heuristic
than "first seen" is to compare the BTCDD, *but only of transactions you
already have in your mempool*, and
*weight the BTCDD so that txns you got earlier are more important.*
The heuristic is most useful when the two blocks are received within a
small window of time, opting for the first-seen rule otherwise. I assume
many miners have an idea of how long it takes for anyone's new block to get
across the network, and more specifically, the range of times it takes for
new solutions to get to themselves. During this little time window, the
chances are 50/50 that they'll choose the right block. If the default
behavior were to use BTCDD during that time window (one second? I have no
idea!), then the chances would be significantly better.
I think Jorge is right that it doesn't benefit miners. It doesn't hurt
them either, unless they are trying to do selfish mining. Well, it
benefits them in terms of increased bitcoin stability by A) making it
easier for clients to decide which block is valid when they see two
competing with each other, B) motivating miners to add transactions instead
of mining empty blocks, C) severely decreasing the utility of any global
private network of nodes intended to spread selfishly-mined blocks, and D)
motivating miners to stay well-connected so that they get transactions
quickly.
I sent this to the list because it is only useful if it is set as default
behavior since most miners leave the defaults alone, and the benefits don't
materialize unless a majority follows the policy.
On Fri, Sep 11, 2015 at 11:37 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
> wrote:
> >
> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>
> I thought he was proposing a new consesnsus rule. I see, this would be
> just a policy validation that everybody would be free to ignore (like the
> "first seen" spend conflict tx replacement policy).
>
> I don't see how miners would benefit from running this policy so I would
> not expect them to run it in the long run (like the "first seen" spend
> conflict tx replacement policy).
> If miners don't use it, I don't see how users can benefit from running
> that policy themselves.
> They will still have to keep waiting some block confirmation to
> exponentially reduce the chances of a successful double-spend attack with
> each new confirmation (as explained in the bitcoin white paper).
>
> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
> > empty blocks and leave it at that, or only switch if the new block
> > doesn't double spend transactions in the old one, so it's a fixable
> > issue.
>
> How do you know which of 2 blocks with the same height is "newer"?
>
> > On 11 September 2015 at 12:32, Jorge Timón
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
> > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >>
> > >> Rather than (promising to, and when they don't actually, at least
> > >> pretending to) use the first-seen block, I propose that a more
> sophisticated
> > >> method of choosing which of two block solutions to accept.
> > >
> > > There's already a criterion to chose: the one with more work (in valid
> > > blocks) on top of it.
> > >
> > >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/5d843513/attachment.html>

2023-06-07 19:39:59

- reply

📅 Original date posted:2015-09-11
📝 Original message:Rather than (promising to, and when they don't actually, at least
pretending to) use the first-seen block, I propose that a more
sophisticated method of choosing which of two block solutions to accept.
Essentially, a miner receiving two solutions at the same height would
compute a weighted sum of bitcoin-days-destroyed (transactions received
earlier get higher weights) of whatever transactions are in a block *and
also* were in the miner's mempool *before* the first solution arrived.
Whichever block has more wins.
This strategy avoids allowing miners to use private transactions to mess
with the blockchain. It also makes an empty block far less attractive
because it is easily replaced, all the way until the next block locks it
in. Any block-selection heuristic can be gamed, but I believe that using a
weighted sum of BTCDD is harder to game than using block propagation timing.
I asked Can Bitcoin Days Destroyed be a better resolution mechanism for
competing blocks?
<http://bitcoin.stackexchange.com/questions/39226/can-bitcoin-days-destroyed-be-a-better-resolution-mechanism-for-competing-blocks>
on the stackexchange bitcoin site in order to collect objections to and
problems with this idea, and have not found any that I haven't addressed.
The best objection is that *maybe* empty blocks and selfish mining are
either good for bitcoin, or else they are so minimally bad that no effort
ought to be expended in preventing them.
If anyone here thinks this is a good idea, and no one can offer reasons
it's a bad idea, I will probably start working on an implementation. I'm
really slow though, so ping me if it looks like fun to you.
notplato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/3ecf1dff/attachment-0001.html>

2023-06-07 19:39:17

- reply

📅 Original date posted:2015-09-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I suggest revising these items for clarity (and I'm guessing on the first
one)
Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile.
A new hardLimit may not increase or decrease by more than 1.2x beyond
the prior hardLimit.
to:
The new hardLimit is calculated by sorting the coinbase scriptSig votes
of the last 12,000 blocks from lowest to highest and using the vote of the
2400th block.
If the vote of the 2400th block is a change of less than 20%, use it as
the new hardLimit. Otherwise, change the hardLimit to be closer to that
vote, to either 120% or 80% of the current hardLimit.
I don't understand #5, 75% rule. Shouldn't invalid version 4 blocks always
be rejected?
notplato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJV58/5AAoJEL8dSijmIbHt16IH/0jAr3v1HjWW7N1awNxeAABs
GIvOFYuZAcPkZvWZQc4JRAppglqeBfYqWl2gpyywSBK1SXjsY8zdo3t7xAK/IJfB
05hnv1GGutG3dLTzJBEXaPx62SLukepC1pzEH7rlwWvVuE9zcRqVE1eGbBEUjA9c
sGPr0z9BNeLoTbllyl3Jndz9N2Vnd6bBTxRgBlfkm/Y5ovc+GhyKZyX3Pdmj5Pga
E6foOsvqNXQJqPl8WCODsnfPSshyb7YRNFrBB9A+tpjvj4UMc8PxOpL6IX/nJpOt
jlfRoKVw2YBEodvda+9P6S54GlGFazyHhwJ11F5YCNnWW1bKoQrqJU6ofgmyxMM=
=QWra
-----END PGP SIGNATURE-----
On Wed, Sep 2, 2015 at 8:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP 100 initial public draft:
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>
> Emphasis on "initial" This is a starting point for the usual open source
> feedback/iteration cycle, not an endpoint that Must Be This Way.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/f858063b/attachment.html>

2023-06-07 19:37:05

- reply

📅 Original date posted:2015-08-19
📝 Original message:I guess every mailing list should have its own internal SNR discussions.
My answer is to respond when something is off-topic and offer a different
place for the topic. I haven't been doing that, partly because no one else
has, but mostly because I figured I don't have a strong handle on what is
off-topic and what isn't. Let's all start doing that. Of course, someone
can object to the claim, "No, I don't think this is off-topic... blah blah
blah," and people can respond. The norms will develop. It just requires
some relative humility, courage, and honesty.
On Wed, Aug 19, 2015 at 12:28 PM, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> FYI, a few developers including Wladimir, Greg, Peter Todd, Pieter, and
> Alex Morcos have been discussing what to do about improving the signal
> noise ratio on bitcoin-dev list. One proposal similar to this discussion
> was to split it into multiple mailing lists. It was pointed out that the
> less technical Bitcoin discussion list already existed in the past and
> nobody used it. Generally the discussion went away from creating yet
> another mailing list and toward instituting an on-topic guidelines for
> bitcoin-dev. Gavin, Wladimir, and a few of the others agreed to a simple
> few paragraphs written by Alex Morcos. IIRC Wladimir agreed to post it.
> Has it been posted yet?
>
> On Wed, Aug 19, 2015 at 11:47 AM, Btc Drak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>> > bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
>> > discussion?
>>
>> Well -dev or both, I dont particularly see a difference at the moment,
>> and establishing two lists isnt really going to make a difference so
>> long as Bitcoin Core is the reference client, which it is by defacto.
>> The risk of having too many lists is interested stakeholders will miss
>> a discussions. Normal protocol and core discussions are usually pretty
>> low volume in any case.
>>
>> > As Jorge notes, a general discussion list has existed for a long time
>> with
>> > little use.
>>
>> I would suggest it's only because there havent been any rules for -dev
>> that would force general discussion over to the bitcoin list. On IRC
>> we regularly tell people in #bitcoin-dev they are OT and ask them to
>> move to #bitcoin and as a result, -dev remains quite clear of chit
>> chat, #bitcoin has a steady stream of general chatter.
>>
>> We could reduce the OT/noise of bitcoin-dev list considerably by
>> offloading the non-technical/academic debate to the bitcoin list. It
>> just needs a bit of shepherding. I am more than happy to help out.
>> Especially if the list already exists, we should consider making a
>> decision now.
>>
>> Who are the moderators for that list? Do we really want to use
>> sourceforge or are there alternatives, like another list on
>> linuxfoundation?
>>
>> ping @Warren.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/adb874db/attachment-0001.html>

2023-06-07 19:36:12

- reply

📅 Original date posted:2015-08-18
📝 Original message:Three things:
1) Hostility is generally the result of perceived hostility. If you assume
the best intentions of another person, you will eventually find yourself in
one of two places. Either you will find truth with that person (becuase
they are also seeking it), or you will drive them away (because you will
ask questions that can't be answered by someone trying to deceive).
2) The Wiki says "The current Core developers are Wladimir J. van der Laan,
Gavin Andresen, Jeff Garzik, Gregory Maxwell, and Pieter Wuille." I've
seen no hostility from any of these people.
3) The people who are threatened by Bitcoin aren't stupid enough to ignore
#1. Can anyone imagine that they have not hired highly skilled
psychological warfare agnts to do everything they can to "help" assault
what we decentralization enthusiasts have been working for?
About #2: I'm actually blind to hostility, and that is an intentional
affectation in response to my recognition of #1 and #3 together. If you
feel another person has expressed a bad idea, just ignore it. If you feel
they might be misleading others, post a reply about what you know to clear
up any possible misconceptions. There is no point in identifying
individuals who are being hostile, or pointing out hostility, or being
divisive. Let the rest of us recognize it on our own. Maybe send
something like what I'm writing now.
PS: If anyone is interested in conspiracy theories, I had written this into
my gmail compose window and (presumably) hit a wrong key which caused the
thread to be marked as spam and deleted my whole reply. It hadn't even
saved a draft. I've never seen gmail not save a draft before.
On Mon, Aug 17, 2015 at 9:55 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I should add that in the interest of peace and goodwill, I extend an offer
> to both Mike and Gavin to make their grievances heard…but only on the
> condition that we make a good effort to avoid misrepresentation and
> misreading of the other side’s intentions.
>
> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
>
>
> FWIW,
>
> I don’t think what theymos did is very constructive.I understand his
> position…but it only hurts the cause, unfortunately - the PR battle is not
> the same thing as a discussion on technical merits. He hurts the PR battle
> and plays into Mike’s hand by doing that. The actual underlying issue
> actually has little to do with block size - it has to do with Mike and
> Gavin feeling that the core devs are being obstructionist.
>
> Regardless of the technical merits of XT, the fact that we’ve never done a
> hard fork before, not even for things some other devs have wanted…and not
> due to any malice on anyone’s part but because simply that’s just the
> nature of decentralized consensus with well-defined settlement
> guarantees…this is the problem - Mike and Gavin think they’re somehow
> special and their fork should be pushed while the rest of us resist pushing
> our own controversial pet ideas because we want civility and understand
> that at this stage in Bitcoin’s development trying to fork the blockchain
> over highly divisive issues is counterproductive and destructive.
>
> But the fact of the matter is that in the PR battle, arguments against the
> fork actually play into Mike’s hand, and that’s the problem.
>
> The whole block size thing is too nuanced and too easily spun
> simplistically. It’s too easy to spin resistance to bigger blocks (even
> though the resistance is actually much more towards untested hardforking
> mechanisms and serious security concerns) as “obstructionism” and it’s too
> easy to spin bigger blocks as “scalability” because most of the people
> can’t tell the fucking difference.
>
> The fact is most of the people don’t really understand the fundamental
> issue and are taking sides based on charismatic leadership and authority
> which is actually entirely counter to the spirit of decentralized
> consensus. It’s beyond ironic.
>
> If you guys want to win the PR battle, the key is to make it clear that
> you are not obstructionist and are giving everyone equal treatment…Bitcoin
> was designed such that changing the rules is *hard* and this is a feature.
> Bitcoin simply does not have a reliable and tested hard forking
> mechanism…and a hard fork for such a politically divisive issue will almost
> certainly lead to a lack of cooperation and refusal to work together out of
> spite. All of us would like to be able to process more transactions on the
> network. It’s not a matter of whether we think higher capacity is a bad
> thing - it’s more that some of us are concerned that Bitcoin is not
> sufficiently mature to be able to handle such a schism with so much
> hostility.
>
> Let’s face it, folks - from a PR standpoint, the block size issue is
> irrelevant. Nobody really understands it except for a handful of people -
> I’ve tried to explain it, I’ve even written articles about it - but most
> people just don’t get it. Most people don’t really get scalability either -
> they seem to think that scalability is just doing the same thing you’ve
> always done manyfold.
>
> Block size is an especially dangerous issue politically because it’s one
> of those that requires deep understanding yet superficially sounds really
> simple. It’s perfect Dunning-Kruger bait.
>
> So let’s be a little smarter about this.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/92430846/attachment-0001.html>

2023-06-07 19:33:41

- reply

📅 Original date posted:2015-08-09
📝 Original message:On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> > Someone mentioned that when the backlog grows faster than it shrinks,
> that
> > is a real problem. I don't think it is. It is a problem for those who
> > don't wait for even one confirmation
>
> The mention you refer to was about the fact that the software doesn't cope
> well with a continuously growing mempool.
> If Bitcoind starts eating more and more memory, I expect lots of people
> that
> run it now to turn it off.
>
That is a real problem then. While emptying the mempool faster with bigger
blocks will help to reduce the occurrence of that problem, I propose a
user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size. "This software has stopped consuming
memory necessary to validate transactions. You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.
> > but backlogs in the past have already
> > started training users to wait for at least one confirmation, or go
> > off-chain.
>
> I am wondering how you concluded that? The only time we saw full blocks
> for a
> considerable amount of time was when we had a spammer, and the only thing
> we taught people was to use higher fees.
>
I concluded that because I don't think I'm all that different than others,
and that is what I have done. The "training" of which I speak is not
always recognized by the bitcoiner on whom it operates. A similar
"training" is how we all learn to ignore teachers because governments force
our attendance at school.
> > Everyone else can double-spend (perhaps that's not as easy as
> > it should be in bitcoin core) and use a higher fee, thus competing for
> > block space.
>
> This is false, if you want to double spent you have to do a lot of work and
> have non-standard software. For instance sending your newer transaction
> to a
> random node will almost always get it rejected because its a double spent.
> Replace by fee (even safe) is not supported in the vast majority of Bitcoin
> land.
>
I don't know what you meant to say is false. I agree with the other stuff
you wrote. Thanks for confirming that it is difficult.
I did some research on replace by fee (FSS-RBF) and on
Child-pays-for-parent (CPFP). You point out that these solutions to paying
too-low fees are "not supported in the vast majority...". Do you mean
philosophically or programmatically? The trend seems to me toward
improvements, just as I insinuated may be necessary ("perhaps that's not as
easy as it should be in bitcoin core"), so, once again, I have to reiterate
that transaction backlog has valuable solutions other than increasing the
block size.
I also realized that we have already been through a period of full blocks,
so that tremendously reduces the value I see in doing it again. It was
that "spam" test someone ran that did it for us, and I love that. It seems
to have kicked the fee-increasability efforts in the butt, which is great.
I now place a higher priority on enabling senders to increase their fee
when necessary than on increasing the Txns per second that the network can
handle. The competition between these two is rather unfair because of how
easy it is to apply the "N MB-blocks bandaid".
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/01523c01/attachment-0001.html>

2023-06-07 19:33:38

- reply

📅 Original date posted:2015-08-08
📝 Original message:I see value in lowering the block size or leaving it where it is. We expect
to run out of space, and I think it's a good idea to prepare for that,
rather than avoid it. When we run out of space and the block size is low,
we will see problems. If we raise the block size, we will NOT see these
problems until bitcoin is bigger and more important and the pressure is
higher.
Someone mentioned that when the backlog grows faster than it shrinks, that
is a real problem. I don't think it is. It is a problem for those who
don't wait for even one confirmation, but backlogs in the past have already
started training users to wait for at least one confirmation, or go
off-chain. I am comfortable leaving those zero-conf people in a little bit
of trouble. Everyone else can double-spend (perhaps that's not as easy as
it should be in bitcoin core) and use a higher fee, thus competing for
block space. Yes, $5 transactions suck, but $0.15 is not so bad and about
twice the average right now.
Meanwhile, the higher fees everyone starts feeling like paying, along with
the visibility of the problems caused by full-blocks, will provide
excellent justification and motivation for increasing the limit. My
favorite thing to do is to have a solution ready for a problem I expect to
see, see the problem (so I can measure things about it) and then implement
the solution.
In my experience, the single biggest reason not to run a full node has to
do with starting from scratch: "I used to run a full node, but last time I
had to download the full blockchain, it took ___ days, so I just use (some
wallet) now." I think that has been improved with headers-first, but many
people don't know it.
I have some ideas how a "full node" could postpone being "full" but still
be nearly completely operational so that the delay between startup and
having a full blockchain is nearly painless. It involves bonded
representation of important not-so-large pieces of data (blocks that have
my transactions, the complete UTXO as of some height, etc.). If I know
that I have some btc, I could offer it (say, 100 or 1000 transaction fees'
worth) to anyone who will guarantee good data to me, and then when I have
the whole blockchain, I will know if they were honest. If done right, the
whole network could know whether or not they were honest and enforce the
bond if they weren't. Credit the Lightening paper for parts of this idea.
Dave
On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please try to focus on constructive technical comments.
>
> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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 to say NO to more users.
>
> But > 99% of Bitcoin transactions are already off-chain. There are
> multiple competing companies offering consumer & retail service with
> off-chain settlement.
>
> I wasnt clear but it seemed in your previous mail that you seemed to
> say you dont mind trusting other people with your money, and so
> presumably you are OK using these services, and so have no problem?
>
> > At this time and this size of bitcoin community, my personal experience
> (and
> > I've been part of many communities) saying NO to new customers
>
> Who said no to anything? The systems of off-chain transfer already
> exist and are by comparison to Bitcoins protocol simple and rapid to
> adapt and scale.
>
> Indications are that we can even do off-chain at scale with Bitcoin
> similar trust-minimisation with lightning, and duplex payment
> channels; and people are working on that right now.
>
> I think it would be interesting and useful for someone, with an
> interest in low trust, high scale transactions, to work on and propose
> an interoperability standard and API for such off-chain services to be
> accessed by wallets, and perhaps periodic on-chain inter-service
> netting.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/904426c0/attachment.html>

2023-06-07 19:33:26

- reply

📅 Original date posted:2015-08-08
📝 Original message:Bitcoin is an irreversible payment system. When you pay someone using its
main selling point, which is removing the need for physical presence, you
are trusting that person. Bitcoin doesn't obviate trust. It obviates
authority. Centralization of trust is what creates the authority that we
all recognize as bad for our species. It does this by making the
authority's use of coercion acceptable.
Bitcoin removes the need for authority, not trust. It replaces trust in a
single body with trust in a majority. We want that majority to be healthy
and varied (as opposed to largely co-opted by some authority). The
replacement has two effects. 1) It is very difficult for any single body
to become the (coercive) authority that everyone has to trust (like central
banks). 2) It is very easy for a person to find a different single body to
trust if they don't like the one they are trusting now - or even stop
trusting one body and trust the majority instead, relying on #1 for
protection, and taking on the responsibility of running a full node.
The philosophical foundation of a thing is ultimately the basis of its
value, so I thought it useful to point out the distinction between
authority and trust in the bitcoin ecosystem. I welcome disagreements with
my philosophical position, as that is how I learn.
Dave.
On Fri, Aug 7, 2015 at 3:53 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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 needs some
> reasonable portion of economic interest to be validating their receipt
> of coins against a full node they run.
>
> I do it myself because I dont want to lose money, as do many power
> users. Most bitcoin ecosystem companies do it. You dont have to run
> it all the time, just sync it when you want to check your own coin
> receipt with higher assurance.
>
> > As we concluded in our previous email, the need to run a node is
> inversely
> > proportional to the ability (or willingness) to trust others.
>
> Even if you are willing to trust others, trusting miners or random
> full nodes would be unsafe if not for the reasonable portion of
> economic interest validating their own received coins. That holds
> miners honest, otherwise they could more easily present fake
> information to SPV users.
>
> > And lets face it, practically everyone trusts others with their money
> today.
>
> Bitcoin's very reason for existence is to avoid that need. For people
> fully happy to trust others with their money, Bitcoin may not be as
> interesting to them.
>
> >> If the impact of the system goes u[p], so should the - joint -
> incentives to
> >> keep it secure. And I think we're (slowly) failing at that.
> >
> > That is your opinion.
>
> What Pieter said is an accurate summary and non-controversial.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/7a148b4f/attachment.html>

2023-06-07 19:31:29

- reply

📅 Original date posted:2016-01-07
📝 Original message:Maybe I'm being dense, but I don't see why 2**80 storage is required for
this attack. Also, I don't see why the attacker ever needs to get the
victim to accept "arbitrary_data". Perhaps I'm wrong about how the
collision attack works:
1. Create a script which is perfectly acceptable and would pass the
sniff test Gavin proposed (no arbitrary_data).
2. Set off CPU power to construct a second script that lets attacker
keep his coins and has the same hash. (This is where you get
"arbitrary_data").
3. Send a transaction with the first script to the seller as payment.
4. Wait for the transaction to be included in a block.
5. Redeem the transaction with the second script, thus stealing the
coins back.
So the seller would never see the I'd appreciate any correction to my
understanding here. Where do you need 2**80 storage? And when does the
seller have to accept "arbitrary_data"?
Thanks!
On Thu, Jan 7, 2016 at 11:19 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> You could say 256 bit ECDSA is overkill lets go to 160 equivalently.
> Saves even more bytes.
>
> The problem with arguing down is where to stop.
>
> As Matt said these things dont degrade gracefully so a best practice
> is to aim for a bit of extra margin.
>
> 256-bit is quite common at this point since AES, SHA256 etc even in
> things with much less at stake than Bitcoin.
>
> You could send the compressed (unhashed) pubkey then there's no hash
> (and omit it from the sig). Greg had mentioned that in the past.
>
> I think it might be possible to do both (reclaim the hash bits in the
> serialisation of the pub key).
>
> Adam
>
> On 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I'm hoisting this from some private feedback I sent on the segregated
> > witness BIP:
> >
> > I said:
> >
> > "I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
> > bytes-- a successful preimage attack against that ain't gonna happen
> before
> > we're all dead. I'm probably being dense, but I just don't see how a
> > collision attack is relevant here."
> >
> > Pieter responded:
> >
> > "The problem case is where someone in a contract setup shows you a
> script,
> > which you accept as being a payment to yourself. An attacker could use a
> > collision attack to construct scripts with identical hashes, only one of
> > which does have the property you want, and steal coins.
> >
> > So you really want collision security, and I don't think 80 bits is
> > something we should encourage for that. Normal pubkey hashes don't have
> that
> > problem, as they can't be constructed to pay to you."
> >
> > ... but I'm unconvinced:
> >
> > "But it is trivial for contract wallets to protect against collision
> > attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
> > arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off,
> just
> > ignore that arbitrary data" a wallet can just refuse. Even more likely, a
> > contract wallet won't even recognize that as a pay-to-gavin transaction.
> >
> > I suppose it could be looking for some form of "gavin_pubkey
> > somebody_else_pubkey CHECKMULTISIG ... with the attacker using
> > somebody_else_pubkey to force the collision, but, again, trivial contract
> > protocol tweaks ("send along a proof you have the private key
> corresponding
> > to the public key" or "everybody pre-commits pubkeys they'll use at
> protocol
> > start") would protect against that.
> >
> > Adding an extra 12 bytes to every segwit to prevent an attack that takes
> > 2^80 computation and 2^80 storage, is unlikely to be a problem in
> practice,
> > and is trivial to protect against is the wrong tradeoff to make."
> >
> > 20 bytes instead of 32 bytes is a savings of almost 40%, which is
> > significant.
> >
> > The general question I'd like to raise on this list is:
> >
> > Should we be worried, today, about collision attacks against RIPEMD160
> (our
> > 160-bit hash)?
> >
> > Mounting a successful brute-force collision attack would require at least
> > O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that
> Bitcoin
> > POW has computed more SHA256 hashes than that). But it also requires
> O(2^80)
> > storage, which is utterly infeasible (there is something on the order of
> > 2^35 bytes of storage in the entire world). Even assuming doubling every
> > single year (faster than Moore's Law), we're four decades away from an
> > attacker with THE ENTIRE WORLD's storage capacity being able to mount a
> > collision attack.
> >
> >
> > References:
> >
> > https://en.wikipedia.org/wiki/Collision_attack
> >
> >
> https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/
> >
> >
> > --
> > --
> > Gavin Andresen
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/b5c2e636/attachment.html>

2023-06-07 17:47:29

- reply

📅 Original date posted:2015-08-18
📝 Original message:At
http://media.scmagazine.com/documents/127/virtual_currency_rules_31557.pdf,
section 200.3(c)(2) lists "consumers that utilize Virtual Currency solely
for the purchase or sale of goods or services or for investment purposes"
as "Persons [who] are exempt from the licensing requirements".
Who else is left?
On Mon, Aug 17, 2015 at 1:24 PM, Theo Chino via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> I might have a "crazy" simple solution.
> From the literature I read, it seems that Satochi has the keys that would
> authenticate him using Bitcoin.
>
> HBO John Oliver's program might have given me (and hopefully others) the
> brilliant idea to protect the Bitcoin network from the overzealous reach of
> the politicians. One need to start a Church, and to start the Church one
> need funds (121UZ1hDs9MgCHonA8vjXr89D8FuDf5c7t) to start.
>
> John Oliver's program on HBO about Churches (and the hypocrisy of some)
> was epic and such entity could argue that Bitcoin is a belief system (which
> it is) and would force the issue at a Federal level under the Church and
> State separation. - John's video :
> https://www.youtube.com/watch?v=7y1xJAVZxXg
>
> At this time, I am waiting for the License issue to walk its course in New
> York State.
>
> Currently:
>
> - I am waiting for my License to be denied (to protest) and appeal it.
> - Waiting to hear from the License process to appeal the law in
> general.
> - Meeting Elected officials (in New York City, NY State, and France)
> and educating them on Bitcoin.
>
> Every time we (the community) talk about Bitcoin, it can sound like
> religion; therefore why not go all the way and do what John Oliver did ?
> Seed money would help. :)
>
> Regarding the Fork, from my perspective of a small company, I see that
> like it was with IRC with the ICMP node split. The Church thing is not here
> to take side but to "try" to protect the Bitcoin.
>
> We will need to ordain ministers selected after completing prescribed
> courses of study setup by the developers.
>
> In short I am asking Satochi to help this church with original coins. If
> it is a troll, I am talking to the Dev Community at large to recruit them
> to ordain the ministers.
>
> Regards,
> *Theo Chino*
>
>
> *https://www.facebook.com/groups/557495624389384
> <https://www.facebook.com/groups/557495624389384> (NY
> State)http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york
> <http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york>*
>
> *(My position on the fork is still the same as when I ran for a seat of
> the Foundation; still don't have enough information and thing will move
> faster than I can devote the time to read about it.)*
>
> On Mon, Aug 17, 2015 at 1:30 PM, Btc Drak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> For the record I would like to share my technical analysis of the Satoshi
>> email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few
>> days ago.
>>
>> 1. The email is the one used by Satoshi to announce Bitcoin in the first
>> place.
>> http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
>>
>> 2. The email was not spoofed, it actually originated from vistomail's
>> server. The email headers show the email originated from 190.97.163.93
>> and the SPF records show this as an authorised sender for the email.
>> This does not prove the account wasn't hacked of course, or that the
>> account might have expired and be re-registered by someone else (vistomail
>> is a paid for email provider).
>>
>> 3. While the email is not signed, and there are a number of PGP keys
>> listed on key servers for him (to vary addresses), he didnt sign any emails
>> with any PGP keys.
>>
>> It is therefore not possible to outright dismiss the email's authenticity
>> as the email originates from an authentic source. The only questions is
>> whether the webmail service was hacked or commandeered somehow.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/bd738711/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-31
📝 Original message:Here are some books that will help more people understand why Adam's
concern is important:
Kicking the Dragon (by Larken Rose)
The State (by Franz Oppenheimer)
Like he said, it isn't much about bitcoin. Our crypto is just one of the
defenses we've created, and understanding what it defends will help us
maintain its value.
Dave
On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 notifying you etc that would be great but that's unfortunately not
> what happens.
>
> Data-center operators are bound to follow laws, including NSLs and gag
> orders. They also get hacked, employ humans who can be corrupt,
> blackmailed, and themselves centralisation points for policy attack.
> Snowden related disclosures and keeping aware of security show this is very
> real.
>
> This isn't much about bitcoin even, its just security reality for hosting
> anything intended to be secure via decentralisation, or just hosting in
> general while at risk of political or policy attack.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/2339c6d8/attachment.html>

2023-06-07 17:43:34

- reply

📅 Original date posted:2015-07-24
📝 Original message:On Fri, Jul 24, 2015 at 4:38 AM, Mike Hearn <hearn at vinumeris.com> wrote:
> It's worth noting that even massive companies with $30M USD of funding
>> don't run a single Bitcoin Core node
>
>
> This has nothing to do with block sizes, and everything to do with Core
> not directly providing the services businesses actually want.
>
> The whole "node count is falling because of block sizes" is nothing more
> than conjecture presented as fact. The existence of multiple companies who
> could easily afford to do this but don't because they perceive it as
> valueless should be a wakeup call there.
>
Regardless of why node count is falling, many people who used to run a full
node stopped doing so. To mitigate that, their chances of getting
something out of it have to be greater. What if propagating a valid
transaction generated a small chance of earning a piece of the fee?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/9fb27b1b/attachment.html>

2023-06-07 17:43:32

- reply

📅 Original date posted:2015-07-23
📝 Original message:I used Google to establish that there is not already a post from 2015 that
mentions "roadmap" in the subject line. Such would be a good skeleton for
anyone new to the list (like me).
1. Increase the 7 Tx per second - by increasing block size.
2. Do something about the trend toward centralization. This is really two
issues in my mind:
A) Mining is falling to an ever shrinking number of businesses with the
infrastructure to run a datacenter.
B) The protocol as it is will soon make common computing machines
inadequate for running full nodes, and as a result they will not be able to
contribute to the ecosystem in meaningful ways.
Feel free to copy and then remove or alter any of that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/ea7fd11a/attachment.html>