<unnamed>

Public Key

npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tq

Profile Code

nprofile1qqs0tp22qlzgp254kq9rzp4pwau00dvzy8vd6yk3rekeged6wdaa2rqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qn86tf8

Publishing to

relay.nostr.net

Last Notes

2023-06-09 14:43:27 CEST

- reply

📅 Original date posted:2015-06-23
📝 Original message:
Hello,
I find the paper very interesting. There is quite a few things I don't
understand. In the the paper there are the terms "channel
counterparty" and "clearinghouse". What is exactly the risk to this
counterparty and why would it be trustless to route through that
party? How would users of the network find and select those
intermediaries? I think in general building trust-based level 2
protocols is a good idea - it's not clear to me how it would work
without explicit trust. Opening a channel is similar to declaring - I
trust this counterparty X up to amount Y. If X disappears then the
risk is capped at Y.
In the existing banking and monetary system counterparty risk can be
minimized by shifting unwanted exposures. The problems are often more
in the systematic risk, such as a failure of a banking system as a
whole. If counterparties are interconnected, failures can propagate in
unexpected ways. For example A might trust B to route or clear and not
trust C. But B might have exposure to C, so that A's exposure can't be
diversified.
Regards,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150623/517af0bb/attachment.html>

2023-06-07 17:46:20 CEST

- reply

📅 Original date posted:2015-08-08
📝 Original message:>> The point was NOT to trust no-one, the point was to trust everyone, but
keep everyone honest by keeping the ledger open and publicly available.
Trust takes many different forms and is not a binary function. You trust a
surgeon to do an operation and a pilot to fly a jet, but not vice versa. To
trust someone explicitly, you need to know who they are. Most social
structures work without explicit identity and they still function quite
well. For example companies are mostly anonymous to the consumer - if you
buy something in a shop you trust a chain of people producing that good. A
priori there is little reason to trust others, but rather that trust is
already developed through social institutions. Money is one such
institution with specific trust problems, and the history of money is
indeed a very good way to study these problems. Unfortunately in Bitcoin
development such insights are rare to find.
Lightning assumes explicit trust and ID - much like Ripple. That's not
going to work, and I'm surprised that someone with basic knowledge of
crypto doesn't see this problem. Having explicit counter-parties is
something very different from Bitcoin where the entity doing transactions
verification is unknowable and changes all the time. Users of Bitcoin trust
nodes doing the verification because they know it is in their best interest
to be honest. Neither Sidechains nor LT have preserve that important
property, and so IMO there are no good proposals to make Bitcoin scale (if
that is possible at all).
On Sat, Aug 8, 2015 at 10:54 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I didn't say off-chain, and gave an example of on-chain usecase with
> trusted middleman.
>
> So, no, that's not what I meant.
>
> Sent on the go, excuse the brevity.
> Original Message
> From: Adam Back
> Sent: Saturday, 8 August 2015 09:50
> To: Thomas Zander
> Cc: Bitcoin Dev
> Subject: Re: [bitcoin-dev] trust
>
> If you are saying that some people are happy trusting other people,
> and so would be perfectly fine with off-chain use of Bitcoin, then we
> agree and I already said that off-chain use case would be a
> constructive thing for someone to improve scale and interoperability
> of in the post you are replying to. However that use case is not a
> strong argument for weakening Bitcoin's security to get to more scale
> for that use case.
>
> In a world where we could have scale and decentralisation, then of
> course it would be nice to provide people with that outlook more
> security than they seem to want. And sometimes people dont understand
> why security is useful until it goes wrong, so it would be a useful
> thing to do. (Like insurance, your money being seized by paypal out
> of the blue etc). And indeed providing security at scale maybe
> possible with lightning like protocols that people are working on.
>
> Adam
> _______________________________________________
> 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/0acd24af/attachment-0001.html>

