<unnamed>

Public Key

npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzw

Profile Code

nprofile1qqs832nfy5y4kc5ajk570xhddmva5ztnywdudmklzxh5yfq0pcwh2hqpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqg0sqef

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:06:37 CEST

- reply

📅 Original date posted:2017-09-29
📝 Original message:I had the same concern, or a miner could fill the remainder of the block
with their own high fee paying transactions if blocks were required to be
full.
On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If
> I were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
> _______________________________________________
> 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/20170929/7873796c/attachment.html>

2023-06-07 20:05:51 CEST

- reply

📅 Original date posted:2017-09-11
📝 Original message:I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.
1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know where you draw the line on who you tell and
who you don't.
2- Unlike other software, I'm not sure good security for bitcoin is defined
by constant upgrading. Obviously upgrading has an important benefit, but
one of the security considerations for Bitcoin is knowing that your
definition of the money hasn't changed. Much harder to know that if you
change software.
On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > I believe there continues to be concern over a number of altcoins which
> > are running old, unpatched forks of Bitcoin Core, making it rather
> > difficult to disclose issues without putting people at risk (see, eg,
> > some of the dos issues which are preventing release of the alert key).
> > I'd encourage the list to have a discussion about what reasonable
> > approaches could be taken there.
>
> That seems like it just says bitcoin core has two classes of users:
> people who use it directly following mainnet or testnet, and people who
> make derived works based on it to run altcoins.
>
> Having a "responsible disclosure" timeline something like:
>
> * day -N: vulnerability reported privately
> * day -N+1: details shared amongst private trusted bitcoin core group
> * day 0: patch/workaround/mitigation determined, CVE reserved
> * day 1: basic information shared with small group of trusted users
> (eg, altcoin maintainers, exchanges, maybe wallet devs)
> * day ~7: patches can be included in git repo
> (without references to vulnerability)
> * day 90: release candidate with fix available
> * day 120: official release including fix
> * day 134: CVE published with details and acknowledgements
>
> could make sense. 90 days / 3 months is hopefully a fair strict upper
> bound for how long it should take to get a fix into a rc; but that's still
> a lot longer than many responsible disclosure timeframes, like CERT's at
> 45 days, but also shorter than some bitcoin core minor update cycles...
> Obviously, those timelines could be varied down if something is more
> urgent (or just easy).
>
> As it is, not publishing vulnerability info just seems like it gives
> everyone a false sense of security, and encourages ignoring good security
> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
> implementations keep up to date...
>
> I suppose both "trusted bitcoin core group" and "small group of trusted
> users" isn't 100% cypherpunk, but it sure seems better than not both not
> disclosing vulnerability details, and not disclosing vulnerabilities
> at all... (And maybe it could be made more cypherpunk by, say, having
> the disclosures to trusted groups have the description/patches get
> automatically fuzzed to perhaps allow identification of leakers?)
>
> Cheers,
> aj
>
> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > > Hi,
> > >
> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > > conference, and the subsequent discussion around responsible disclosure
> > > and industry practice, perhaps now would be a good time to discuss
> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> > >
> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> > >
> > > To quote:
> > >
> > > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > > not yet publicly disclosed? Is the following list of Bitcoin CVEs
> > > up-to-date?
> > >
> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> > >
> > > There have been no new CVEs posted for almost three years, except for
> > > CVE-2015-3641, but there appears to be no information publicly
> available
> > > for that issue:
> > >
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> > >
> > > It would be of great benefit to end users if the community of clients
> > > and altcoins derived from Bitcoin Core could be patched for any known
> > > vulnerabilities.
> > >
> > > Does anyone keep track of security related bugs and patches, where the
> > > defect severity is similar to those found on the CVE list above? If
> > > yes, can that list be shared with other developers?"
> > >
> > > Best Regards,
> > > Simon
> > > _______________________________________________
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/e2ab7b78/attachment-0001.html>

2023-06-07 19:54:19 CEST

- reply

📅 Original date posted:2016-11-16
📝 Original message:I think we are misunderstanding the effect of this change.
It's still "OK" for a 50k re-org to happen.
We're just saying that if it does, we will now have potentially introduced
a hard fork between new client and old clients if the reorg contains
earlier signaling for the most recent ISM soft fork and then blocks which
do not conform to that soft fork before the block height encoded activation.
I think the argument is this doesn't substantially add to the confusion or
usability of the system as its likely that old software won't even handle
50k block reorgs cleanly anyway and there will clearly have to be human
coordination at the time of the event. In the unlikely event that the new
chain does cause such a hard fork, that coordination can result in everyone
upgrading to software that supports the new rules anyway.
So no, I don't think we should add a checkpoint. I think we should all
just agree to a hard fork that only has a very very slim chance of any
practical effect.
In response to Thomas' email. I think ideally we would treat these soft
forks the way we did BIP30 which is to say that we're just introducing a
further soft fork that applies to all blocks except for the historical
exceptions. So then its a almost no-op soft fork with no risk of hard
fork. This however isn't practical with at least BIP 34 without storing
the hashes of all 200K blocks that don't meet the requirement.
On Wed, Nov 16, 2016 at 9:18 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Are checkpoints good now? Are hard forks okay now?
>>
>
> I think that at least one checkpoint should be included. The assumption
> is that no 50k re-orgs will happen, and that assumption should be directly
> checked.
>
> Checkpointing only needs to happen during the headers-first part of the
> download.
>
> If the block at the BIP-65 height is checkpointed, then the comparisons
> for the other ones are automatically correct. They are unnecessary, since
> the checkpoint protects all earlier block, but many people would like to be
> able to verify the legacy chain.
>
> This makes the change a soft-fork rather than a hard fork. Chains that
> don't go through the checkpoint are rejected but no new chains are allowed.
>
> _______________________________________________
> 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/20161116/5e407283/attachment-0001.html>

2023-06-07 19:48:43 CEST

