<unnamed>

Public Key

npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8

Profile Code

nprofile1qqs28pre2vgvagvn0hdy6q0w3u2v5u6tnfatvrrzz999v4nsdc27glcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjz7ve4

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:11:26 CEST

- 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-07 20:17:25 CEST

- 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 19:56:44 CEST

- 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:49:31 CEST

- 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:04 CEST

- reply

📅 Original date posted:2016-01-23
📝 Original message:+1
The distinction we are making importantly requires that contributors
provide readers with another thing to say in favor of something - another
thing which is different than "X people support this instead of only X-1
people." Evidence trumps votes.
On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > I would extend this to say that the technical explanation also should
> > contribute uniquely to the conversation; a +1 with an explanation
> > the last +1 gave isn't useful.
>
> Yes, comments should contribute to the discussion, with either technical
> discussion or additional relevant data. I think a +1 like the following
> should be encouraged:
>
> "+1: we had eleven customer support tickets in just the last week that
> would have been prevented if XYZ.
>
> Jane Doe, CTO CoinBitChainBasely.com"
>
> _______________________________________________
> 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/20160123/573d40da/attachment.html>

2023-06-07 19:47:38 CEST

- 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 19:46:59 CEST

- 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 CEST

- 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:00 CEST

- reply

📅 Original date posted:2015-12-10
📝 Original message:If we partition the work using bits from the TxID (once it is no longer
malleable) or even bits from whatever definition we use for "coin," then
every transaction may have to use all the other partitions to verify that
the incoming coin is good.
If all partitions are involved in validating and storing every transaction,
then we may be doing more work in total, but any one node will only have to
do (and store) a fraction of what it is now. We would want the current
situation to be identical to one in which all the participants are handling
all the partitions. So how can we break up the work so that any
participant can handle whatever fraction of the work he or she wants? One
idea is to use the last bits of the address that will receive the subsidy
and fees. You solve the block for your partition by determining that all
transactions in the block are valid against the subset of blocks whose
hashes end with the same bits.
This solution is broadcast in the hope that others will start attempting to
validate that same block on their own partition. If they are mining the
same partition, they simply change their subsidy address to work on a
different partition. Each time a new-but-not-last partition is solved,
everyone working on the block adds the new solver's output address to their
generation transaction with the appropriate fraction of the
reward-plus-subsidy. In this way, several miners contribute to the
solution of a single block and need only store those blocks that match the
partitions they want to work on.
Suppose we use eight bits so that there are 256 partitions and a miner
wishes to do about 1/5 of the work. That would be 51 partitions. This is
signaled in the generation transaction, where the bit-pattern of the last
byte of the public key identifies the first partition, and the proportion
of the total reward for the block (51/256) indicates how many partitions a
solution will cover.
Suppose that the last byte of the subsidy address is 0xF0. This means
there are only 16 partitions left, so we define partition selection to wrap
around. This 51/256 miner must cover partitions 0xF0 - 0xFF and 0x00 -
0x23. In this way, all mining to date has covered all partitions.
The number of bits to be used might be able to be abstracted out to a
certain level. Perhaps a miner can indicate how many bits B the
partitioning should use in the CoinBase. The blocks for which a partition
miner claims responsibility are all those with a bit pattern of length B at
the end of their hash matching the the bits at the end of the first
output's public key in the generation transaction, as well as those blocks
with hashes for which the last B bits match any of the next N bit patterns
where for the largest integer N for which the claimed output is not less
than (subsidy+fees)*(N/(2^B)).
If you only store and validate against one partition, and that partition
has a solution already, then you would start working on the next block
(once you've validated the current one against your subset of the
blockchain). You could even broadcast a solution for that next block
before the previous block is fully solved, thus claiming a piece of the
next block reward (assuming the current block is valid on all partitions).
It seems that a miner who covers only one partition will be at a serious
disadvantage, but as the rate of incoming transactions increases, the
fraction of time he must spend validating (being about half of all other
miners who cover just one more partition) makes up for this disadvantage
somewhat. He is a "spry" miner and therefore wins more rewards during
times of very dense transaction volume. If we wish to encourage miners to
work on smaller partitions, we can provide a difficulty break for smaller
fractions of the work. In fact, the difficulty can be adjusted down for
the first solution, and then slowly back up to full for the last
partition(s).
This proposal has the added benefit of encouraging the assembly of blocks
by miners who work on single partitions to get them out there with a
one-partition solution.
On Wed, Dec 9, 2015 at 2:35 PM, Andrew via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Akiva
>
> I sketched out a similar proposal here:
> https://bitcointalk.org/index.php?topic=1083345.0
>
> It's good to see people talking about this :). I'm not quite convinced
> with segregated witness, as it might mess up some things, but will take a
> closer look.
> On Dec 9, 2015 7:32 AM, "Loi Luu via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Dear Akiva,
>>
>> Its Loi Luu, one of the authors of the SCP protocol (
>> http://eprint.iacr.org/2015/1168.pdf ).
>>
>> Before SCP, we had been thinking hard about how to do sharding
>> efficiently without degrading any security guarantee. A simple solution
>> which splits the coins, or TXs in to several partitions will just not work.
>> You have to answer more questions to have a good solutions. For example, I
>> wonder in your proposal, if a transaction spends a "coin" that ends in "1"
>> and creates a new coin that ends in "1", which partition should process the
>> transaction? What is the prior data needed to validate that kind of TXs?
>>
>> The problem with other proposals, and probably yours as well, that we
>> see is that the amount of data that you need to broadcast immediately to
>> the network increases linearly with the number of TXs that the network can
>> process. Thus, sharding does not bring any advantage than simply using
>> other techniques to publish more blocks in one epoch (like Bitcoin-NG,
>> Ghost). The whole point of using sharding/ partition is to localize
>> the bandwidth used, and only broadcast only a minimal data to the network.
>>
>> Clearly we are able to localize the bandwidth used with our SCP protocol.
>> The cost is that now recipients need to themselves verify whether a
>> transaction is double spending. However, we think that it is a reasonable
>> tradeoff, given the potential scalability that SCP can provides.
>>
>> Thanks,
>> Loi Luu.
>>
>> On Wed, Dec 9, 2015 at 12:27 AM, Akiva Lichtner via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hello,
>>>
>>> I am seeking some expert feedback on an idea for scaling Bitcoin. As a
>>> brief introduction: I work in the payment industry and I have twenty years'
>>> experience in development. I have some experience with process groups and
>>> ordering protocols too. I think I understand Satoshi's paper but I admit I
>>> have not read the source code.
>>>
>>> The idea is to run more than one simultaneous chain, each chain
>>> defeating double spending on only part of the coin. The coin would be
>>> partitioned by radix (or modulus, not sure what to call it.) For example in
>>> order to multiply throughput by a factor of ten you could run ten parallel
>>> chains, one would work on coin that ends in "0", one on coin that ends in
>>> "1", and so on up to "9".
>>>
>>> The number of chains could increase automatically over time based on the
>>> moving average of transaction volume.
>>>
>>> Blocks would have to contain the number of the partition they belong to,
>>> and miners would have to round-robin through partitions so that an attacker
>>> would not have an unfair advantage working on just one partition.
>>>
>>> I don't think there is much impact to miners, but clients would have to
>>> send more than one message in order to spend money. Client messages will
>>> need to enumerate coin using some sort of compression, to save space. This
>>> seems okay to me since often in computing client software does have to
>>> break things up in equal parts (e.g. memory pages, file system blocks,) and
>>> the client software could hide the details.
>>>
>>> Best wishes for continued success to the project.
>>>
>>> Regards,
>>> Akiva
>>>
>>> P.S. I found a funny anagram for SATOSHI NAKAMOTO: "NSA IS OOOK AT MATH"
>>>
>>>
>>> _______________________________________________
>>> 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/20151209/7030e17e/attachment-0001.html>

2023-06-07 19:45:11 CEST

- reply

📅 Original date posted:2015-11-27
📝 Original message:I was curious about there being only 10 single-byte opcodes left. There
are ten single-byte OP_NOPx opcodes defined, but there are 15 opcodes that
"simply *do not exist anymore* in the protocol" because they are scary (had
bugs that "could crash any Bitcoin node if exploited" or "allowed anyone to
spend anyone's bitcoins"). There are also 66 single-byte values that are
currently reserved, 186 - 252 (0xba - 0xfc).
If the name OP_CHECKSEQUENCEVERIFY should not be changed, each of us has a
single best reason not to change it. Finding other reasons suggests that
one's top reason isn't good enough. See Nassim Taleb's book, Antifragile,
if that claim makes you curious. The same goes for changing it. In any
case, it is 178 (0xb2) and app developers can call it whatever they want.
It seems trivial to me since the following, in script.h, would neither slow
compilation nor confuse anyone, but could lead the curious to explore the
history and expand their knowledge:
OP_NOP3 = 0xb2,
OP_CHECKSEQUENCEVERIFY = OP_NOP3,
OP_CHECKMATURITYVERIFY = OP_NOP3, // A comment defending the alternative
name
I don't know the consensus here on leaving breadcrumbs in code comments
(and enum/variable names) for curious coders to use as inspiration for
studying the history, but I advocate it, since modern IDEs are fairly
well-equipped to make skipping or hiding comments easy.
On Wed, Nov 25, 2015 at 3:05 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Looks like I'm the long dissenting voice here? As the originator of the
> name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
> appropriately chosen and why the proposed alternatives don't stand up.
>
> First, the names are purposefully chosen to illustrate what they do:
>
> What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
> What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.
>
> Second, the semantics are not limited to relative lock-time / maturity
> only. They both leave open ranges with possible, but currently undefined
> future consensus-enforced behavior. We don't know what sort of future
> behavior these values might trigger, but the associated opcodes are generic
> enough to handle them:
>
> CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
> though such constraints have no meaning in Bitcoin.
> CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
> while checking only 17 of the available 39 bits of both the operand and the
> nSequence. Indeed the most recent semantic change of CSV was justified in
> part because it relaxes all constraints over the values of these bits
> freeing them for other purposes in transaction validation and/or future
> extensions of the opcode semantics.
>
> Third, single-byte opcode space is limited. There are less than 10 such
> opcodes left. Maybe space won't be so precious in a post-segwitness world,
> but I don't want to presume that just yet.
>
>
> As for the alternatives, they capture only the initial use case of
> nSequence. My objection would relax if nSequence were renamed, but I think
> that would be too disruptive and unnecessary. In any case, the imagined use
> cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
> of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
> was a hypothicated opcode that directly checked the minimum age of inputs
> of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
> hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
> hypothicated opcode that would check a ficticious nRelativeLockTime field,
> which does not exist. Again my objection would go away if we renamed
> nSequence, but I actually think the nSequence name is better...
>
> On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> BIP68 introduces relative lock-time semantics to part of the nSequence
>> field leaving the majority of bits undefined for other future applications.
>>
>> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is
>> specifically limited to verifying transaction inputs according to BIP68's
>> relative lock-time[1], yet the _name_ OP_CSV is much boarder than that. We
>> spent months limiting the number of bits used in BIP68 so they would be
>> available for future use cases, thus we have acknowledged there will be
>> completely different usecases that take advantage of unused nSequence bits.
>>
>> For this reason I believe the BIP112 should be renamed specifically for
>> it's usecase, which is verifying the time/maturity of transaction inputs
>> relative to their inclusion in a block.
>>
>> Suggestions:-
>>
>> CHECKMATURITYVERIFY
>> RELATIVELOCKTIMEVERIFY
>> RCHECKLOCKTIMEVERIFY
>> RCLTV
>>
>> We could of course softfork additional meaning into OP_CSV each time we
>> add new sequence number usecases, but that would become obscure and
>> confusing. We have already shown there is no shortage of opcodes so it
>> makes no sense to cram everything into one generic opcode.
>>
>> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
>> rather than focusing on the bitcoin internals.
>>
>> [1]
>> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>>
>> _______________________________________________
>> 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/20151126/53c45125/attachment.html>

2023-06-07 19:43:17 CEST

- 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 CEST

- 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 CEST

- 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 CEST

- 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:40:53 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:I am in a timezone that uses DST (currently PDT), but I would like us to
use a timezone that does NOT use DST. It will be nice to have something
that reflects the seasonal patterns like my own body does. I hate the time
change in both ways.
On Fri, Sep 18, 2015 at 2:50 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> > Google calendar is localised, so it doesn't matter. The problem with
> > quoting UTC anyway it the meeting times are going to change for those
> that
> > observe DST. It would be much better to quote an actual timezone of an
> > actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
> > example. Otherwise when the clocks change, what was a convenient meeting
> > time will become inconvenient for some.
>
> Not everyone does crazy clock-changing. Using such a time system for
> scheduling seems to inconvenience the wrong position. (although perhaps
> arguably better since most people probably use DST) :p
>
> (Aside, if Google Calendar can't support standard UTC, that sounds like an
> argument against using Google Calendar...)
>
> > Urgh... Can we hardfork time? It's clearly in need of an upgrade...
>
> Tonal time works nice any consistently. :D
>
> 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/20150918/3727a8c0/attachment.html>

2023-06-07 19:40:32 CEST

- 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 CEST

- 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:39:17 CEST

- 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:38:20 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:Prabhat,
You write about OFAC, KYC, and AML.
The *Office of Foreign Assets Control* (*OFAC*) is a financial intelligence
<https://en.wikipedia.org/wiki/Financial_intelligence> and enforcement
agency of the U.S. government charged with planning and execution of
economic and trade sanctions
<https://en.wikipedia.org/wiki/Economic_sanctions> in support of U.S. national
security
<https://en.wikipedia.org/wiki/National_Security_of_the_United_States>
and foreign
policy <https://en.wikipedia.org/wiki/Foreign_policy_of_the_United_States>
objectives.
KYC means "Know Your Customer" which is something every intelligent
businessman does when his deals are significant. Support for "KYC" is
built into reality and needs no qualification, compliance, or control.
AML means "Anti-Money-Laundering" which smacks of overreach. Laundering
money serves to hide behaviors that authorities dislike, many of which are
actually helping the world. Neomoney says it best
<http://neomoney.net/?p=426>: "Indeed, money laundering describes a wide
range of activities that are undertaken by innocent participants in the
economy. Authorities’ growing expectation of a right to violate our privacy
to enforce their laws, and an expectation that we do nothing to protect
ourselves from that violation of privacy, lie at the heart of money
laundering propaganda."
So your work comes across as that of someone who has been duped into doing
the bidding of the largest and most successful criminal organization on
Earth. I do not accuse you of being deceived because no one can be blamed
for the damage done to them by such a powerful parasite. I wish only to
open your eyes, or, at least what worked for me, your ears
<http://peacerevolution.podomatic.com/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/83887135/attachment.html>

2023-06-07 19:35:47 CEST

- 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>

2023-06-07 19:33:38 CEST

- 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 CEST

- 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 17:47:29 CEST

- reply

2023-06-07 17:45:47 CEST

- 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 17:45:45 CEST

- reply

2023-06-07 17:45:34 CEST

- reply

2023-06-07 17:43:34 CEST

- 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>