2023-06-07 17:41:01 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:"On the Lightning network, a large hub can't steal my money." Malicious
hubs could flood the network. The way it is discussed now it's not
resistant to Sybil attack either. It's an interesting idea in a very early
stage. Not at all a drop-in replacement for Bitcoin anytime soon, as some
imply. Blockstream shouldn't make these issues into pitches of their own
tech of their for-profit enterprise.
On Sun, Jun 28, 2015 at 9:22 PM, Andrew Lapp <lapp0 at purdue.edu> wrote:
> I don't mind a set of central authorities being part of an option IF the
> central authority doesn't need to be trusted. On the blockchain, the larger
> miner is, the more you have to trust them to not collude with anyone to
> reverse your payments or destroy the trust in the system in some attack. On
> the Lightning network, a large hub can't steal my money.
>
> I think most people share the sentiment that trustlessness is what matters
> and decentralization is just a synonym for trustlessness when talking about
> the blockchain and mining, however decentralization isn't necessarily
> synonymous with trustlessness nor is centralization synonymous with
> trust-requiring when you're talking about something else.
>
> -Andrew Lapp
>
> On 06/28/2015 01:29 PM, Gavin Andresen wrote:
>
>> I can see how payment channels would work between big financial
>> institutions as a settlement layer, but isn't that exactly the
>> centralization concern that is making a lot of people worried about
>> increasing the max block size?
>>
>
> _______________________________________________
> 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/20150628/6ca0b59b/attachment.html>

2023-06-07 17:40:55 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:"You open a channel with a hub and through that channel send coins to
anyone accessible to the network."
Define hub *precisely* and you will find there are
some significant problems here.
a) does everyone know each other in the network? In Bitcoin transacting
parties exchange keys out of band. How do I know that Alice is owner of a
pubkey? I don't, and if don't know Alice I'm out of luck and can't transact
with here (or trust another PKI).
b) hubs need incentives. There are not going to put up collateral just for
nothing.
c) how is complexity reduced? I would speculate that most transactions are
one-time transactions in the time frame of days.
LT is a very interesting idea, but far from actual implementation.
On Sun, Jun 28, 2015 at 7:12 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Think in terms of participants, not addresses. A participant in the
> lightning network has a couple of connections to various hubs, from which
> the participant is able to send or receive coin. The user is able to send
> coins to anyone connected to the lightning network by means of an atomic
> transaction through any path of the network. But the only payment from them
> that ever hits the chain is their settlement with the hub.
>
> Imagine there was a TCP/IP data chain and corresponding lightning network.
> Everyone connected to the network has an "IP" channel with their ISP.
> Through this channel they can send data to anywhere on the network, and a
> traceroute shows what hops the data would take. But when settlement
> actually occurs all the network sees is the net amount of data that has
> gone through each segment -- without any context. There's no record
> preserved on-chain of who sent data to whom, just that X bytes went through
> the pipe on the way to somewhere unspecified.
>
> So it is with lightning payment networks. You open a channel with a hub
> and through that channel send coins to anyone accessible to the network.
> Channels only close when a participant needs the funds for non-lightning
> reasons, or when hubs need to rebalance. And when they do, observers on the
> chain learn nothing more than how much net coin moved across that single
> link. They learn nothing about where that coin eventually ended up.
>
> So back to your original question, each channel can be considered to have
> a pseudonymous identity, and each new channel given a new identity. Channel
> closures can even be coinjoin'd when the other party is cooperating. But
> ultimately, lightning usefully solves a problem where participants have
> semi-long lived payment endpoints.
>
> On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <raystonn at hotmail.com> wrote:
>
>> Write coalescing works fine when you have multiple writes headed to the
>> same (contiguous) location. Will lightning be useful when we have more
>> unique transactions being sent to different addresses, and not just
>> multiple transactions between the same sender and address? I have doubts.
>>
>>
>> -----Original Message----- From: Adam Back
>> Sent: Sunday, June 28, 2015 5:37 AM
>> To: Benjamin
>> Cc: bitcoin-dev at lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
>>
>>
>> On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes at gmail.com> wrote:
>>
>>> I agree that naive scaling will likely lead to bad outcomes. They might
>>> have
>>> the advantage though, as this would mean not changing Bitcoin.
>>>
>>
>> Sure we can work incrementally and carefully, and this is exactly what
>> Bitcoin has been doing, and *must* do for safety and security for the
>> last 5 years!
>> That doesnt mean that useful serious improvements have not been made.
>>
>> Level2 and Lightning is not well defined. If you move money to a third
>>> party, even if it is within the constrained of a locked contract, then I
>>> don't think that will solve the issues.
>>>
>>
>> I think you misunderstand how lightning works. Every lightning
>> transaction *is* a valid bitcoin transaction that could be posted to
>> the Bitcoin network to reclaim funds if a hub went permanently
>> offline. It is just that while the hubs involved remain in service,
>> there is no need to do so. This is why it has been described as a
>> (write coalescing) write cache layer for Bitcoin.>
>>
>> I believe people expect lightning to be peer 2 peer like bitcoin.
>>
>> Adam
>> _______________________________________________
>> 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/20150628/9b9af297/attachment.html>