- reply

📅 Original date posted:2016-02-07
📝 Original message:I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.
And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience. In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now. There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.
And the back and forth discussion over your BIP has been in large part a
charade. People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are. Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements. For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen. Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption. If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.
On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
>> wrote:
>> > > None of the reasons you list say anything about the fact that "being
>> > > lost" (kicked out of the network) is a problem for those node's users.
>> >
>> > That's because its not.
>> >
>> > If you have a node that is "old" your node will stop getting new blocks.
>> > The node will essentially just say "x-hours behind" with "x" getting
>> larger
>> > every hour. Funds don't get confirmed. etc.
>>
>> Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> blocks
>> confirming a large 10000 BTC payment. If you're just a normal end user (or
>> perhaps an automated system), you'll figure that payment is good and
>> irreversibly hand over the title to the house.
>>
>
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).
>
> So it will take a week to get 6 confirmations.
>
> If you are a full node, you are warned that your software is obsolete and
> you must upgrade.
>
> If you are a lightweight node, it SHOULD tell you something is wrong, but
> even if it doesn't, given that people running lightweight nodes run them so
> they don't have to be connected to the network 24/7, it is very likely
> during that week you disconnect and reconnect to the network several times.
> And every time you do that you increase your chances that you will connect
> to full nodes on the majority branch of the chain, where you will be told
> about the double-spend.
>
> All of that is assuming that there is no OTHER mitigation done. DNS seeds
> should avoid reporting nodes that look like they are in the middle of
> initial block download (that are at a block height significantly behind the
> rest of the network), for example.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20160207/b8871116/attachment-0001.html>

2023-06-07 19:40:55 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.
On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>
> Currently an attacker with >50% of the network hashrate can rewrite
> history.
>
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
>
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
> > Currently, when a new node wants to join the network, it needs to
> retrieve the entire blockchain history, starting from January 2009 and up
> until now, in order to derive a UTXO set that it can verify new
> blocks/transactions against. With a blockchain size of 40GB and a UTXO size
> of around 1GB, the extra bandwidth required is significant, and will keep
> increasing indefinitely. If a newly mined block were to include the UTXO
> set hash of the chain up until the previous block — the hash of the UTXO
> set on top of which this block builds — then new nodes, who want to know
> whether a transaction is valid, would be able to acquire the UTXO set in a
> trustless manner, by only verifying proof-of-work headers, and knowing that
> a block with an invalid UTXO set hash would be rejected.
> >
> > I’m not talking about calculating a complicated tree structure from the
> UTXO set, which would put further burden on already burdened Bitcoin Core
> nodes. We simply include the hash of the current UTXO set in a newly
> created block, such that the transactions in the new block build *on top*
> of the UTXO set whose hash is specified. This actually alleviates Bitcoin
> Core nodes, as it will now become possible for nodes without the entire
> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly
> and using this to answer queries). It also saves bandwidth for Bitcore Core
> nodes, who only need to send roughly 1GB of data, in order to synchronise a
> node, rather than 40GB+. I will continue to run a full Bitcoin Core node,
> saving the entire blockchain history, but it shouldn’t be a requirement to
> hold the entire transaction history in order to start verifying new
> transactions.
> >
> > As far as I can see, this also forces miners to actually maintain an
> UTXO set, rather than just build on top of the chain with the most
> proof-of-work. Producing a UTXO set and verifying a block against a chain
> is the same thing, so by including the hash of the UTXO set we force miners
> to verify the block that they want to build on top of.
> >
> > Am I missing something obvious, because as far as I can see, this solves
> the problem of quadratic time complexity for initial sync:
> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
> >
> > The only added step to verifying a block is to hash the UTXO set. So it
> does require additional computation, but most modern CPUs have a SHA256
> throughput of around 500 MB/s, which means it takes only two seconds to
> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s).
> A small sacrifice for the added ease of initial syncing, in my opinion.
> >
> > /Rune
> > _______________________________________________
> > 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/20150918/b0e1a5b4/attachment-0001.html>

2023-06-07 19:40:49 CEST

- reply

📅 Original date posted:2015-09-17
📝 Original message:+1
sounds good to me!
On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntary, but it may be good to have a time that
> many people are expected to be present and current issues can be discussed.
>
> Any preference for days/times?
>
> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
> Wladimir
> _______________________________________________
> 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/20150917/074771ec/attachment.html>

2023-06-07 19:33:56 CEST

- reply

📅 Original date posted:2015-08-10
📝 Original message:Gavin,
They are not analogous.
Increasing performance and making other changes that will help allow
scaling can be done while at small scale or large scale.
Dealing with full blocks and the resultant feedback effects is something
that can only be done when blocks are full. It's just too complicated a
problem to solve without seeing the effects first hand, and unlike the
block size/scaling concerns, its binary, you're either in the situation
where demands outgrows supply or you aren't.
Fee estimation is one example, I tried very hard to make fee estimation
work well when blocks started filling up but it was impossible to truly
test and in the small sample of full blocks we've gotten since the code
went live, many improvements made themselves obvious. Expanding mempools
is another issue that doesn't exist at all if supply > demand. Turns out
to also be a difficult problem to solve.
Nevertheless, I mostly agree that these arguments shouldn't be the reason
not to expand block size, I think they are more just an example of how
immature all of this technology is, and we should be concentrating on
improving it before we're trying to scale it to world acceptance levels.
The saddest thing about this whole debate is how fundamental improvements
to the science of cryptocurrencies (things like segregated witness and
confidential transactions) are just getting lost in the circus debate
around trying to cram a few more users into the existing system sooner
rather than later.
On Mon, Aug 10, 2015 at 10:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>> >
>> > I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> What are the other reasons?
>>
>> > I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>> When "the network runs out of capacity" (when we hit the limit) do we
>> expect anything to happen apart from minimum market fees rising (above
>> zero)?
>> Obviously any consequences of fees rising are included in this concern.
>>
> It is frustrating to answer questions that we answered months ago,
> especially when I linked to these in response to your recent "increase
> advocates say that not increasing the max block size will KILL BITCOIN"
> false claim:
> http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
> Executive summary: when networks get over-saturated, they become
> unreliable. Unreliable is bad.
>
> Unreliable and expensive is extra bad, and that's where we're headed
> without an increase to the max block size.
>
> RE: the recent thread about "better deal with that type of thing now
> rather than later" : exactly the same argument can be made about changes
> needed to support a larger block size-- "better to do that now than to do
> that later." I don't think either of those arguments are very convincing.
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150810/e46ab2bb/attachment.html>

