<unnamed>

Public Key

npub1a3zpmn53lhv8jv7vjg3daletu2e6e9ce88737ga2r7dkr7yc7dss7r6s85

Profile Code

nprofile1qqswc3qae6glmkrex0xfygk7lu479vavjuvnnlglyw4plxmplzv0xcgpgdmhxw309aaxgdnsw36kjdenxau85umrw4mrwdr6dfk8g73kde5nyethveexumfhdpcngmtdweaxjdm5v9nxwmrwwdkkwatt09jzummwd9hkuqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvcunr0j

Publishing to

zd6ptui737xzscuv74zjltz6ni2ewfrnm7hq4mmvzi7tafglnsmgukyd.onion

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:05:54 UTC

- reply

📅 Original date posted:2017-09-12
📝 Original message:It would be a good starting point if the current policy could be
clarified, so everyone is on the same page, and there is no confusion.
On 09/11/2017 09:49 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Historically people have published vulnerabilities in Bitcoin only after
>>80% of the nodes have upgraded. This seems to be the general (but not
> publicly stated) policy. If you're a core developer and you know better,
> please correct me.
>

2023-06-07 18:05:50 UTC

- reply

📅 Original date posted:2017-09-10
📝 Original message:Hi,
Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
conference, and the subsequent discussion around responsible disclosure
and industry practice, perhaps now would be a good time to discuss
"Bitcoin and CVEs" which has gone unanswered for 6 months.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013751.html
To quote:
"Are there are any vulnerabilities in Bitcoin which have been fixed but
not yet publicly disclosed? Is the following list of Bitcoin CVEs
up-to-date?
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
There have been no new CVEs posted for almost three years, except for
CVE-2015-3641, but there appears to be no information publicly available
for that issue:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
It would be of great benefit to end users if the community of clients
and altcoins derived from Bitcoin Core could be patched for any known
vulnerabilities.
Does anyone keep track of security related bugs and patches, where the
defect severity is similar to those found on the CVE list above? If
yes, can that list be shared with other developers?"
Best Regards,
Simon

2023-06-07 17:50:31 UTC

- reply

📅 Original date posted:2016-05-11
📝 Original message:On 05/11/2016 02:01 PM, Matt Corallo via bitcoin-dev wrote:
> Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments
> mostly died out long ago, and, indeed, the goal that many making those
> arguments had of building "unoptimizeable" ASICs failed with them.
Discussion quietened down but never went away. With centralization of
mining in China, the topic is up for discussion again. For example,
Z.Cash will now use Equihash as their proof-of-work scheme.
> giving one
> manufacturer/licenser a huge influence in who is successful in a market
> that we're all relying on remaining rather flat.
Central planning is a slippery slope. Let the market decide the winners
and losers. It's not feasible to hard fork every time an innovation or
perceived unfair advantage appears in the space.
--Simon

2023-06-07 17:43:54 UTC

- reply

📅 Original date posted:2015-10-30
📝 Original message:Storage of UTXO data looks like an implementation detail and thus one
would have thought that the choice of database would not increase the
odds of consensus protocol failure.
Btcd, a full node implementation written in Go, already provides a
database interface which supports different backends:
https://github.com/btcsuite/btcd/tree/master/database
Given that UTXO storage is considered critical, it seems reasonable to
let a node operator decide for themselves if they want data stored in
LevelDB (which is not fully ACID compliant) or a database like Sqlite,
Oracle, DB2 etc.
If the storage requirements for UTXO data are fairly simple, consisting
mainly of puts and gets, there is a decent argument that using a
dedicated key-value store provides superior performance over a
traditional SQL database.
However, from a practical perspective, given that nodes operate on a
range of different hardware and even a little Raspberry Pi can run a
full node and keep up with the network, why not let those users with the
resources to operate big iron databases do so? It would be a good
feature to have.
On 10/29/2015 01:03 AM, Luke Dashjr via bitcoin-dev wrote:
> I predict this would be a disaster. UTXO storage is CONSENSUS-CRITICAL code.
> Any divergence in implementation behaviour, including bugs AND bugfixes, may
> cause consensus failure. For this to have a reasonable *hope* of working, we
> need to choose one storage engine, and *will* need to maintain consensus-
> compatibility of it ourselves (since nobody else cares).
>
> Fixing LevelDB frankly seems like an easier task than switching to anything
> SQL-based, which would require a *lot* more *difficult-to-get-consensus-
> compatible* code that we are all (or at least mostly) very unfamiliar with.
>
> Research is fine, but let's be realistic about deployment.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:39:22 UTC

- reply

