Benjamin [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-08 to 2015-10-27
💬 Posted a total of 24 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tq

Profile Code

nprofile1qqs0tp22qlzgp254kq9rzp4pwau00dvzy8vd6yk3rekeged6wdaa2rqnurrez

Author Public Key

npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tq

Show more details

Last Notes

2023-06-09 12:45:00

- reply

📅 Original date posted:2015-10-27
📝 Original message:
>> But I think it's actually a tractable question, so we can probably actually
work out numbers!
The whole point of a market would be that you get users to work out "the
numbers". If Bitcoin would have a market then capacity would be set by its
use and more demand would trigger supply, and vice versa. Fixing that in
code is inevitably going to lead to bad results. So these discussions about
blocksize and capacity went fundamentally going in the wrong direction.
There is no sensible algorithm to determining prices of anything without
using the input of people in the market. Its not really clear Bitcoin could
build in a mechanism to handle that.
It would be advantageous if fees would be variable by transaction size.
Bitcoin should handle large nominal volumes and low transaction volumes and
a possible second layer handle low nominal values and high transaction
volumes. So it's good to consider BTC amount transferred per bytes. The
higher that number the better for Bitcoin's capacity.
On Tue, Oct 27, 2015 at 10:38 AM, Pierre <pm+lists at acinq.fr> wrote:
> Hello aj,
>
> This is very interesting, thanks!
>
> You seem to be considering that bitcoin tx and lightning tx are completely
> independent, which is not entirely true because of anchor transactions.
> While this is certainly a valid assumption, maybe it would be worth stating
> it explicitely ?
>
> Cheers,
>
> Pierre
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/e19ca702/attachment-0001.html>

2023-06-09 12:45:00

- reply

📅 Original date posted:2015-10-27
📝 Original message:
To make myself more clear. If I assume (roughly based on BCI data):
1000 tx / block
1 BTC volume per tx
300$ BTC/USD
=> 300.000$ of dollar volume moved per block
=> 36B$ dollar volume capacity per year
One of the key aspects of scaling would be to move low value transactions
to a 2nd layer, and leave high value transactions for the most secure
mechanism. Assume for instance that Bitcoin only processes transactions
which have a dollar nominal value of say 100$ and everything else is
handled by 2nd layer. I don't know the statistical distribution, but I
assume this would cut e.g. 95% of transaction volume and brings the average
to 100 BTC. Then the total dollar volume capacity increases by a factor of
100, that is 3600B$ with the same 1 MB blocksize. The key to scaling in my
opinion is to figure out some way to make this split work based on nominal
value of the transaction. That's already how the financial system is
organised. Banks make huge transaction volumes on closed systems. Hubs in
Lightning and banks in the fiat money system would be very similar things.
On Tue, Oct 27, 2015 at 10:46 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> >> But I think it's actually a tractable question, so we can probably actually
> work out numbers!
>
> The whole point of a market would be that you get users to work out "the
> numbers". If Bitcoin would have a market then capacity would be set by its
> use and more demand would trigger supply, and vice versa. Fixing that in
> code is inevitably going to lead to bad results. So these discussions about
> blocksize and capacity went fundamentally going in the wrong direction.
> There is no sensible algorithm to determining prices of anything without
> using the input of people in the market. Its not really clear Bitcoin could
> build in a mechanism to handle that.
>
> It would be advantageous if fees would be variable by transaction size.
> Bitcoin should handle large nominal volumes and low transaction volumes and
> a possible second layer handle low nominal values and high transaction
> volumes. So it's good to consider BTC amount transferred per bytes. The
> higher that number the better for Bitcoin's capacity.
>
> On Tue, Oct 27, 2015 at 10:38 AM, Pierre <pm+lists at acinq.fr> wrote:
>
>> Hello aj,
>>
>> This is very interesting, thanks!
>>
>> You seem to be considering that bitcoin tx and lightning tx are
>> completely independent, which is not entirely true because of anchor
>> transactions. While this is certainly a valid assumption, maybe it would be
>> worth stating it explicitely ?
>>
>> Cheers,
>>
>> Pierre
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/806adb1d/attachment.html>

2023-06-09 12:43:50

- reply

📅 Original date posted:2015-07-30
📝 Original message:
>> Still trying to get the details right of this protocol.
Me too, but I have some more basic problems.
>> Assume a payment route: Alice<>Bob<>Carol
* how does Alice know Bob and Carol? In Bitcoin there needs to be
out-of-band key exchange, but there is no ID attached to the keys. The
concept of a hub seems to imply either use of standard PKI or Web-of-trust.
Both have big problems when it comes to large, frequent financial
transactions.
* why should Bob even participate in this transaction? Currently I don't
see that incentives are described. That is a fundamental part of Bitcoin
and makes network based intermediation possible (Alice <> computer network
with N nodes <> Carol). From the point of view of a node, Bitcoin does not
have a scalability issue. The only concern of the node is to maximize
knowable profit.
On Thu, Jul 30, 2015 at 4:41 AM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Christopher Jamthagen <cjamthagen at gmx.com> writes:
> > Still trying to get the details right of this protocol. Please correct
> > me if I am wrong in any of my assumptions below.
>
> > Assume a payment route: Alice<>Bob<>Carol
>
> > Alice want to pay Carol some amount. Carol gives Alice H(R) and Alice
> > updates her commitment tx with Bob including the HTLC output and Bob
> > does the same with Carol.
>
> OK.
>
> > Carol witholds R, forcing Bob to broadcast the commitment tx between
> > Bob and Carol.
>
> Yep, Carol goes non-responsive. Got it.
>
> > Carol can now spend the HTLC output because she knows R and thus
> > revealing it to the world. Alice now also refuses to update the
> > commitment tx with Bob, forcing Bob to broadcast that commitment tx.
>
> Poor Bob. Yep.
>
> > This commitment tx is putting a delay on
> > Bobs ability to spend the HTLC output (as well as all other outputs to
> > him), but Alice can spend the HTLC output if the CLTV has expired.
>
> Indeed, don't ever offer an HTLC less than your delay!
>
> > In most examples I have seen, the CLTV is 2 days between Alice and Bob
> > and 1 day between Bob and Carol, and all CSV delays are 3 days.
>
> I haven't seen an example which included a CSV delay amount.
>
> As the discussion with Joseph is establishing, the minimum CSV you allow
> controls the worst-case HTLC you can accept. CSV of a few hours should
> be OK if you're online all the time. I think...
>
> Anyone want to do some stats on that? CSV uses the median time of last
> 11 blocks, so to some extent you can tell the worst case...
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150730/4b836826/attachment.html>

2023-06-09 12:43:27

- 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:43:13

- reply

📅 Original date posted:2015-10-13
📝 Original message:p.s. the links
[1] https://blockstream.com/2015/10/12/introducing-liquid/
[2] www.coindesk.com/blockstream-commercial-sidechain-bitcoin-exchanges/
On Tue, Oct 13, 2015 at 4:25 PM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> Hello all,
>
> I was very surprised to learn that Blockstream will implement Sidechains
> for exchanges [1], [2] and has been working on this privately. Can somebody
> explain this “announcement”? Just a few comments on this “proposal”.
>
> “This new construction establishes a security profile inherently superior
> to existing methods of rapid transfer and settlement, and is directly
> applicable to other problems within existing financial institutions.”
>
> First of all, what does Bitcoin have to do with existing financial
> institutions? Secondly, what in do you mean by “rapid transfer” and
> "settlement"? Bitcoin is anonymous, digital cash. There is no such thing as
> settlement, there is only the transfer of digital cash and that's it
> (settlement is a bad word for this kind of transfer of property). If you
> make up new terms define them accurately and don't play the
> crypto-buzzword-bingo game.
>
> “This, in addition to increasing the security of funds normally subject to
> explicit counterparty risk, fosters conditions that increase market
> liquidity and reduce capital requirements for on-blockchain business
> models.”
>
> Again – what does Bitcoin have to do with “market liquidity” and “capital
> requirements”?
>
> “Blockstream's innovative solutions are definitely a game changer for the
> Bitcoin industry.”
>
> Does Blockstream have commercial products now?
>
> "These initial launch partners include Bitfinex, BTCC, Kraken, Unocoin,
> and Xapo, and discussions are underway with another dozen major
> institutional traders and licensed exchanges. "
>
> ??? so many questions and no answers.
>
> Regards,
> Benjamin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/a90a85cc/attachment.html>

2023-06-07 17:43:12

- reply

📅 Original date posted:2015-10-13
📝 Original message:Hello all,
I was very surprised to learn that Blockstream will implement Sidechains
for exchanges [1], [2] and has been working on this privately. Can somebody
explain this “announcement”? Just a few comments on this “proposal”.
“This new construction establishes a security profile inherently superior
to existing methods of rapid transfer and settlement, and is directly
applicable to other problems within existing financial institutions.”
First of all, what does Bitcoin have to do with existing financial
institutions? Secondly, what in do you mean by “rapid transfer” and
"settlement"? Bitcoin is anonymous, digital cash. There is no such thing as
settlement, there is only the transfer of digital cash and that's it
(settlement is a bad word for this kind of transfer of property). If you
make up new terms define them accurately and don't play the
crypto-buzzword-bingo game.
“This, in addition to increasing the security of funds normally subject to
explicit counterparty risk, fosters conditions that increase market
liquidity and reduce capital requirements for on-blockchain business
models.”
Again – what does Bitcoin have to do with “market liquidity” and “capital
requirements”?
“Blockstream's innovative solutions are definitely a game changer for the
Bitcoin industry.”
Does Blockstream have commercial products now?
"These initial launch partners include Bitfinex, BTCC, Kraken, Unocoin, and
Xapo, and discussions are underway with another dozen major institutional
traders and licensed exchanges. "
??? so many questions and no answers.
Regards,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151013/29ae869a/attachment.html>

2023-06-07 17:41:55

- reply

📅 Original date posted:2015-09-30
📝 Original message:Hi Richard,
its great that people with a lot of experience in financial markets take
interest in these topics. I don't think you will receive the best answers
here. The Bitcointalk Altcoin section is currently the best place for such
announcements. I believe there is room for a better board/list for new 2.0
projects. Bitcoin dev is not very welcoming to discussions/debates/projects
which go beyond digital cash systems (assets, markets, etc.), as it is very
focused on the core problems which are under-funded.
Anyone who wants to build a better venue for 2.0 projects feel free to
contact me. This could be a mailing list or an upgraded message board. Most
such boards are project/currency specific, but there is one missing for
announcements.
In terms of markets on top of blockchains, I have sent a private email.
Regards,
Benjamin
On Wed, Sep 30, 2015 at 3:17 PM, Richard Olsen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Lykke Corp based in Zürich funds the competition.
>
> 2 Mio Lykke coins (8'000 USD) is allocated to funding core development in
> next 3 months,
>
> Richard
>
> On 30.09.2015, at 14:22, Thomas Kerin <thomas.kerin at gmail.com> wrote:
>
> Who is funding this?
>
> Why not fund Core development?
> On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> All,
>>
>> We are looking for participants in a Bitcoin related competition: the aim
>> is to build a trading platform (initially for foreign exchange, other
>> assets will follow) which lets participants settle their trades through the
>> blockchain via coloured coins. To facilitate a quicker trade
>> reconciliation, the use of a sidechain is a suggestion but by no means a
>> requirement. There will be an online briefing event today where we will
>> outline the requirements in more detail, though much of it we have posted
>> on our website www.lykkex.com .
>>
>> As we want this to be a community driven effort rather than something
>> turning into a proprietary technology, all contributions will be made
>> available under a MIT license on Github.
>>
>> I look forward to answering your questions at the online briefing event
>> or over email,
>>
>> Thank you and kind regards,
>> Richard Olsen
>>
>>
>> _______________________________________________
>> 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/20150930/c28a42b2/attachment.html>

2023-06-07 17:39:15

- reply

📅 Original date posted:2015-09-03
📝 Original message:I would be helpful to describe what is meant by "votes". As far as I
understand this would be a semi-automatic process - nodes encode values
which in turn are hardcoded in software, or is this completely automated
without any intervention at all? Is there the possibility that nodes decide
by encode votes, but somehow this decision is not adhered to? Is 4. a 51%
rule?
Under 2. it might make sense to specify values in the range (1MB steps
e.g.). The number of options could have an effect. For example if the vote
has 4 possible values or 32 possible values can make a difference in
outcomes.
With regards to 1. Bitcoin does not have a fee market, although I agree
that might be a good goal. There is no price-determination of fees and no
definition of quality of service. A fee market would entail some matching
of demand and supply to establish a price. Users would adjust fee to win a
transaction slow in a deterministic way. However currently the user has no
way of knowing what effect a fee might have. So this would necessarily
include some kind pricing-mechanism with actual commitments. Bitcoin as a
system is quite far away from such a capability. It would mean Bitcoin is
capable of adapting to how it is used. For example that would allow to
shift transactions from high demand period to low demand period. I'm not
aware of any proposal to make an actual functioning fee market in Bitcoin
(or even the conceptual primitives).
On Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Oh, and answering your question about the 1M: It is a safety rail. It
> can perform no worse on the low end than the current system. Eliminates
> unlikely scenarios that squeeze users.
>
>
> On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
>> wrote:
>> > The repo: https://github.com/jgarzik/bip100
>>
>> What is the purpose of the newly added 1 MB floor? It seems clear from the
>> current information available that 1 MB is presently too high for the
>> limit,
>> and it is entirely one-sided to only allow increases when decreases are
>> much
>> more likely to be needed in the short term.
>>
>> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
>> numeric value pushed after height? Since this is a hardfork, I suggest
>> increasing the coinbase length to allow for 100 bytes *in addition* to the
>> pushed height and size-vote.
>>
>> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
>> MB
>> (or whatever value is deemed appropriate) to make it clear that the limit
>> remains a part of the consensus protocol and p2p protocol limits are not
>> to
>> have an effect on consensus rules.
>>
>> Furthermore, I suggest modifying the voting to require 50% to set the
>> limit
>> floor. This has the effect of merely coordinating what miners can already
>> effectively do today by rejecting blocks larger than some collusion-
>> determined limit.
>>
>> Thoughts?
>>
>> Luke
>>
>
>
> _______________________________________________
> 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/20150903/218cbfe4/attachment.html>

2023-06-07 17:34:22

- reply

📅 Original date posted:2015-08-08
📝 Original message:>> What is the problem that
you see in lightning model exactly?
How do you know who is who online? If Alice and Bob want to transact and
haven't exchanged keys before they need public-key infrastructure
out-of-band to identify themselves. Which means they are using SSL and
Certificate authorities and trust them. If you have non-cooperative hubs
they could flood the network and make it unusable. And why should hubs
cooperate? There are no incentives in the system.
On Sat, Aug 8, 2015 at 1:08 PM, s7r <s7r at sky-ip.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Interesting point of view Thomas! I agree that if we only think
> towards one single direction (treat trust as a super bad thing) we
> might miss some good features (or scalability levels) among the way.
>
> Benjamin:
> > 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.
>
> Can explain why exactly do you think this? What is the problem that
> you see in lightning model exactly? I am not arguing, maybe you are
> right and there is a part of the lightning network proposal which I
> missed, so that is why I am asking for clarification here.
>
> Lightning doesn't require explicit trust, worst case scenario you can
> end up with coins blocked until next in-chain broadcast. It depends on
> each and very hub, obviously there will also be trusted, identified
> public hubs but we can also have anonymous hubs.
>
> On 8/8/2015 12:24 PM, Benjamin via bitcoin-dev wrote:
> >>> 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
> > <mailto: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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBCAAGBQJVxeMaAAoJEIN/pSyBJlsRJFoH/RbgArUMJStQwF92XZk99dUd
> 0xI/VU1goFLDFiFVkrea7uNWUrWw0GM9nDq0kTIV+mTi9rTYgWKlgA1XZnPusr35
> GpDhXxoG3mJmay9AX1fezrZjGmCZPCjSnPWa+BeQCSMXnVchZX0U4XZSwgD7qTIU
> 7o4r5JIDuGxXyPcwECnB7ePmZ8xA2QGQaMW6nnMhlA4KCanSd5/78kcpUp/kGAJ1
> chjhV2g7tAeq3NMs2IXeIMiEAqji0B7RRAejviBg9CAwbpo4dP3dRz8hv/qPx6K0
> Mu6jHczCQOUyAHagwG8q4+laMbkskVETw18NwluspOZi3inxvVpOD60CDqSZPS4=
> =ogMZ
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/5696b441/attachment.html>

2023-06-07 17:34:21

- 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:32:51

- reply

📅 Original date posted:2015-08-05
📝 Original message:Very interesting paper. When you talk about a market, what are you
referring to exactly? A market means that demand and supply are matched
continuously, and Bitcoin has no such mechanism. A lot of discussion has
been around fixing the "supply" of blocksize. A floating number would mean
that a hardcoded number or function would be replaced by a decision process
involving users (demand). I don't think a fee market exists and that demand
or supply are not easily definable. Ideally supply of transaction
capability would completely depend on demand, and a price would exist such
that demand can react to longterm or shorterm supply constraints. In such a
scenario there would be no scalability concerns, as scale would be almost
perfectly elastic.
On Tue, Aug 4, 2015 at 8:40 AM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear Bitcoin-Dev Mailing list,
>
> I’d like to share a research paper I’ve recently completed titled “A
> Transaction Fee Market Exists Without a Block Size Limit.” In addition to
> presenting some useful charts such as the cost to produce large spam
> blocks, I think the paper convincingly demonstrates that, due to the
> orphaning cost, a block size limit is not necessary to ensure a functioning
> fee market.
>
> The paper does not argue that a block size limit is unnecessary in
> general, and in fact brings up questions related to mining cartels and the
> size of the UTXO set.
>
> It can be downloaded in PDF format here:
>
> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>
> Or viewed with a web-browser here:
>
>
> https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
>
> *Abstract. *This paper shows how a rational Bitcoin miner should select
> transactions from his node’s mempool, when creating a new block, in order
> to maximize his profit in the absence of a block size limit. To show this,
> the paper introduces the block space supply curve and the mempool demand
> curve. The former describes the cost for a miner to supply block space by
> accounting for orphaning risk. The latter represents the fees offered by
> the transactions in mempool, and is expressed versus the minimum block size
> required to claim a given portion of the fees. The paper explains how the
> supply and demand curves from classical economics are related to the
> derivatives of these two curves, and proves that producing the quantity of
> block space indicated by their intersection point maximizes the miner’s
> profit. The paper then shows that an unhealthy fee market—where miners are
> incentivized to produce arbitrarily large blocks—cannot exist since it
> requires communicating information at an arbitrarily fast rate. The paper
> concludes by considering the conditions under which a rational miner would
> produce big, small or empty blocks, and by estimating the cost of a spam
> attack.
>
> Best regards,
> Peter
>
> _______________________________________________
> 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/20150805/113f3d52/attachment.html>

- reply

- reply

- reply

- 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 15:40:55

- 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 15:40:54

- 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 15:40:50

- 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 15:40:49

- 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 15:40:48

- 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 15:38:37

- 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 15:38:28

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

- 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 15:37:33

- 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 15:37:28

- 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

2023-06-07 15:33:52

- reply

📅 Original date posted:2015-05-08
📝 Original message:>> Imagine a group of 1000 people who want to make a donation of 50BTC to something. They all way that they will donate 0.05BTC, but only if everyone else donates.
It still isn't perfect. Everyone has an incentive to wait until the
last minute to pledge. <<
AC does not solve the problem. AC works if people gain directly from
the payment. Imagine a group of people paying tax - nobody gains from
paying it. You have to actually need to enforce negative outcomes to
enable it (jail for tax fraud). Hence in Bitcoin we have the enforced
subsidy. AFAIK the problem of how to incentivize transaction
verification without subsidy is unsolved. Who determines a fair price?
People around here should study more economics, game theory, etc.
instead of debating low level encodings all the time.
On Fri, May 8, 2015 at 4:15 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> Just to clarify the process.
>
> Pledgers create transactions using the following template and broadcast
> them. The p2p protocol could be modified to allow this, or it could be a
> separate system.
>
> Input: 0.01 BTC
> Signed with SIGHASH_ANYONE_CAN_PAY
>
> Output 50BTC
> Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
>
> Output 0.01BTC
> Paid to OP_TRUE
>
> This transaction is invalid, since the inputs don't pay for the output. The
> advantage of the sighash "anyone can pay" field is that other people can add
> additional inputs without making the signature invalid. Normally, any
> change to the transaction would make a signature invalid.
>
> Eventually, enough other users have added pledges and a valid transaction
> can be broadcast.
>
> Input: 0.01 BTC
> Signed with SIGHASH_ANYONE_CAN_PAY
>
> Input: 1.2 BTC
> Signed with SIGHASH_ANYONE_CAN_PAY
>
> Input: 5 BTC
> Signed with SIGHASH_ANYONE_CAN_PAY
>
> <etc>
>
> Input: 1.3 BTC
> Signed with SIGHASH_ANYONE_CAN_PAY
>
> Output 50BTC
> Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
>
> Output 0.01BTC
> Paid to OP_TRUE
>
> This transaction can be submitted to the main network. Once it is included
> into the blockchain, it is locked in.
>
> In this example, it might be included in block 999,500. The 0.01BTC output
> (and any excess over 50BTC) can be collected by the block 999,500 miner.
>
> The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
> spent until block 1 million. Once block 1 million arrives, the output is
> completely unprotected. This means that the miner who mines block 1 million
> can simply take it, by including his own transaction that sends it to an
> address he controls. It would be irrational to include somebody else's
> transaction which spent it.
>
> If by block 999,900, the transaction hasn't been completed (due to not
> enough pledgers), the pledgers can spend the coin(s) that they were going to
> use for their pledge. This invalidates those inputs and effectively
> withdraws from the pledge.
>
> On Fri, May 8, 2015 at 11:01 AM, Benjamin <benjamin.l.cordes at gmail.com>
> wrote:
>>
>> 2. "A merchant wants to cause block number 1 million to effectively
>> have a minting fee of 50BTC." - why should he do that? That's the
>> entire tragedy of the commons problem, no?
>
>
> No, the pledger is saying that he will only pay 0.01BTC if the miner gets a
> reward of 50BTC.
>
> Imagine a group of 1000 people who want to make a donation of 50BTC to
> something. They all way that they will donate 0.05BTC, but only if everyone
> else donates.
>
> It still isn't perfect. Everyone has an incentive to wait until the last
> minute to pledge.

2023-06-07 15:33:51

- reply

📅 Original date posted:2015-05-08
📝 Original message:Interesting.
1. How do you know who was first? If one node can figure out where
more transactions happen he can gain an advantage by being closer to
him. Mining would not be fair.
2. "A merchant wants to cause block number 1 million to effectively
have a minting fee of 50BTC." - why should he do that? That's the
entire tragedy of the commons problem, no?
On Fri, May 8, 2015 at 11:49 AM, Mike Hearn <mike at plan99.net> wrote:
> Looks like a neat solution, Tier.
>
> ------------------------------------------------------------------------------
> 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
>