2023-06-07 19:33:38 CEST

- reply

📅 Original date posted:2015-08-08
📝 Original message:I agree
There are a lot of difficult technical problems introduced by insufficient block space that are best addressed now. As well as problems that scale will exacerbate like bootstrapping that we should develop solutions for first.
Sent from my iPad
> On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 and Meme Racing (in alpha).
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
> _______________________________________________
> 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/20150808/e5e734f6/attachment-0001.html>

2023-06-07 19:32:28 CEST

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
> As far as I can tell, nobody besides miners running old and/or buggy
> software lost money due to outsourced mining validation (please correct me
> if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
> bitcoin.org seem to have freaked out and pushed the panic button (with
> dire warnings of not trusting transactions until 20 confirmations), but
> theymos was well known for using an old, patched version of Core for
> blockexplorer.com so maybe that's not surprising.
>
>
I'm also looking forward to Greg's post-mortem, because I had a completely
different takeaway from the BIP66 mini-forks. My view is that despite the
extremely cautious and conservative planning for the completely
uncontentious fork, the damage could and would have been very significant
if it had not been for several core devs manually monitoring, intervening
and problem solving for other network participants. I don't believe thats
the way the system should work. Participants in the Bitcoin community have
come to rely on the devs for just making sure everything works for them.
That's not sustainable. The system needs to be made fundamentally more
secure if its going to succeed, not depend on the good will of any
particular parties, otherwise it certainly will no longer be permissionless.
The BIP66 fork was urgently required to fix an undisclosed consensus bug,
unanimously agreed on and without technical objection, and it was still
fraught with problems. That's the most clear cut example of when we should
have a fork. A change to a consensus limit that a significant proportion
of the community disagrees with for economic or technical reasons or both
should be raising a sea of red flags.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/b2ddba5d/attachment.html>

2023-06-07 17:48:41 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:This is a message that I wrote and had hoped that all the core devs would
sign on to, but I failed to finish organizing it. So I'll just say it from
myself.
There has been a valuable discussion over the last several months regarding
a hard fork with respect to block size. However the sheer volume of email
and proportion of discussion that is more philosophical than technical has
rendered this list almost unusable for its primary purpose of technical
discussion related to Bitcoin development. Many of us share the blame for
letting the discourse run off topic to such a degree, and we hope that an
appeal for individual self restraint will allow this list to return to a
higher signal-to-noise ratio.
-Please consider the degree to which any email you send is related to
technical development before sending it.
-Please consider how many emails you are sending to this list regarding the
same topic.
This list is not appropriate for an endless back and forth debate on the
philosophical underpinnings of Bitcoin. Although such a debate may be
worthwhile it should be taken to another forum for discussion. Every email
you send is received by hundreds of developers who value their time as much
as you value yours. If your intended audience isn't really the majority of
them, perhaps private communication would be more appropriate.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/68f13345/attachment-0001.html>

2023-06-07 17:46:01 CEST

- reply

2023-06-07 17:45:46 CEST

- reply

2023-06-07 17:44:48 CEST

- reply

2023-06-07 17:42:50 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:Jeff I respectively disagree with many of your points, but let me just
point out 2.
Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen. Look at all the
work that has been put into fee estimation, why do that work if the
expectation was there would be no fee pressure?
I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them. Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter. We only have the privilege of even having this debate as a result
of his work.
On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Some people have called the prospect of limited block space and the
>> development of a fee market a change in policy compared to the past. I
>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
>> economy, and its developers have no authority to set its rules. Change in
>> economics is always happening, and should be expected. Worse, intervening
>> in consensus changes would make the ecosystem more dependent on the group
>> taking that decision, not less.
>>
>>
> This completely ignores *reality*, what users have experienced for the
> past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the
> scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic
> bursts, fee pressure has been largely absent.
>
> Moving to a new economic policy where fee pressure is consistently present
> is radically different from what users, markets, and software have
> experienced and *lived.*
>
> Analysis such as [1][2] and more shows that users will hit a "painful"
> "wall" and market disruption will occur - eventually settling to a new
> equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> First, users & market are forced through this period of chaos by "let a
> fee market develop" as the whole market changes to a radically different
> economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block
> size limit will be increased eventually. What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and
> disruption as the fee market is rebooted *again* by changing the block
> size limit.
>
> The average user hears a lot of noise on both sides of the block size
> debate, and really has no idea that the new "let a fee market develop"
> Bitcoin Core policy is going to *raise fees* on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon
> them
>
>
>
>> So to point out what I consider obvious: if Bitcoin requires central
>> control over its rules by a group of developers, it is completely
>> uninteresting to me. Consensus changes should be done using consensus, and
>> the default in case of controversy is no change.
>>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy -
> not seen in the entire 6 year history of bitcoin - is to stonewall work on
> block size.
>
> Closing size increase PRs and failing to participate in planning for a
> block size increase accomplishes your stated goal of changing bitcoin to a
> new economic policy.
>
> "no [code] change"... changes bitcoin to a brand new economic policy,
> picking economic winners & losers. Some businesses will be priced out of
> bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
> move as increasing the hard limit by hard fork.
>
>
>
>> My personal opinion is that we - as a community - should indeed let a fee
>> market develop, and rather sooner than later, and that "kicking the can
>> down the road" is an incredibly dangerous precedent: if we are willing to
>> go through the risk of a hard fork because of a fear of change of
>> economics, then I believe that community is not ready to deal with change
>> at all. And some change is inevitable, at any block size. Again, this does
>> not mean the block size needs to be fixed forever, but its intent should be
>> growing with the evolution of technology, not a panic reaction because a
>> fear of change.
>>
>> But I am not in any position to force this view. I only hope that people
>> don't think a fear of economic change is reason to give up consensus.
>>
>
> Actually you are.
>
> When size increase progress gets frozen out of Bitcoin Core, that just
> *increases* the chances that progress must be made through a contentious
> hard fork.
>
> Further, it increases the market disruption users will experience, as
> described above.
>
> Think about the users. Please.
>
>
>
> _______________________________________________
> 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/20150722/2fd9f799/attachment-0001.html>

2023-06-07 17:40:37 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I think thats the crux of the issue: "some uses fit, some don't".
I don't think anyone can claim to know which fall in which category for
sure. But its clear that with the existing technology, achieving
decentralization and lack of trusted third parties is expensive, therefore
I think it does the world a disservice to pretend everyone can put their
microtransactions on the block chain.
More importantly, I don't think I'm worried about economic policy or change
at all. I'm worried about decentralization. That's the piece we should be
concentrating on. Sure a bitcoin with giant blocks could probably serve a
bunch more use cases, but what value would it provide if there are 10
centralized miners and processing nodes running the network. We'll beat
out Apple Pay or Paypal or Google at their game? Who cares.
On Fri, Jun 26, 2015 at 2:12 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> I am not saying that economic change is what we want. Only that it is
> inevitable, independent of whether larger blocks happen or not.
>
> I am saying that acting because of fear of economic change is a bad
> reason. The reason for increase should be because of the higher utility. We
> need it at some point, but there should be no rush.
>
> I do understand that we want to avoid a *sudden* change in economic
> policy, but I'm generally not too worried. Either fees increase and they
> get paid, and we're good. But more likely is that some uses just move
> off-chain because the block chain does not offer what they need. That's
> sad, but it is inevitable at any size: some uses fit, some don't.
>
> --
> Pieter
> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>
>> It is not "fear" of fee pressure.
>>
>> 1) Blocks are mostly not-full on average.
>>
>> 2) Absent long blocks and stress tests, there is little fee pressure
>> above the anti-spam relay fee metric, because of #1.
>>
>> 3) As such, inducing fee pressure is a delta, a change from years-long
>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin
>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
>> lobbies miners to upgrade.
>>
>> (note - this is not an endorsement of these actions - it is a neutral
>> observation)
>>
>> 4) Inaction leads to consistent fee pressure as the months tick on and
>> system volume grows; thus, inaction leads to economic policy change.
>>
>> 5) Economic policy change leads to market and software disruption. The
>> market and software - notably wallets - is not prepared for this.
>>
>> 6) If you want to change economic policy, that's fine. But be honest and
>> admit you are arguing for a change, a delta from current market
>> expectations and behavior.
>>
>> 7) It is critical to first deal with what _is_, not what you wish the
>> world to be. You want a fee market to develop. There is nothing wrong
>> with that desire. It remains a delta from where we are today, and that is
>> critically relevant in a $3b+ market.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille at gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> here I'm going to try to address a part of the block size debate which
>>> has been troubling me since the beginning: the reason why people seem to
>>> want it.
>>>
>>> People say that larger blocks are necessary. In the long term, I agree -
>>> in the sense that systems that do not evolve tend to be replaced by other
>>> systems. This evolution can come in terms of layers on top of Bitcoin's
>>> blockchain, in terms of the technology underlying various aspects of the
>>> blockchain itself, and also in the scale that this technology supports.
>>>
>>> I do, however, fundamentally disagree that a fear for a change in
>>> economics should be considered to necessitate larger blocks. If it is, and
>>> there is consensus that we should adapt to it, then there is effectively no
>>> limit going forward. This is similar to how Congress voting to increase the
>>> copyright term retroactively from time to time is really no different from
>>> having an infinite copyright term in the first place. This scares me.
>>>
>>> Here is how Gavin summarizes the future without increasing block sizes
>>> in PR 6341:
>>>
>>> > 1. Transaction confirmation times for transactions with a given fee
>>> will rise; very-low-fee transactions will fail to get confirmed at all.
>>> > 2. Average transaction fee paid will rise
>>> > 3. People or applications unwilling or unable to pay the rising fees
>>> will stop submitting transactions
>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting
>>> growth and adoption
>>>
>>> Is it fair to summarize this as "Some use cases won't fit any more,
>>> people will decide to no longer use the blockchain for these purposes, and
>>> the fees will adapt."?
>>>
>>> I think that is already happening, and will happen at any scale. I
>>> believe demand for payments in general is nearly infinite, and only a small
>>> portion of it will eventually fit on a block chain (independent of whether
>>> its size is limited by consensus rules or economic or technological means).
>>> Furthermore, systems that compete with Bitcoin in this space already offer
>>> orders of magnitude more capacity than we can reasonably achieve with any
>>> blockchain technology at this point.
>>>
>>> I don't know what subset of use cases Bitcoin will cater to in the long
>>> term. They have already changed - you see way less betting transactions
>>> these days than a few years ago for example - and they will keep changing,
>>> independent of what effective block sizes we end up with. I don't think we
>>> should be afraid of this change or try to stop it.
>>>
>>> If you look at graphs of block sizes over time (for example,
>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
>>> little "organic" growth, and a lot of sudden changes (which could
>>> correspond to changing defaults in miner software, introduction of popular
>>> sites/services, changes in the economy). I think these can be seen as the
>>> economy changing to full up the available space, and I believe these will
>>> keep happening at any size effectively available.
>>>
>>> None of this is a reason why the size can't increase. However, in my
>>> opinion, we should do it because we believe it increases utility and
>>> understand the risks; not because we're afraid of what might happen if we
>>> don't hurry up. And from that point of view, it seems silly to make a huge
>>> increase at once...
>>>
>>> --
>>> Pieter
>>>
>>>
>>> _______________________________________________
>>> 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/20150626/70106007/attachment.html>

2023-06-07 17:40:04 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:+1 Mark!
On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented. We talk about it
> quite often in fact as it is a defining characteristic of how bitcoin is
> developed which differs in some ways from how other open source software is
> developed -- although it remains the same in most other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get merged
> when there are a few reviews, tests, and ACKs from recognized developers,
> there are no outstanding objections, and the maintainer doing the merge
> makes a subjective judgement that the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core only
> after the above criteria are met AND an extremely long discussion period
> that has given all the relevant stakeholders a chance to comment, and no
> significant objections remain. Consensus-code changes are unanimous. They
> must be.
>
> The sort of process that exists in standards bodies for example, with
> working groups and formal voting procedures, has no place where changes
> define the nature and validity of other people's money. Who has the right
> to reach into your pocket and define how you can or cannot spend your
> coins? The premise of bitcoin is that no one has that right, yet that is
> very much what we do when consensus code changes are made. That is why when
> we make a change to the rules governing the nature of bitcoin, we must make
> sure that everyone is made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
> indication is that BIP 66 will complete deployment in the very near future,
> and we intend to repeat this process for more interesting changes such as
> BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This is
> about no one having the right to decide these things on the behalf of
> others. If a contentious change is proposed and not accepted by the process
> of consensus, that is because the process is doing its job at rejecting
> controversial changes. It has nothing to do with personality, and
> everything to do with the nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> I have seen this question asked many times. Most developers become
>> defensive and they usually give a very vague 1-sentence answer when this
>> question is asked. It seems to be it is based on personalities rather than
>> any kind of definable process. To have that discussion the personalities
>> must be separated out and answers like "such-and-such wouldn't do that"
>> don't really do much to advance the discussion. Also, the incentive for
>> new developers to come in is that they will be paid by companies who want
>> to influence the code and this should be considered (some developers take
>> this statement as an insult when it is just a statement of the incentive
>> process).
>>
>> The other problem you are having is the lead developer does not want to
>> be a "decider" when, in fact, he is a very significant decider. While the
>> users have the ultimate choice in a practical sense the chief developer is
>> the "decider." Now people don't want to get him upset so nobody wants to
>> push the issue or fully define the process. Now you are left with a
>> broken, unwritten/unspoken process. While this type of thing may work with
>> a small group of developers businesses/investors looking in from the
>> outside will see this as a risk.
>>
>> Until you get passed all the personality-based arguments you are going to
>> have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>
>>> I would like to start a civil discussion on an undefined, or at least
>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>> these voters sufficient for approval? If not, then what is?
>>>
>>> Raystonn
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/3c10f6ac/attachment.html>

2023-06-07 17:38:33 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:Not that I know how to do this, but would you be willing to attempt some
other method of measuring just how much of a "super-majority" we have
before deploying code? Maybe that information would be helpful for
everyone. Obviously such a poll couldn't be perfect, but maybe better than
the information we have now.
A) I don't believe we should consider changing the 1 MB limit now
B) I conceptually believe in increasing block size, but would like to
follow a more conservative process and wait to see if a stronger technical
consensus on a plan to do so can develop.
C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait
til this is fully specified, but again not deployed)
Perhaps there can even be 4 polls:
Miners can vote in coinbases
Known corporate entities can announce their vote
Does the Bitcoin Foundation infrastructure still exist to represent some
authenticated (I think) set of individuals
A reddit poll
I don't even know if I think this is a good idea, but just trying to find a
way to move forward where more of us are on the same page.
On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos at gmail.com> wrote:
>
>> Let me take a pass at explaining how I see this.
>>
>> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
>> the decider but he works under a process that is well understood by
>> developers on the project in which he takes under reasonable consideration
>> other technical opinions and prefers to have clear agreement among them.
>>
>
> Yes.
>
> 2) Changes to the consensus rules: As others have said, this isn't
>> anyone's decision for anyone else.
>>
>
> Yes.
>
>
>> It's up to each individual user as to what code they run and what rules
>> they enforce. So then why is everyone so up in arms about what Mike and
>> Gavin are proposing if everyone is free to decide for themselves? I
>> believe that each individual user should adhere to the principle that there
>> should be no changes to the consensus rules unless there is near complete
>> agreement among the entire community, users, developers, businesses miners
>> etc. It is not necessary to define complete agreement exactly because every
>> individual person decides for themselves. I believe that this is what
>> gives Bitcoin, or really any money, its value and what makes it work, that
>> we all agree on exactly what it is. So I believe that it is misleading and
>> bad for Bitcoin to tell users and business that you can just choose without
>> concern for everyone else which code you'll run and we'll see which one
>> wins out. No. You should run the old consensus rules (on any codebase you
>> want) until you believe that pretty much everyone has consented to a change
>> in the rules. It is your choice, but I think a lot of people that have
>> spent time thinking about the philosophy of consensus systems believe that
>> when the users of the system have this principle in mind, it's what will
>> make the system work best.
>>
>
> I don't think I agree with "pretty much everybody", because status-quo
> bias is a very powerful thing. Any change that disrupts the way they've
> been doing things will generate significant resistance -- there will be 10
> or 20% of any population that will take a position of "too busy to think
> about this, everything seems to be working great, I don't like change, NO
> to any change."
>
> For example, I think some of the resistance for bigger blocks is coming
> from contributors who are worried they, personally, won't be able to keep
> up with a bigger blockchain. They might not be able to run full nodes from
> their home network connections (or might not be able to run a full node AND
> stream Game of Thrones), on their old raspberry pi machines.
>
> The criteria for me is "clear super-majority of the people and businesses
> who are using Bitcoin the most," and I think that criteria is met.
>
>
>
>> 3) Code changes to Core that do change consensus: I think that Wladimir,
>> all the other committers besides Gavin, and almost all of the other
>> developers on Core would defer to #2 above and wait for its outcome to be
>> clear before considering such a code change.
>>
>
> Yes, that's the way it has mostly been working. But even before stepping
> down as Lead I was starting to wonder if there are ANY successful open
> source projects that didn't have either a Benevolent Dictator or some clear
> voting process to resolve disputes that cannot be settled with "rough
> consensus."
>
>
> --
> --
> Gavin Andresen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/a6d09f1f/attachment.html>