📅 Original date posted:2015-09-04
📝 Original message:Maybe grab some code from BIP101 ? It permits block messages > 2MB,
while retaining the current limit of 2 MB imposed on other network
messages. The 32 MB limit was patched a few months ago.
Links to code:
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
> The 32Mb limit is
> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>
> It's to keep the message size small enough that messages can be
> serialized in memory.
>
> Jeff if you decide to lift the 32MB limit (you really should, unless
> your plan is to potentially hard force another Blocksize discussion
> again which might be okay). I suggest having the 32MB ceiling auto-raise
> according to a exponential factor (1.5?) starting 1 year from now.
>
> Basically hard limit ceiling 2016-2017: 32 MB
> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>
> The factor could be 2 like BIP-101 but I imagine you will want to be
> more conservative. The delay time could also be longer if you think it
> will take longer to fix the message size issue across all implementations.
>

2023-06-07 17:35:50 UTC

- reply

📅 Original date posted:2015-08-19
📝 Original message:Yes, you're right, the Bitcoin Foundation is facing many challenges, but
that's an entirely different discussion.
The question in hand is this: was the request to remove Gavin made by an
individual of their own volition, reflecting their own personal opinion,
or was it made on behalf of the company?
If the latter, it would imply that compromise is unlikely to be reached
and thus the ecosystem should start planning immediately for the
potential hard fork, rather than waiting and hoping for things to be
resolved.
On 08/19/2015 11:13 AM, Peter Todd wrote:
> On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
>> Olivier Janssens claims that one of your colleagues is asking for Gavin
>> to be removed from his position. Is this true?
>>
>> https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
>>
>> http://pastebin.com/q2TT58Z5
>
> IMO that's a very reasonable request; lately I've spent a lot of time
> having to educate journalists on how Bitcoin doesn't have a "chief
> scientist" with any kind of authority. Having Gavin Andresen in that
> position at the otherwise inactive and bankrupt Bitcoin Foundation
> misleads the public about the true nature of how Bitcoin operates,
> giving a misleading impression that it has the same centralized decision
> making as conventional financial systems do. Among other things, this
> harms the reputation of Bitcoin as a whole as it can confuse the public
> into thinking there aren't major differences between Bitcoin and those
> conventional financial systems.
>
> As the email said "Regardless of your personal view on XT this is bad
> for bitcoin." - a statement I agree with 100%
>

2023-06-07 17:35:49 UTC

- reply

📅 Original date posted:2015-08-19
📝 Original message:Olivier Janssens claims that one of your colleagues is asking for Gavin
to be removed from his position. Is this true?
https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
http://pastebin.com/q2TT58Z5
> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
>
> Gavin, Mike - anything to say here?
>
> Adam

2023-06-07 17:33:37 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message:That's a good question.
An argument has been put forward that a larger block size would reduce
the security of the network, so does the converse hold?
On 08/07/2015 11:17 AM, jl2012 via bitcoin-dev wrote:
> What if we reduce the block size to 0.125MB? That will allow 0.375tx/s.
> If 3->24 sounds "almost the same", 3->0.375 also sounds almost the same.
> We will have 50000 full nodes, instead of 5000, since it is so
> affordable to run a full node.
>
> If 0.125MB sounds too extreme, what about 0.5/0.7/0.9MB? Are we going to
> have more full nodes?
>
> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or
> less full nodes if we reduce the block size?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:47:31 UTC

- reply

2023-06-07 15:47:31 UTC

- reply

2023-06-07 15:45:44 UTC

- reply

2023-06-07 15:45:22 UTC

- reply

📅 Original date posted:2015-08-11
📝 Original message:There's also an interesting question posted over at Reddit - will
Lightning payment hubs be treated as money transmitters in the US?
https://www.reddit.com/r/bitcoin_uncensored/comments/3gjnmd/lightning_may_not_be_a_scaling_solution/
A payment hub operator working with brand name merchants like Disney and
Gap would most likely adopt any licensing and AML/KYC regulations.
Some folk might thus find themselves forced to use anonymous hubs with
strict routing requirements to avoid commercial hubs. Given the reduced
number of available channels, this could drive up lightning network fees
for those folk.
Of course, two parties can avoid any intermediary by using a regular
on-chain transaction, but it might not be feasible if Bitcoin is
operating as a settlement network with high transaction fees.
On 08/11/2015 02:01 AM, Hector Chu via bitcoin-dev wrote:
> Lightning will never catch on as it basically demands that everyone who
> uses it to become a speculator. Payment hubs and merchants will be at
> the mercy of the bitcoin price while their funds stay locked up in
> payment channels. This idea is a dead-end.
>
> On 10 August 2015 at 22:43, Adam Back via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> In terms of usage I think you'd more imagine a wallet that basically
> parks Bitcoins onto channels at all times, so long as they are
> routable there is no loss, and the scalability achieved thereby is
> strongly advantageous, and there is even the potential for users to
> earn fees by having their wallets participate in channel rebalancing
> (where hubs pay users to rebalance channels - end up with the same net
> position but move funds from one user-owned channel to another.)
> Exchange deposit, withdrawal, payments, even in-exchange trades can
> usefully happen in lightning for faster, cheaper more scalable
> transactions.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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
>

