<unnamed>

Public Key

npub1l899vmy2zhg9zr96jvnxt85ayddd26qu36m02k22759e9djqldnqrhm88x

Profile Code

nprofile1qqs0njjkdj9pt5z3pjafxfn9n6wjxkk4dqwgadh4t9902zujkeq0kespz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsajt9gs

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:54:11 UTC

- reply

📅 Original date posted:2016-10-27
📝 Original message:I have been reading recently through the history of soft forks provided by
Bitcoin Core:
https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks
.
It has led me to think that there is a deceiving notion that soft forks do
not force Bitcoin users to upgrade software. Yes, it's true that the past
soft forks still allow old nodes to accept blocks under the tighter rules
as valid, but what about miners who are still using old software? What
about users who want to make a transaction using the old rules? Those
people are no longer able to do those things. And if they want to do those
things, a hard fork will result.
Remember what happened when BIP 66 was activated? Luckily, it was short
lived, but this is just the beginning. If you keep tightening the rules,
you are building up more and more pressure for a split in the network to
occur. You can call this split a "hard fork" or just a "fork", but it is
dangerous either way, and it leads to basically the creation of two coins
when before we just had one, people instantly lose value, and the trust in
Bitcoin's store of value dies.
Obviously every one can debate about what should be the definition of a
soft fork, but whatever that is, I think it is unacceptable how sloppily
the past soft forks have been deployed. I can think of many ways in which
we could have these new features that the soft forks provided, but without
forcing the new rules, and simply making them features that can be used on
an individual miner or transaction signer basis. Is there a document from
Bitcoin Core that outlines the philosophy of soft forks and why it is
acceptable to force the tightening of rules and cause such risks? And
please give me another reason other than "it removes a few if statements
from the code".
Now that Segregated witness is scheduled to be deployed on November 15, we
should take a look at this "soft fork" as well. I like the idea of
Segregated Witness, but from conversations on Reddit and IRC, I see people
saying that this soft fork will be like the others: requiring a hard fork
in order to revert it. Is this true? I am getting conflicting messages by
reading the BIP. It says that if all transactions are non-segwit, then a
node will validate the block as before. But if we pass the threshhold
(usually 95 % for 1000 blocks) will miners mining non-segwit blocks be
ignored? This is not good... I really think we should make it optional.
Miners will have an incentive to mine segwit blocks, since it allows for
more transactions per block, so why force them? What if we want to slightly
modify the Segwit protocol in the future? What if we want to replace segwit
with something much different? We will be forced to do a hard fork in order
to do that.
Now, we can't go back in time and fix the deployment of the soft forks, but
I do propose one clean way to fix things: Remove all the previously "soft
forked" rules for non segwit transactions, and require them only for segwit
transactions. But make segwit optional! In addition to what I talked about
above, this may also relieve some tensions of people who are not
comfortable with segwit and are thinking of joining a hard fork like the
Bitcoin Unlimited project.
Unless people can give me a good explanation as to why we are deploying
soft forks in such forceful manner, or Bitcoin Core accepts my proposal,
then I will have no choice but to create a new client (I'm thinking to call
it Bitcoin Authentic), that will be just as Bitcoin Core but will always
follow the chain with the most work regardless of whether soft fork rules
are respected, and I would put at least CHECKLOCKTIMEVERIFY as mandatory
within segwit transactions.
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161027/5d5cc827/attachment.html>

2023-06-07 17:46:48 UTC

- reply

📅 Original date posted:2015-12-19
📝 Original message:On Fri, Dec 18, 2015 at 2:47 AM, Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 1) The risk of an old full node wallet accepting a transaction that is
> invalid to the new rules.
>
> The receiver wallet chooses what address/script to accept coins on.
> They'll upgrade to the new softfork rules before creating an address
> that depends on the softfork's features.
>
> So, not a problem.
>
>
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob runs
> the old rules. Bob creates a p2pkh address for Mallory to use. Mallory
> takes 1 BTC, and creates an invalid SegWit transaction that Bob cannot
> properly validate and that pays into one of Mallory's wallets. Mallory then
> immediately spends the unconfirmed transaction into Bob's address. Bob sees
> what appears to be a valid transaction chain which is not actually valid.
>
> What do you mean a valid transaction chain? If Bob is fully validating
(even with old software), he should see that Mallory's signature is not on
a transaction with his address.
Do you mean Mallory creates a regular transaction as well as an
Anyone-can-spend segwit transaction that results in double spending in the
same block?
Sorry not sure what I'm missing...
> Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
> mining node. Carol sees that Mallory included an enormous fee in his
> transactions, so Carol makes sure to include both transactions in her
> block.
>
> Mallory gets free beer.
>
> Anything I'm missing?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/7dec3138/attachment.html>

2023-06-07 17:45:58 UTC

- reply

📅 Original date posted:2015-12-09
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/19e592c7/attachment.html>

2023-06-07 15:42:28 UTC

- reply

📅 Original date posted:2015-07-17
📝 Original message:What are you trying to do? Break the ice with a hard fork so that later it
becomes easier to do so, with people more complacent towards it? There are
many solutions to the scaling problem that do not require a hard fork and
are quite simple to implement actually, and don't come with the
complications involved with a hard fork. I'm not a reputable developer on
this list, so my opinion probably doesn't matter much, but I watched and
analyzed this situation closely and I don't like this idea.
On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan to
> my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity. A good backup plan.
>
> Benefits: conservative increase. proves network can upgrade. permits
> some added growth, while the community & market gathers data on how an
> increased block size impacts privacy, security, centralization, transaction
> throughput and other metrics. 2MB seems to be a Least Common Denominator
> on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the road.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/540d1554/attachment-0001.html>