2023-06-07 17:38:32 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:Let me take a pass at explaining how I see this.
1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
the decider but he works under a process that is well understood by
developers on the project in which he takes under reasonable consideration
other technical opinions and prefers to have clear agreement among them.
2) Changes to the consensus rules: As others have said, this isn't anyone's
decision for anyone else. It's up to each individual user as to what code
they run and what rules they enforce. So then why is everyone so up in
arms about what Mike and Gavin are proposing if everyone is free to decide
for themselves? I believe that each individual user should adhere to the
principle that there should be no changes to the consensus rules unless
there is near complete agreement among the entire community, users,
developers, businesses miners etc. It is not necessary to define complete
agreement exactly because every individual person decides for themselves.
I believe that this is what gives Bitcoin, or really any money, its value
and what makes it work, that we all agree on exactly what it is. So I
believe that it is misleading and bad for Bitcoin to tell users and
business that you can just choose without concern for everyone else which
code you'll run and we'll see which one wins out. No. You should run the
old consensus rules (on any codebase you want) until you believe that
pretty much everyone has consented to a change in the rules. It is your
choice, but I think a lot of people that have spent time thinking about the
philosophy of consensus systems believe that when the users of the system
have this principle in mind, it's what will make the system work best.
3) Code changes to Core that do change consensus: I think that Wladimir,
all the other committers besides Gavin, and almost all of the other
developers on Core would defer to #2 above and wait for its outcome to be
clear before considering such a code change.
I'm sure my description of point 2 is not the most eloquent or clear, but
maybe someone else can try to elucidate this principle if they've grasped
what I'm trying to say.
On Thu, Jun 18, 2015 at 1:04 PM, <justusranvier at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2015-06-18 16:28, Jeff Garzik wrote:
> > This is an engineering list. The quote precisely describes how the
> > bitcoin
> > consensus system functions.
> >
> > Users' choice is largely binary: Follow the rules, or bitcoin software
> > ignores you.
>
>
> Software engineers should understand that they have a binary choice:
> produce the software that your customers want, or the world will ignore
> your software.
>
> There is *no inherent value* to Bitcoin's software rules. The only value
> that is exists is that produced by the individuals who voluntarily
> choose to run the software.
>
> Failing to account for all design requirements is bad engineering.
> Nobody cares about the design features of a bridge to nowhere.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
> 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
> EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
> yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
> 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
> 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
> FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
> Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
> SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
> LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
> Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
> 0A+51wwSZnAdMIw7lwIb
> =r4Co
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/bb6ae32f/attachment.html>