2023-06-07 15:44:38 UTC

- reply

📅 Original date posted:2015-08-03
📝 Original message:Increasing the block size shouldn't be a problem for Chinese miners.
Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
already signed a draft agreement indicating they are fine with an
increase to 8 MB: http://www.8btc.com/blocksize-increase-2
With regards to China's international bandwidth, not only is intra-Asia
capacity improving all the time, a major consortium cable FASTER is
coming online Q2 2016. Backed by Google, China Telecom and others, it
has a capacity of 60 Tbps, making it the highest-capacity data link ever
created across the Pacific.
Interactive map: http://www.submarinecablemap.com/
FASTER: https://plus.google.com/+UrsH%C3%B6lzle/posts/haJzDXnp9Z4
--Simon
On 08/02/2015 11:34 PM, Adam Back via bitcoin-dev wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners,
> it is not the Chinese miners that lose, it is all of the non-Chinese
> miners - this is because the Chinese miners have the slight majority of
> the hashrate. The relatively low external bandwidth connecting China to
> the net is actually the problem of the non-Chinese miners problem. Non
> Chinese miners will experience higher orphan rate once Chinese miners
> cease to build on top of blocks that are too large to sync in a timely
> fashion into China.
>
> Adam
>
> On 2 August 2015 at 23:02, Jim Phillips via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> China is a communist country. It is no secret that all "capitalist"
> enterprises are essentially State controlled, or at the very least
> are subject to nationalization should the State deem it necessary.
> Most ASIC chips are manufactured in China, so they are cheap and
> accessible to Chinese miners. Electricity is subsidized and
> essentially free. Cooling is not an issue since large parts of China
> are mountainous and naturally cool. In short the Chinese miners have
> HUGE advantages over all other mining operations. This is probably
> why, between just the top 4 Chinese miners, the People's Republic of
> China effectively controls 57% of all the Bitcoin being mined.
>
> The ONLY disadvantage the Chinese miners have in competing with the
> rest of the world is bandwidth. China has poor connectivity with the
> rest of the world, and Chinese miners have said that an increase in
> the block size would be detrimental to them. I say, GOOD! Most of
> the free world has enough bandwidth to be able to handle larger
> blocks. We need to take advantage of that fact to get mining out of
> the centralized control of the Chinese.
>
> If you're truly worried about larger blocks causing centralization,
> think about how, by restricting blocksize, you're enabling the
> Communist Chinese government to maintain centralized control over
> 57% of the Bitcoin hashing power.
>
> --
> *James G. Phillips
> IV* <https://plus.google.com/u/0/113107039501292625391/posts> <http://www.linkedin.com/in/ergophobe>
> /"Don't bunt. Aim out of the ball park. Aim for the company of
> immortals." -- David Ogilvy
> /
>
> /This message was created with 100% recycled electrons. Please
> think twice before printing./
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto: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
>

2023-06-07 15:42:56 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:Increasing the block size does not hinder research and development of
Lightning or other technologies.
On 07/23/2015 05:04 PM, Eric Lombrozo via bitcoin-dev wrote:
> I should also add that I think those who claim that fee pressure will
> scare away users and break the industry are *seriously* underestimating
> human ingenuity in the face of a challenge. We can do this - we can
> overcome this obstacle…we can find good solutions to a fee market.
> Unless someone can come up with another way to pay for the operation of
> the network, we NEED to do this. What makes anyone think it will be
> easier to do later rather than now? The longer we wait, the lower block
> rewards get, the larger the deployed infrastructure, the larger our
> userbase, the HARDER it will be to solve it. We should solve it now - we
> will be much better off for it…and so will our users.
>

2023-06-07 15:39:47 UTC

- reply

📅 Original date posted:2015-06-26
📝 Original message:If Bitcoin is a $3bn project where stakeholder interests are to be
safeguarded, or if Bitcoin is to be compared to a civil engineering
project where life and death is at stake, it seems only logical that a
well-defined and well-documented process be introduced to properly
evaluate proposed changes. Although too late for the block size debate,
it seems odd that discussion of such a process is often dismissed out of
hand.
To maintain the current approach of supermajority consensus, based
around ingrained wisdom, personal preference and unwritten rules would
suggest that Bitcoin is still an experiment, in which case perhaps any
decision regarding the block size should be based upon technical merit
alone rather than economic interest.
--Simon
> You're the one proposing a change here; we're evaluating the safety of
that change.
> In civil engineering we have enough experience with disasters to know
> that you can't give into political pressure to do potentially dangerous
> things until the consequences are well understood; hopefully we'll learn
> that in the consensus cryptography space before a big disaster rather
> than after.