2023-06-07 17:40:54 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:I agree that naive scaling will likely lead to bad outcomes. They might
have the advantage though, as this would mean not changing Bitcoin.
Level2 and Lightning is not well defined. If you move money to a third
party, even if it is within the constrained of a locked contract, then I
don't think that will solve the issues. Blockchain does not know about
offchain and moving between offchain and onchain requires liquidity and a
pricing mechanism. That is exactly the problem with side-chains. If you
have off-chain transactions on an exchange, they are ID'ed in their system,
subject to KYC/AML.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/489ec17d/attachment.html>

2023-06-07 17:40:50 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 07:46:55PM +0200, Benjamin wrote:
> > There is no ensured Quality of service, is there? If you "bid" higher,
> then
> > you don't know what you are going to get. Also because you have no way of
> > knowing what *others* are bidding. Only if you have auctions (increasing
> > increments) you can establish a feedback loop to settle demand and
> supply.
> > And the supply side doesn't adapt. Adapting supply would help resolve
> parts
> > of the capacity problem.
>
> There's lots of markets where there is no assured quality of service,
> and where the bids others are making aren't known. Most financial
> markets work that way - there's only ever probabalistic guarantees that
> for a given amount of money you'll be able to buy a certain amount of
> gold at any given time for instance. Similarly for nearly all
> commodities the infrastructure required to mine those commodities has
> very little room for short, medium, or even long-term production
> increases, so whatever the production supply is at a given time is
> pretty much fixed.
>
hmm? if the current ask for 1 ounce of gold is 100$, then you need to bid
100$ to get 1 ounce of gold. If tomorrow everyone agree 1ounce of gold
should be worth 200$, then the bid moves accordingly. of course production
changes based on prices. otherwise the economy would not function. if price
of some stuff goes up, more people produce that stuff. in terms of a price
for a transaction and the use of a blockchain, unfortunately there is not a
way to just add computational supply. that's an inherent weakness of how
blockchains are structured. ideally it would be as simple as demanding more
resources as in scaling a webservices with AWS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/ef46ab91/attachment.html>

2023-06-07 17:40:49 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:There is no ensured Quality of service, is there? If you "bid" higher, then
you don't know what you are going to get. Also because you have no way of
knowing what *others* are bidding. Only if you have auctions (increasing
increments) you can establish a feedback loop to settle demand and supply.
And the supply side doesn't adapt. Adapting supply would help resolve parts
of the capacity problem.
On Sat, Jun 27, 2015 at 7:37 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 07:26:00PM +0200, Benjamin wrote:
> > "Thus we have a fixed capacity system where access is mediated by supply
> > and demand transaction fees."
> >
> > There is no supply and demand. That would mean users would be able to
> adapt
> > fees and get different quality of service depending on current capacity.
> > For example if peak load is 10x average load, then at those times fees
> > would be higher and users would delay transactions to smooth out demand.
>
> That's exactly how Bitcoin works already. See my article on how
> transaction fees work for more details:
>
> https://gist.github.com/petertodd/8e87c782bdf342ef18fb
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/4f0abdd8/attachment.html>