2023-06-07 17:38:13 CEST

- reply

📅 Original date posted:2015-06-15
📝 Original message:Aaron,
My understanding is that Gavin and Mike are proceeding with the XT fork, I
hope that understanding is wrong.
As for improving the non-consensus code to handle full blocks more
gracefully. This is something I'm very interested in, block size increase
or not. Perhaps I shouldn't hijack this thread, but maybe there are others
who also believe this would ameliorate some of the time pressure for
deciding on a block size increase.
What is it that you would like to see improved?
The fee estimation code that is included for 0.11 will give much more
accurate fee estimates, which should allow adding the correct fee to a
transaction to see it likely to be confirmed in a reasonable time. For
further improvements:
- There has recently been attention to overhauling the block creation and
mempool limiting code in such a way that actual outstanding queues to be
included in a block could also be incorporated in fee estimation. See
https://github.com/bitcoin/bitcoin/pull/6281.
- CPFP and RBF are candidates for inclusion in core soon, both of which
could be integrated into transaction processing to handle the edge cases
where a priori fee estimation fails. See
https://github.com/bitcoin/bitcoin/pull/1647 and
https://github.com/bitcoin/bitcoin/pull/6176
I know there has been much discussion of fee estimation not working for SPV
clients, but I believe several independent servers which were serving the
estimates from full nodes would go a long way towards allowing that
information to be used by SPV clients even if its not a completely
decentralized solution. See for example
http://core2.bitcoincore.org/smartfee/latest.json
On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine at gmail.com> wrote:
> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman <brianchoffman at gmail.com>
> wrote:
>
>> Who is actually planning to move to Bitcoin-XT if this happens?
>>
>> Just Gavin and Mike?
>>
>> [image: image1.JPG]
>>
>> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00 at gmail.com> wrote:
>>
>> I'm quite puzzled by the response myself, it doesn't seem to address some
>> of the (more serious) concerns that Adam put out, the most important
>> question that was asked being the one regarding personal ownership of the
>> proposed fork:
>>
>> "How do you plan to deal with security & incident response for the
>> duration you describe where you will have control while you are deploying
>> the unilateral hard-fork and being in sole maintainership control?"
>>
>> I do genuinely hope that whomever (now and future) wishes to fork the
>> protocol reconsider first whether they are truly ready to test/flex their
>> reputation/skills/resources in this way... Intuitively, to me it seems
>> counterproductive, and I don't fully believe it is within a single
>> developer's talents to manage the process start-to-finish (as it is
>> non-trivial to hard-fork successfully, others have rehashed this in other
>> threads)...
>>
>> That being said I think it appropriate if Adam's questions were responded
>> in-line when Mike is feeling up to it. I think that the answers are
>> important for the community to hear when such a drastic change is being
>> espoused.
>>
>> Faiz
>>
>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>>> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
>>>> error of their ways. Anyone can write blogs.
>>>>
>>>
>>> I worry that if this is the level of care you take with reading and
>>> (mis)interpreting Adam's messages, that you might not be taking extreme
>>> care with evaluating consensus changes, even while tired or sleeping. I
>>> encourage you to evaluate both messages and source code more carefully,
>>> especially in the world of bitcoin. However, this goes for everyone and not
>>> just you. Specifically, when Adam mentioned your conversations with
>>> non-technical people, he did not mean "Mike has talked with people who have
>>> possibly not made pull requests to Bitcoin Core, so therefore Mike is a
>>> non-programmer". Communication is difficult and I can understand that, but
>>> we really have to be more careful when evaluating each other's messages;
>>> technical miscommunication can be catastrophic in this context. On the
>>> topic of whether you are a programmer, I suspect that ever since you built
>>> CIA.vc we have all known you're a programmer, Mike.
>>>
>>> - Bryan
>>> http://heybryan.org/
>>> 1 512 203 0507
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>> --
>>>
>>> My regards,
>>>
>>> Faiz Khan
>>>
>>> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.JPG
Type: image/jpeg
Size: 22107 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/66911ee3/attachment.jpe>