2023-06-07 15:33:07 UTC

- reply

📅 Original date posted:2015-05-07
📝 Original message:I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of "apps" that depend on
zero conf instant transactions, so this would of course require more
traffic on the blockchain. I think people like Gavin or Mike should state
clearly what kind of (rigorous) system for instant transactions is
satisfactory for use in their applications. Be it lightning or something
similar, what is good enough? And no zero conf is not a real secure system.
Then once we know what is good enough for them (and everyone else), we can
implement it as a soft fork into the protocol, and it's a win win situation
for both sides (we can also benefit from all the new users people like Mike
are trying bring in).
On Thu, May 7, 2015 at 10:52 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike at plan99.net> wrote:
> > I observed to Wladimir and Gavin in private that this timeline meant a
> change to the block size was unlikely to get into 0.11, leaving only 0.12,
> which would give everyone only a few months to upgrade in order to fork the
> chain by the end of the winter growth season. That seemed tight.
>
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> I assume that you are expecting full blocks by then, have you used any
> statistical technique to come up with that date or is it just your
> guess?
> Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>
> > What we need to see right now is leadership and a plan, that fits in the
> > available time window.
> >
> >>
> >> Certainly a consensus in this kind of technical community should be a
> >> basic requirement for any serious commitment to blocksize increase.
> >
> >
> > I'm afraid I have come to disagree. I no longer believe this community
> can
> > reach consensus on anything protocol related. Some of these arguments
> have
> > dragged on for years. Consensus isn't even well defined - consensus of
> who?
> > Anyone who shows up? And what happens when, inevitably, no consensus is
> > reached? Stasis forever?
>
> We've successfully reached consensus for several softfork proposals
> already.
> I agree with others that hardfork need to be uncontroversial and there
> should be consensus about them.
> If you have other ideas for the criteria for hardfork deployment all I'm
> ears.
> I just hope that by "What we need to see right now is leadership" you
> don't mean something like "when Gaving and Mike agree it's enough to
> deploy a hardfork" when you go from vague to concrete.
>
>
> >> Long-term incentive compatibility requires that there be some fee
> >> pressure, and that blocks be relatively consistently full or very nearly
> >> full.
> >
> >
> > I disagree. When the money supply eventually dwindles I doubt it will be
> fee
> > pressure that funds mining, but as that's a long time in the future, it's
> > very hard to predict what might happen.
>
> Oh, so your answer to "bitcoin will eventually need to live on fees
> and we would like to know more about how it will look like then" it's
> "no bitcoin long term it's broken long term but that's far away in the
> future so let's just worry about the present".
> I agree that it's hard to predict that future, but having some
> competition for block space would actually help us get more data on a
> similar situation to be able to predict that future better.
> What you want to avoid at all cost (the block size actually being
> used), I see as the best opportunity we have to look into the future.
>
> >> What we see today are
> >> transactions enjoying next-block confirmations with nearly zero pressure
> >> to include any fee at all (though many do because it makes wallet code
> >> simpler).
> >
> >
> > Many do because free transactions are broken - the relay limiter means
> > whether a free transaction actually makes it across the network or not is
> > basically pot luck and there's no way for a wallet to know, short of
> either
> > trying it or actually receiving every single transaction and repeating
> the
> > calculations. If free transactions weren't broken for all non-full nodes
> > they'd probably be used a lot more.
>
> Free transactions are a gift from miners that run an altruistic policy.
> That's great but we shouldn't rely on them for the future. They will
> likely disappear at some point and that's ok.
> In any case, he's not complaining about the lack of free transactions,
> more like the opposite.
> He is saying that's very easy to get free transactions in the next
> block and blocks aren't full so there's no incentive to include fees
> to compete for the space.
> We can talk a lot about "a fee market" and build a theoretically
> perfect fee estimator but we won't actually have a fee market until
> there's some competition for space.
> Nobody will pay for space that's abundant just like people don't pay
> for the air they breath.
>
> > What I don't see from you yet is a specific and credible plan that fits
> > within the next 12 months and which allows Bitcoin to keep growing. Not
> some
> > vague handwave like "let's all use the Lightning network" (which does not
> > exist), or "let's do more research" (Gavin has done plenty of research),
> or
> > "but what about the risks" (Bitcoin is full of risks). A plan, with dates
> > attached, and a strong chance of actually being deployed in time.
>
> Ok, this is my plan: we wait 12 months, hope that your estimations are
> correct (in case that my guess was better than yours, we keep waiting
> until June 2017) and start having full blocks and people having to
> wait 2 blocks for their transactions to be confirmed some times.
> That would be the beginning of a true "fee market", something that
> Gavin used to say was his #1 priority not so long ago (which seems
> contradictory with his current efforts to avoid that from happening).
> Having a true fee market seems clearly an advantage.
> What are supposedly disastrous negative parts of this plan that make
> an alternative plan (ie: increasing the block size) so necessary and
> obvious.
> I think the advocates of the size increase are failing to explain the
> disadvantages of maintaining the current size. It feels like the
> explanation are missing because it should be somehow obvious how the
> sky will burn if we don't increase the block size soon.
> But, well, it is not obvious to me, so please elaborate on why having
> a fee market (instead of just an price estimator for a market that
> doesn't even really exist) would be a disaster.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/1bc393f5/attachment.html>