2023-06-07 17:40:48 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:"Thus we have a fixed capacity system where access is mediated by supply
and demand transaction fees."
There is no supply and demand. That would mean users would be able to adapt
fees and get different quality of service depending on current capacity.
For example if peak load is 10x average load, then at those times fees
would be higher and users would delay transactions to smooth out demand.
On Sat, Jun 27, 2015 at 7:20 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:
> > That test seems like a reasonable suggestion; 840GB is not prohibitive
> > given today's computing costs. What other than the successful result of
> > that test would you want to see before agreeing to increase the block
> size
> > to 8MB?
>
> The two main things you need to show is:
>
> 1) Small, anonymous, miners remain approximately as profitable as large
> miners, regardless of whether they are in the world, and even when
> miners are under attack. Remember I'm talking about mining here, not
> just hashing - the process of selling your hashpower to someone else who
> is actually doing the mining.
>
> As for "approximately as profitable", based on a 10% profit margin, a 5%
> profitability difference between a negligable ~0% hashing power miner
> and a 50% hashing power miner is a good standard here.
>
> The hard part here is basically keeping orphan rates low, as the %5
> profitability different on %10 profit margin implies an orphan rate of
> about 0.5% - roughly what we have right now if not actually a bit lower.
> That also implies blocks propagate across the network in just a few
> seconds in the worst case, where blocks are being generated with
> transactions in them that are not already in mempools - circumventing
> propagation optimization techniques. As we're talking about small
> miners, we can't assume the miners are directly conneted to each other.
> (which itself is dangerous from an attack point of view - if they're
> directly connected they can be DoS attacked)
>
> 2) Medium to long term plan to pay for hashing power. Without scarcity
> of blockchain space there is no reason to think that transaction fees
> won't fall to the marginal cost of including a transaction, which
> doesn't leave anything to pay for proof-of-work security. A proposal
> meeting this criteria will have to be clever if you don't keep the
> blocksize sufficiently limited that transaction fees are non-negligable.
> One possible approach - if probably politically non-viable - would be to
> change the inflation schedule so that the currency is inflated
> indefinitely.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> 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/20150627/df971066/attachment.html>