2023-06-07 17:33:10 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: "everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo"
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it. The biggest risk here isn't that 20MB blocks will
be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
isn't nearly universally agreed upon, we will be damaging that belief. If
I strongly believed some hard fork would be better for Bitcoin, say
permanent inflation of 1% a year to fund mining, and I managed to convince
80% of users, miners, businesses and developers to go along with me, I
would still vote against doing it. Because that's not nearly universal
agreement, and it changes what people chose to believe in without their
consent. Forks should be hard, very hard. And both sides should recognize
that belief in the value of Bitcoin might be a fragile thing. I'd argue
that if we didn't force through a 20MB fork now, and we ran into major
network difficulties a year from now and had no other technical solutions,
that maybe we would get nearly universal agreement, and the businesses and
users that were driven away by the unusable system would be a short term
loss in value considerably smaller than the impairment we risk by forcing a
change.
On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email me objections I might have missed. I would
> still appreciate it if people do that; it is impossible to keep up with
> this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
> also have time to respond thoughtfully to the objections raised.
>
> I would very much like to find some concrete course of action that we can
> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> how much transaction volume the main Bitcoin blockchain will be able to
> support over the next eleven years."
>
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
>
> There ARE tradeoffs here, and the hard question is what process do we use
> to decide those tradeoffs? How do we come to consensus? Is it worth my
> time to spend hours responding thoughtfully to every new objection raised
> here, or will the same thing happen that happened last year and the year
> before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
> fast Internet connection, and assume Nelson's law to increase over time),
> and then encouraging merchants and exchanges and web wallets and
> individuals who think it strikes a reasonable balance to run it.
>
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger blocks
> and eventually trigger the hard fork.
>
> Because ultimately consensus comes down to what software people choose to
> run.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/30afcdf6/attachment.html>

2023-06-07 17:15:28 CEST

- reply

📅 Original date posted:2014-03-14
📝 Original message:I think Mark makes some good arguments.
I realize this would only add to the confusion, but...
What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
whatever else), with a proper 3 letter code, and then from a user
standpoint, where people are using mBTC, they could switch to using Kbits
(ok thats obviously bad, but you get the idea) at the same nominal price.
But accounting backends and so forth would operate in the "bit" base unit
with 2 decimals of precision.
On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark at monetize.io> wrote:
> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
> numbers in both Chinas, Thailand, and other economically important East
> Asian countries. Expect to pay hundreds of rupees in India, or thousands
> of rupees in Indonesia.
>
> This concept that money should have low, single digits for everyday
> prices is not just Western-centric, it's English-centric. An expresso in
> Rome would have cost you a few (tens of?) thousand lira in recent
> memory. It was pegging of the Euro to the U.S. dollar that brought
> European states in line with the English-speaking world (who themselves
> trace lineage to the pound sterling).
>
> No, there is no culturally-neutral common standards for currency and
> pricing. But there are ill-advised, ill-informed "standards" in
> accounting software that we nevertheless must live with. These software
> packages do not handle more than two decimal places gracefully. That
> gives technical justifications for moving to either uBTC or accounting
> in Satoshis directly. An argument for uBTC is that it retains alignment
> with the existing kBTC/BTC/mBTC/uBTC conventions.
>
> However another limitation of these accounting software practices is
> that they do not always handle SI notation very well, particularly
> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
> compliant with any software accounting package out there.
>
> We are still very, very early in the adoption period. These are changes
> that could be made now simply by a few big players and/or the bitcoin
> foundation changing their practice and their users following suit.
>
> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> > How much do you pay for an Espresso in your local currency?
> >
> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> > people would expect. Certainly more familiar than µBTC 3558 or BTC
> > 0.003578.
> >
> > Anyway, I was just sharing real-world experience: nobody is confused.
> >
> >
> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >> You give them a hard to interpret thing like mBTC and then wonder
> >> why they rather look at local currency. Because the choices you
> >> gave them are bad.
> >>
> >> I think Bitcoin would have a better chance to be percieved as a
> >> currency of its own if it had prices and fractions like currencies
> >> do.
> >>
> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >> would be.
> >>
> >>
> >> Tamas Blummer Bits of Proof
> >>
> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de>
> >> wrote:
> >>
> >>> btw. None of Bitcoin Wallet's users complained about confusion
> >>> because of the mBTC switch. In contrast, I get many mails and
> >>> questions if exchange rates happen to differ by >10%.
> >>>
> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >>> local currency that matters to the users.
> >>>
> >>>
> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >>>> µBTC.
> >>>>
> >>>> I must admit I was not aware if this thread. I just watched
> >>>> other wallets and at some point decided its time to switch to
> >>>> mBTC.
> >>>>
> >>>>
> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>>>> The standard has become mBTC and that's what was adopted.
> >>>>> It's too late to try and sway this on a mailing list thread
> >>>>> now.
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
> >>>>>
> >>>>> The MultiBit HD view is that this is a locale-sensitive
> >>>>> presentation issue. As a result we offer a simple
> >>>>> configuration panel giving pretty much every possible
> >>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
> >>>>> mXBT, μXBT, sat along with settings for leading/trailing
> >>>>> symbol, commas, spaces and points. This allows anyone to
> >>>>> customise to meet their own needs beyond the offered default.
> >>>>>
> >>>>>
> >>>>> We apply the NIST guidelines for representation of SI unit
> >>>>> symbols (i.e no conversion to native language, no RTL giving
> >>>>> icon+m etc).
> >>>>>
> >>>>> Right now MultiBit HD is configured to use m+icon taken from
> >>>>> the Font Awesome icon set. However reading earlier posts it
> >>>>> seems that μ+icon is more sensible.
> >>>>>
> >>>>> Let us know what you'd like.
> >>>>>
> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >>>>> Awesome icon:
> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>>>
> >>>>>
> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
> >>>>> <mailto:jgarzik at bitpay.com>> wrote:
> >>>>>
> >>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
> >>>>> several weeks ago, which was disappointing -- it sounded like
> >>>>> the consensus was uBTC, and moving to uBTC later --which will
> >>>>> happen-- may result in additional user confusion, thanks to
> >>>>> yet another decimal place transition.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
> >>>>> <mailto:w at grabhive.com>> wrote:
> >>>>>> We're with uBTC too. Been waiting for the signal to do
> >>>>>> this,
> >>>>> let's do it right after the fee system is improved.
> >>>>>>
> >>>>>> -wendell
> >>>>>>
> >>>>>> grabhive.com <http://grabhive.com> |
> >>>>>> twitter.com/hivewallet
> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >>>>>>
> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >>>>>>
> >>>>>>> Go straight to uBTC. Humans and existing computer
> >>>>>>> systems
> >>>>> handle numbers to
> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
> >>>>>>> The
> >>>>> opposite is
> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
> >>>>>>> places).
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Jeff Garzik Bitcoin core developer and open source
> >>>>> evangelist BitPay, Inc. https://bitpay.com/
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>>
> >>>>>
> > Learn Graph Databases - Download FREE O'Reilly Book
> >>>>> "Graph Databases" is the definitive new guide to graph
> >>>>> databases and their applications. Written by three acclaimed
> >>>>> leaders in the field, this first edition is now available.
> >>>>> Download your free book today!
> >>>>> http://p.sf.net/sfu/13534_NeoTech
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>>> Databases" is the definitive new guide to graph databases
> >>>>> and their applications. Written by three acclaimed leaders in
> >>>>> the field, this first edition is now available. Download your
> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>>> Databases" is the definitive new guide to graph databases and
> >>>>> their applications. Written by three acclaimed leaders in the
> >>>>> field, this first edition is now available. Download your
> >>>>> free book today! http://p.sf.net/sfu/13534_NeoTech
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Bitcoin-development mailing list
> >>>>> Bitcoin-development at lists.sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>>> Databases" is the definitive new guide to graph databases and
> >>>> their applications. Written by three acclaimed leaders in the
> >>>> field, this first edition is now available. Download your free
> >>>> book today! http://p.sf.net/sfu/13534_NeoTech
> >>>> _______________________________________________
> >>>> Bitcoin-development mailing list
> >>>> Bitcoin-development at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >
> ------------------------------------------------------------------------------
> >>> Learn Graph Databases - Download FREE O'Reilly Book "Graph
> >>> Databases" is the definitive new guide to graph databases and
> >>> their applications. Written by three acclaimed leaders in the
> >>> field, this first edition is now available. Download your free
> >>> book today! http://p.sf.net/sfu/13534_NeoTech
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases
> >> and their applications. Written by three acclaimed leaders in the
> >> field, this first edition is now available. Download your free book
> >> today! http://p.sf.net/sfu/13534_NeoTech
> >>
> >>
> >>
> >> _______________________________________________ Bitcoin-development
> >> mailing list Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140314/b6d600bc/attachment.html>