2023-06-07 17:38:37 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:Yeah, but increasing block-size is not a longterm solution. Necessary
higher fees are a logical consequence of lower subsidies. Bitcoin was
basically free to use at the beginning because miners got paid with
new coins at the expense of those who already hold coins. Eventually
there needs to be a mechanism which matches supply and demand.
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn <mike at plan99.net> wrote:
>> Or alternatively, fix the reasons why users would have negative
>> experiences with full blocks
>
>
> It's impossible, Mark. By definition if Bitcoin does not have sufficient
> capacity for everyone's transactions, some users who were using it will be
> kicked out to make way for the others. Whether that happens in some kind of
> stable organised way or (as with the current code) a fairly chaotic way
> doesn't change the fundamental truth: some users will find their bitcoin
> savings have become uneconomic to spend.
>
> Here's a recent user complaint that provides a preview of coming
> attractions:
>
> https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
>
>> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
>> onto a paper wallet. When I try to send it, a window pops up stating
>> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
>
>
> These sorts of complaints will get more frequent and more extreme in the
> coming months. I realise that nobody at Blockstream is in the position of
> running an end user facing service, but many of us are .... and we will be
> the ones that face the full anger of ordinary users as Bitcoin hits the
> wall.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:38:28 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:"And I never had a problem with Bitcoin-XT while it was just a
patch-set with no consensus changes. But a controversial hard fork of
the chain is something else completely."
How is that different? The only difference is in who makes the fork
and if that group has a chance of actually splitting/overriding the
network. So Mike and Gavin are using the trust and relationship they
have garnered through Bitcoin for their purposes (malicious or not).
There are only 20-30 people with the same kind of recognition who
would be able to do that. M&G already wanted to make a fork in 2014
for entirely different reasons (http://pastebin.com/3kt5Reeh).
On Thu, Jun 18, 2015 at 2:50 PM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thu, Jun 18, 2015 at 02:29:42PM +0200, Pieter Wuille wrote:
>> On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan <laanwj at gmail.com>
>> wrote:
>>
>> > Like in any open source project there is lots of decision making ability
>> > for code changes. I'd say look at the changelog for e.g. 0.11
>> > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
>> > or follow pull requests for a while, to see how many decisions about
>> > changes are made from day to day. No, I'm not sitting on my hands, and so
>> > is none of the other contributors that you'd like to get rid of.
>> >
>>
>> The analogy goes further even. Even though I disagree with some of the
>> changes you're making, I respect Mike's (and anyone's) right to make a fork
>> of Bitcoin Core. That's how open source works: if people disagree with
>> changes made or not made, they can maintain their own version. However:
>
> Sure. According to github, there exist 4890 forks of the bitcoin/bitcoin repository.
>
> Forking the code is perfectly fine in itself, that doesn't even need to be said, it's how open source works. Make your changes, run your own version, contribute back the changes (or not).
>
> And I never had a problem with Bitcoin-XT while it was just a patch-set with no consensus changes. But a controversial hard fork of the chain is something else completely.
>
> Wladimir
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJVgr5LAAoJEHSBCwEjRsmm5mMH/0yLGGQQefRVdmM/nJZ60b/z
> iTCUUzY4eLL67FRC6pqGA18RdUt4Etl4wEqvgXH/B9mWIAM2yQD/jnxutYrEIoBT
> 8Jyd1OhmmKF8MN5/uE7JNPivIuHs0ioF+qTxlbdElpVZ2NodVotznbTvuqJgXUFb
> c9Et5L5n7g55uPzDt+MSV5iBDJaMiBAnZA00aTLGmYmNXxcy7xBwCFX3dDij8krv
> 0+zdpNNAKm85k1rG2jHCM+0onu+TOIur03pPd5OZktgr18P6UvAQ6A59yAkGgFai
> 4l6VVNJ40g3PzItGQ7wsKZ8s/qG5LlcEppxMlG6CX1dIDpxbrwx2aJmeNjwSLKQ=
> =LbA3
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:38:20 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:"And it allows the minority to hold the majority hostage"
The Bitcoin protocol has no definitions about developer consensus .
The reference to FOSS is quite arbitrary. The alternative of lobbying
companies is equally indeterminate and arbitrary. One of the core
problem is that you can't poll users about features, and even if one
could users are unlikely to be able to make design decisions about the
system. Voting is a quite imperfect mechanism. IF there would be a
hardfork vote of this kind, at least each party should lay out a
longterm plan and proposal. Mike and Gavin don't have any plans to
implement new scaling facilities and Lightening is not a coherent
proposal. In effect this fork battle would not be part of a BIP
process, but a vote on a longterm plan/architecture.
On Tue, Jun 16, 2015 at 8:09 AM, Marcel Jamin <marcel at jamin.net> wrote:
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.
>
> Neither do you or anyone else.
>
>> There is protocol for how change is effected in a FOSS project.
>
> And it allows the minority to hold the majority hostage.
>
>> If you take the risks with Mike&GavCoin, that would be fine, but you are
>> about to take them with community-owned Bitcoin and Other People's Money!
>
> The same can be said about the other camp.
>
> BitcoinXT is not going to fork the chain on a specific date no matter what.
> People will be able to vote via block versions and once a sufficient
> majority supports the extensions, everyone else will have a grace period to
> upgrade. Only after that is a very small minority at risk of losing money.
>
> That being said, I'd rather see a solution that everyone agrees on. My
> personal opinion/hope is that Mike and Gavin are just applying pressure
> where it's needed. But in the end, they can do whatever they want if they
> have the necessary support. Permissionless innovation is one of bitcoins
> virtues. In the end, only adoption will decide what bitcoin is and isn't.
>
> 2015-06-16 7:18 GMT+02:00 Venzen <venzen at mail.bihthai.net>:
>>
>> Mike Hearn,
>>
>> In the light of your responses to Adam Back's questions, below, I feel
>> it is time to speak up because what I now understand, and is implied,
>> is that Mike Hearn and Gavin Andresen have planned and deployed the
>> infrastructure for a Bitcoin hard-fork and intend to action it despite
>> majority opposition. http://xtnodes.com/
>>
>> I'll try to keep it brief:
>>
>> Mike Hearn, you should cease your activity of a unilateral hard-fork
>> immediately. You are doing untold damage by breaking FOSS governance
>> protocol requiring methodical collaborative work and due process of
>> change implementation by consensus. Your actions are bad for the
>> Bitcoin project and its ideals, disrespectful of your peers and years
>> of their passionate hard work, and dangerous for Bitcoin in the
>> marketplace and bitcoin in peoples' wallets.
>>
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
>> you cannot have it. Your hard-fork is tantamount to theft and you and
>> your collaborators will effectively ex-communicate yourselves from
>> this project and community. It appears that you are consciously trying
>> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
>> You clearly do not comprehend the array of risks - especially the
>> unanticipated ones. As the market saying goes: "If you think
>> speculation is easy, it is because you are ignorant about the risks".
>> If you take the risks with Mike&GavCoin, that would be fine, but you
>> are about to take them with community-owned Bitcoin and Other People's
>> Money!
>>
>> You are causing a lot of stress, unnecessarily, and grave concern
>> surrounds your proposed renegade action. You can dissolve the threat:
>> those players to whom you have made promises can be appeased and
>> eventually get most of what they need from this FOSS project. The
>> developers whom you are railroading to get your way, and the way in
>> which you are doing it, is about to cause a schism that will expand
>> outward from this community.
>>
>> You may accuse the community for being antagonistic to you, and
>> therefore uncooperative, but it is plain to see that your bullheaded
>> manner eventually generates antagonism wherever you go. Taking Bitcoin
>> away from this community, in anger, won't solve the problem and will
>> be like killing the goose that lays the golden eggs.
>>
>> If an individual in an objectively agreed-to FOSS-modelled
>> collaborative project has the audacity to threaten his peers and the
>> world with a unilateral hard-fork despite majority objection and a
>> probability distribution that includes terminal risks and unintended
>> consequences, then what would an impartial outsider think? Some of
>> their thoughts would include that the antagonist could be acting in
>> self-interest, or may be a paid actor, or worse, a saboteur. What
>> would they advise? Stop that individual, at once!
>>
>> Bitcoin is a Free and Open Source Software project that serves as
>> flagship for the blockchain. It has a payment network but the key
>> benefits are censorship resistance and trustless decentralization.
>> There is protocol for how change is effected in a FOSS project. For
>> the sake of everything that is good and useful in Bitcoin, reconsider
>> your dangerous plan and its intended and unintended consequences. Put
>> your feet back on the ground, return to the fold and let the
>> collaborative FOSS model, and the skills available here, gradually
>> scale Bitcoin to your (and all our) grand vision.
>>
>> Venzen Khaosan
>>
>>
>> On 06/15/2015 04:56 PM, Mike Hearn wrote:
>> > Hi Adam,
>> >
>> > Provisional answers below!
>> >
>> > - Are you releasing a BIP for that proposal for review?
>> >
>> >
>> > The work splits like this:
>> >
>> > * Gavin is writing the code and I think a BIP as well
>> >
>> > * I will review both and mostly delegate to Gavin's good taste
>> > around the details, unless there is some very strong disagreement.
>> > But that seems unlikely.
>> >
>> > * I have been handling gitian and the patch rebases, the code
>> > signing and so on, so far. I've also been doing some work to setup
>> > the basic infrastructure of the project (website etc).
>> >
>> >
>> > - If the reviewers all say NACK will you take on board their
>> > suggestions?
>> >
>> >
>> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
>> > requests aren't scored in any way. The final decision rests with
>> > the maintainer as in ~all open source projects.
>> >
>> >
>> >
>> > - On the idea of a non-consensus hard-fork at all, I think we can
>> > assume you will get a row of NACKs. Can you explain your
>> > rationale for going ahead anyway? The risks are well understood
>> > and enormous.
>> >
>> >
>> > Yes, I have been working on an article that explains how we got to
>> > this point from my perspective. It is quite long, but only because
>> > I want it to be readable for people who weren't following the
>> > debate.
>> >
>> > Anyway, I think I've laid out the gist of it over and over again,
>> > but to summarise:
>> >
>> > If Bitcoin runs out of capacity *it will break and many of our
>> > users will leave*. That is not an acceptable outcome for myself or
>> > the many other wallet, service and merchant developers who have
>> > worked for years to build an ecosystem around this protocol.
>> >
>> >
>> >
>> > - How do you propose to deal with the extra risks that come from
>> > non-consensus hard-forks? Hard-forks themselves are quite risky,
>> > but non-consensus ones are extremely dangerous for consensus.
>> >
>> >
>> > The approach is the same for other forks. Voting via block versions
>> > and then when there's been >X% for Y time units the 1mb limit is
>> > lifted/replaced.
>> >
>> >
>> >
>> >
>> > - If you're going it alone as it were, are you proposing that you
>> > will personally maintain bitcoin-XT? Or do you have a plan to
>> > later hand over maintenance to the bitcoin developers?
>> >
>> >
>> > Good question! I have various thoughts on this, but let's wait and
>> > see what happens first. Perhaps the new chain won't get the
>> > majority on it.
>> >
>> > In the event that the >1mb chain does eventually win, I would
>> > expect Core to apply the patch and rejoin the consensus rather than
>> > lose all its users. That would take XT back to being a fairly small
>> > patchset to improve the network protocol.
>> >
>> >
>> >
>> > - Do you have contingency plans for what to do if the
>> > non-consensus hard-fork goes wrong and $3B is lost as a result?
>> >
>> >
>> > Where did you get the $3B figure from? The fork either doesn't
>> > happen, or it happens after quite a long period of people knowing
>> > it's going to happen - for example because their full node is
>> > printing "You need to upgrade" messages due to seeing the larger
>> > block version, or because they read the news, or because they heard
>> > about it via some other mechanisms.
>> >
>> > Let me flip the question around. Do you have a contingency plan if
>> > Bitcoin runs out of capacity and significant user disruption occurs
>> > that results in exodus, followed by fall in BTC price? The only one
>> > I've seen is "we can perform an emergency hard fork in a few
>> > weeks"!
>> >
>> >
>> >
>> > As you can probably tell I think a unilateral fork without
>> > wide-scale consensus from the technical and business communities is
>> > a deeply inadvisable.
>> >
>> >
>> > Gavin and I have been polling many key players in the ecosystem.
>> > The consensus you seek does exist. All wallet developers (except
>> > Lawrence), all the major exchanges, all the major payment
>> > processors and many of the major mining pools want to see the limit
>> > lifted (I haven't been talking to pools, Gavin has).
>> >
>> > This notion that the change has no consensus is based on you
>> > polling the people directly around you and people who like to spend
>> > all day on this mailing list. It's not an accurate reflection of
>> > the wider Bitcoin community and that is one of the leading reasons
>> > there is going to be a fork. A small number of people have been
>> > flatly ignoring LOTS of highly technical and passionate developers
>> > who have written vast amounts of code, built up the Bitcoin user
>> > base, designed hardware and software, and yes built companies.
>> >
>> > How do you think that makes Bitcoin Core look to the rest of the
>> > Bitcoin world? How much confidence does that give people?
>> >
>> >
>> >
>> > Of the overall process, I think you can agree we should not be
>> > making technical decisions with this level of complexity and
>> > consensus risk with financial implications of this magnitude under
>> > duress of haste?
>> >
>> >
>> > This debate will never end until a fork makes it irrelevant. There
>> > is no process for ending it, despite me begging Wladimir to make
>> > one.
>> >
>> > And there is no haste. We have been debating the block size limit
>> > for _years_. We have known it must be lifted for _years_. I kicked
>> > off this current round of debates after realising that Wladimir's
>> > release timeline wouldn't allow a block size limit to be released
>> > before the end of the year. The reason we're talking about it now
>> > and not next year is exactly to ensure there is plenty of time.
>> >
>> >
>> >
>> >
>> > I can sincerely assure you everyone does want to scale bitcoin and
>> > shares your long term objective on that
>> >
>> >
>> > I really wish you were right, and I definitely feel you are one of
>> > the more reasonable ones Adam. But the overwhelming impression I
>> > get from a few others here is that no, they don't want to scale
>> > Bitcoin. They already decided it's a technological dead end. They
>> > want to kick end users out in order to "incentivise" (force) the
>> > creation of some other alternative, claiming that it's still
>> > Bitcoin whilst ignoring basic details ... like the fact that no
>> > existing wallets or services would work.
>> >
>> > Scaling Bitcoin can only be achieved by letting it grow, and
>> > letting people tackle each bottleneck as it arises at the right
>> > times. Not by convincing ourselves that success is failure.
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> > _______________________________________________ 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
>

2023-06-07 17:37:33 CEST

- reply

📅 Original date posted:2015-06-14
📝 Original message:"The size limit is an economic policy lever that needs to be
transitioned -away- from software and software developers, to the free
market."
Exactly right. Bitcoin does not have a free market for fee though, and
literally all the discussion so far has neglected some fundamental
aspect of this, as you described. It's not at all a "technical" or
"engineering" decision. It's the question of how to potentially
re-design a fundamental part of Bitcoin, and the proposals so far
don't address this. What is the price of the scarce resource of the
blockchain and the mechanism to decide on price, once the subsidy runs
out?
On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats at henricson.se> wrote:
> Jeff,
>
> with all due respect, but I've seen you saying this a few times
> now, that this decision is oh so difficult and important.
>
> But this is not helpful. We all know that. Even I.
>
> Make a suggestion, or stay out of the debate!
>
> Mats
>
> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
>> The choice is very real and on-point. What should the block size limit
>> be? Why?
>>
>> There is a large consensus that it needs increasing. To what? By what
>> factor?
>>
>> The size limit literally defines the fee market, the whole damn thing. If
>> software high priests choose a size limit of 300k, space is scarce, fees
>> are bid high. If software high priests choose a size limit of 32mb, space
>> is plentiful, fees are near zero. Market actors take their signals
>> accordingly. Some business models boom, some business models fail, as a
>> direct result of changing this unintentionally-added speedbump. Different
>> users value adoption, decentralization etc. differently.
>>
>> The size limit is an economic policy lever that needs to be transitioned
>> -away- from software and software developers, to the free market.
>>
>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
>> problems associated with actors lobbying developers, even if a cloistered
>> and vetted Technical Advisory Board as has been proposed.
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>>> I definitely think we need some voting system for metaconsensus…but if
>>> we’re going to seriously consider this we should look at the problem much
>>> more generally. Using false choices doesn’t really help, though ;)
>>>
>>> - Eric Lombrozo
>>>
>>>
>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>>>
>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
>>> wrote:
>>>
>>>> 2) BIP100 has direct economic consequences…and particularly for miners.
>>>> It lends itself to much greater corruptibility.
>>>>
>>>>
>>> What is the alternative? Have a Chief Scientist or Technical Advisory
>>> Board choose what is a proper fee, what is a proper level of
>>> decentralization, a proper growth factor?
>>>
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> 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

2023-06-07 17:37:28 CEST

- reply

📅 Original date posted:2015-06-12
📝 Original message:This is a misguided idea, to say the least. If such a mechanism of of
user input would be possible, one would use it for transaction
verification in the first place. In proof-of-stake outcomes are
determined by vote by stake (that vote has very different
characteristics than vote by compute power). There is no such thing as
making it possible to determine what "users want". That's what the
proof-of-work mechanism does in the first place, only that it is now
unfortunately skewed/corrupted/(whatever you want to call it). Before
centralization the concept of "miners" didn't exist in Bitcoin and
miners were roughly identical to users. Peer-to-Peer implies only one
class of users.
A big problem with such a vote (in PoW and PoS): miners get paid for
their work and have incentives to raise fees. Those who pay fees would
have no say in whether those fees are fair or not. Transaction
verification has to be roughly profitable, but there is no fixed
formula for determining profitability.
On Fri, Jun 12, 2015 at 8:26 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
>> Peter it's not clear to me that your described protocol is free of miner
>> influence over the vote, by artificially generating transactions which they
>> claim in their own blocks
>
> Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 12, 2015 at 8:34 PM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
>> Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
>>
>> 0 0 = no preference ("wildcard" vote)
>> 0 1 = vote for the limit to remain the same
>> 1 0 = vote for the limit to be halved
>> 1 1 = vote for the limit to be doubled
>>
>> User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
>
> Sounds like a good encoding to me. Taking the median of the three
> options, and throwing away "don't care" votes entirely, makes sense.
>
>> Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
>
> Thanks! I personally expect disaster to ensue with this kind of
> proposal, but I'm less concerned if the disaster is something users
> explicitly allowed to happen in a consensual way.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
On Fri, Jun 12, 2015 at 8:36 PM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
>> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
>> > Peter it's not clear to me that your described protocol is free of miner
>> > influence over the vote, by artificially generating transactions which they
>> > claim in their own blocks
>>
>> Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
>
> Exactly. I very explicitly am proposing that we consider giving users a
> mechanism to pay for votes to give them a way to directly influence the
> outcome.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
On Fri, Jun 12, 2015 at 8:36 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
>> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
>> > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
>> >
>> > 0 0 = no preference ("wildcard" vote)
>> > 0 1 = vote for the limit to remain the same
>> > 1 0 = vote for the limit to be halved
>> > 1 1 = vote for the limit to be doubled
>> >
>> > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
>>
>> Sounds like a good encoding to me. Taking the median of the three
>> options, and throwing away "don't care" votes entirely, makes sense.
>
> I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development