2023-06-07 17:13:23 CEST

- reply

📅 Original date posted:2014-02-12
📝 Original message:I apologize if this has been discussed many times before.
As a long term solution to malleable transactions, wouldn't it be possible
to modify the signatures to be of the entire transaction. Why do you have
to zero out the inputs? I can see that this would be a hard fork, and
maybe it would be somewhat tricky to extract signatures first (since you
can sign everything except the signatures), but it would seem to me that
this is an important enough change to consider making.
On Wed, Feb 12, 2014 at 5:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
> > On 02/12/2014 08:44 AM, Alan Reiner wrote:
> > > Changing the protocol to use these static IDs is a pretty fundamental
> > > change that would never happen in Bitcoin. But they can still be
> > > useful at the application level to mitigate these issues.
> >
> > Not to mention that it would be potentially very insecure to have
> > consensus depend on data (scriptSigs) which are not hashed in the Merkle
> > structure of a block.
> >
> > Not that anyone on this list has suggested such a change, but I've seen
> > it raised multiple times on the forum....
>
> This would be a problem if it was used in the merkle tree, but I'm pretty
> sure
> using it for input selection would be pretty safe. One could even avoid the
> index by simply using the hashScript as the sole input value; then even
> CoinJoins would be safe without breaking chains of transactions (although
> this
> would break address reuse entirely - but I don't see that as a problem in a
> theoretical world). One of those things that an altcoin could improve upon
> Bitcoin with... ;)
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/1bd41008/attachment.html>