Marcel Jamin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-01 to 2018-08-01
💬 Posted a total of 26 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:13:53

- reply

📅 Original date posted:2018-08-01
📝 Original message:IMHO you should almost never publish a service that asks users for private
keys.
A warning isn't enough. Your server might get compromised.
"Move your coins by yourself" isn't even correct if your server is involved.
On Tue, 31 Jul 2018 at 13:26, Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I know this list is not to advertise personal projects but
> https://peersm.com/wallet might be of some interest, this is the web
> interface for https://github.com/Ayms/bitcoin-transactions since
> apparently quasi nobody succeeds to use it
>
> As far as I know (and surprisingly) this is the only online tool that
> converts bech32 addresses (Sipa's one does not output something
> understandable by everybody, the tool is using his code), the only one
> that converts from any address to any address, maybe the only one that
> decodes simply redeem scripts and probably the only one that allows to
> create transactions by its own (the advanced mode is not implemented for
> now but will be soon)
>
> Ideally it should be an offline tool if there is some incentive to do
> so, so of course it is not advised to use his private keys for now
>
> Maybe they are mistaken but some users are reporting invalid bech32
> addresses from their Electrum wallet, after segwit, bech32 confusion
> seems to be the topic of the moment
>
> Regards
>
> Aymeric
>
> --
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
> _______________________________________________
> 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/20180801/7f4e4e8f/attachment.html>

2023-06-07 20:08:43

- reply

📅 Original date posted:2017-12-15
📝 Original message:I think one could make the argument that the only people who talk
about and understand 24 bit audio or 256 bit cryptography are the ones
who can tell the difference very easily.
To me, your example seems to try hard to make the case for a problem
that won't exist in reality.
Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
>correct< approach. It's tidy, systematic and precise. But that won't
stop people from using something that's easier to deal with as I just
had to google the µ character again.
Let's also keep in mind that Coinbase has been using "bits" as the
default for over 2 years now:
https://blog.coinbase.com/bits-is-the-new-default-and-all-new-users-get-100-bits-for-free-9165f757594b
Just from a linguistic standpoint, chances are we'll end up with bits
anyway. Why fight it? We don't have a SI prefix educational mandate.
Marcel
On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
>
> Reposting /u/BashCo's post on reddit here, for visibility:
>
> ---8<---------------------------------------------------------------
>
>> Before anyone says 'bits' are too confusing because it's a computer
>> science term, here's a list of homonyms
>> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every
>> day. Homonyms are fine because our brains are able to interpret language
>> based on context, so it's a non-argument.
>
>
> This ignores the fact that there exists multiple meanings of bits *within
> the same context*, and that beginners likely can't tell them apart.
>
> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
> value with somebody who doesn't understand Bitcoin. Then explain that the
> cryptography uses 256 bit keys. I would be surprised if you could find
> somebody who would not be confused by that.
>
> Let's say a website says a song is 24 bits. Was that 24 bit audio resolution
> or 24 bit price? Somebody writes about 256 bit keys, are that their size or
> value?
>
> You guys here can probably tell the difference. Can everybody...? Bits will
> cause confusion, because plenty of people will not be able to tell these
> apart. They will not know WHEN to apply one definition or the other.
>
> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>
>

2023-06-07 20:08:42

- reply

📅 Original date posted:2017-12-14
📝 Original message:On 13 December 2017 at 22:36, David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> - Microbitcoins is not a homonym for any other word in English (and
> probably not in any other language), whereas "bit" and "bits" have
> more than a dozen homonyms in English---some of which are quite common
> in general currency usage, Bitcoin currency usage, or Bitcoin
> technical usage.
Reposting /u/BashCo's post on reddit here, for visibility:
---8<---------------------------------------------------------------
> Before anyone says 'bits' are too confusing because it's a computer science term, here's a list of homonyms [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every day. Homonyms are fine because our brains are able to interpret language based on context, so it's a non-argument. Also, the term 'bits' was used in reference to money long before 'bits and bytes' came along, and even before the metric system itself.
> https://en.wikipedia.org/wiki/Bit_(money)
> https://en.wikipedia.org/wiki/Spanish_colonial_real
> 'Bits' are superior to mBTC partly because we'll need to transition to bits eventually anyways (one transition is easier than two), but more importantly, bits have two decimal places, matching the format of dozens of other major currencies.
> No other currency has 8 decimal places, or even 4 decimal places. Most of them have 2. Dollars and cents, Bits and satoshis.
> If people actually want this to happen, then they need to train their own brains by switching their wallets and exchange settings to bits. The shift will probably happen eventually, although the major Bitcoin denomination probably isn't going anywhere any time soon, even if the majority of people use 'bits' as a matter of habit.
> 99.99 bits is currently equal to $1.63 USD.
---8<---------------------------------------------------------------
>
> - Microbitcoins trains users to understand SI prefixes, allowing them to
> easily migrate from one prefix to the next. This will be important
> when bitcoin prices rise to $10M USD[1] and the bits denomination has
> the same problems the millibitcoin denomination has now, but it's also
> useful in the short term when interacting with users who make very
> large payments (bitcoin-scale) or very small payments
> (nanobitcoin-scale).[2] Maybe a table of scale can emphasize this
> point:
>
> Wrong (IMO): Right (IMO):
> --------------- --------------
> BTC BTC
> mBTC mBTC
> bits µBTC
> nBTC nBTC
>
I wouldn't expect people to type out µBTC. I think the best you can
hope for here is uBTC. As for saying "microbitcoins", I can virtually
guarantee that this will be abbreviated to "microbits" and/or
eventually "bits" anyway. Bits and sats.
> [1] A rise in price to $10M doesn't require huge levels of growth---it
> only requires time under the assumption that a percentage of bitcoins will
> be lost every year due to wallet mishaps, failure to inherit bitcoins,
> and other issues that remove bitcoins from circulation. In other words,
> it's important to remember that Bitcoin is expected to become a
> deflationary currency and plan accordingly.
>
> [2] Although Bitcoin does not currently support committed
> nanobitcoin-scale payments in the block chain, it can be supported in a
> variety of ways by offchain systems---including (it is hypothesized)
> trustless systems based on probabilistic payments.
>
> Thanks,
>
> -Dave
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 20:00:28

- reply

📅 Original date posted:2017-04-18
📝 Original message:Probably a bad idea for various reasons, but tagging (fee paying)
transactions with info about the capabilities of the node that created
it might be interesting? Might be useful to gauge economic support for
certain upgrades, especially if excluding long transaction chains,
etc. In the very least it would be a far better indicator than simply
counting reachable nodes.
On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If users added a signal to OP_RETURN, might it be possible to tag all
> validated input addresses with that signal.
>
> Then a node can activate a new feature after the percentage of tagged input
> addresses reaches a certain level within a certain period of time?
>
> This could be used in addition to a flag day to trigger activation of a
> feature with some reassurance of user uptake.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:56:56

- reply

📅 Original date posted:2017-03-05
📝 Original message:> This could even come in the form of a Bitcoin address.
Wouldn't this actually *need* to be a bitcoin address that is included in a
block to get any real assurances about the age if this node id? Otherwise
malicous nodes could lie and claim to have seen a brand new node id years
ago already.
Even if included in a block, people could sell their aged IDs (if we were
to rely on those for anything).
Also funding that ID address would might tie your economic activity (or
even identity) to a node.
On 4 March 2017 at 17:04, John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> john at seebitcoin.com
>
>
> _______________________________________________
> 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/20170305/baaa502c/attachment.html>

2023-06-07 19:56:55

- reply

📅 Original date posted:2017-03-07
📝 Original message:> Why are multiple results separated by a line-feed rather than using a JSON Array?
> * Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file.
> * Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time.
> What if long descriptions require line and paragraph breaks?
> * Clients should word-wrap long lines, and JSON escapes newlines as "\n" which can be used doubly ("\n\n") for paragraph breaks.
I'd file this under premature optimization at the cost of
interoperability. If you use JSON, then please use it properly.
I'd also say it's the job of the parser to offer a way of doing that,
e.g. in .NET you can easily achieve that with Newtonsoft's JSON
parser: http://stackoverflow.com/questions/20374083/deserialize-json-array-stream-one-item-at-a-time.
On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Investigating what it would take to add fiat currency information to Bitcoin
> Knots, I noticed Electrum currently has many implementations, one for each
> exchange rate provider, due to lack of a common format for such data.
>
> Therefore, I put together an initial draft of a BIP that could standardise
> this so wallets (or other software) and exchange rate providers can simply
> interoperate without a lot of overhead reimplementing the same thing many
> ways.
>
> One thing I am unsure about, is that currently this draft requires using XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis, but those
> don't really have a pseudo-ISO currency code to fit in nicely...
>
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.mediawiki
>
> Thoughts? Anything critical missing? Ways to make the interface better?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:47:24

- reply

📅 Original date posted:2015-12-30
📝 Original message:I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.
2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> As a first impression, I think this proposal is intellectually
> interesting, but crufty and hackish and should never actually be deployed.
> Writing code for Bitcoin in a future in which we have deployed a few
> generalized softforks this way sounds terrifying.
>
> Instead of this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> return block->vtx[index];
> }
>
> We might have this:
>
> CTransaction GetTransaction(CBlock block, unsigned int index) {
> if (!IsBIP102sBlock(block)) {
> return block->vtx[index];
> } else {
> if (!IsOtherGeneralizedSoftforkBlock(block)) {
> // hooray! only one generalized softfork level to deal
> with!
> return
> LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index];
> } else {
> throw NotImplementedError; // I'm too lazy to write
> pseudocode this complicated just to argue a point
> }
> }
>
> It might be possible to make that a bit simpler with recursion, or by
> doing subsequent generalized softforks in a way that doesn't have
> multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh.
>
>
>
>
> On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Below is a proof-of-concept implementation of BIP102 as a softfork:
> >
> > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
> >
> https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
> >
> > BIP102 is normally a hardfork. The softfork version (unofficial
> > codename BIP102s) uses the idea described here:
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
> >
> > The basic idea is that post-fork blocks are constructed in such a way
> > they can be mapped to valid blocks under the pre-fork rules. BIP102s
> > is a softfork in the sense that post-fork miners are still creating a
> > valid chain under the old rules, albeit indirectly.
> >
> > From the POV of non-upgraded clients, BIP102s circumvents the
> > block-size limit by moving transaction validation data "outside" of
> > the block. This is a similar trick used by Segregated Witness and
> > Extension Blocks (both softfork proposals).
> >
> > From the POV of upgraded clients, the block layout is unchanged,
> > except:
> > - A larger 2MB block-size limit (=BIP102);
> > - The header Merkle root has a new (backwards compatible)
> > interpretation;
> > - The coinbase encodes the Merkle root of the remaining txs.
> > Aside from this, blocks maintain their original format, i.e. a block
> > header followed by a vector of transactions. This keeps the
> > implementation simple, and is distinct from SW and EB.
> >
> > Since BIP102s is a softfork it means that:
> > - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This
> > is not true for a hardfork.
> > - Fraud risk is significantly reduced (6-conf unlikely depending on
> > activation threshold).
> > This should address some of the concerns with deploying a block-size
> > increase using a hardfork.
> >
> > Notes:
> >
> > - The same basic idea could be adapted to any of the other proposals
> > (BIP101, 2-4-8, BIP202, etc.).
> > - I used Jeff Garzik's BIP102 implementation which is incomplete (?).
> > The activation logic is left unchanged.
> > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
> > code :-(
> >
> > --joe
> >
> > _______________________________________________
> > 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/20151230/5c2838ea/attachment.html>

2023-06-07 19:42:45

- reply

📅 Original date posted:2015-10-06
📝 Original message:This is childish and very disappointing to see.
2015-10-06 9:20 GMT+02:00 Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> I prefer the term "clown".
>
> Can we please move on?
>
> ------ Original Message ------
> From: "cipher anthem via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>
> To: milly at bitcoins.info
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Sent: 10/6/2015 12:17:14 AM
> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
> technical debate
>
> Sent: Monday, October 05, 2015 at 8:21 PM
>>> From: "Milly Bitcoin via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org>
>>> To: bitcoin-dev at lists.linuxfoundation.org
>>> Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
>>> technical debate
>>> On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
>>>
>>>> It's pretty clear Mike has turned into concern troll and bully.
>>>>
>>>
>> "troll" and, even worse, "concern troll" are terms generally used by
>>> teenagers on places like Reddit to complain about someone who doesn't
>>> agree with them.
>>>
>>
>> They should substitute troll for cultist so they appear more
>> professional...
>> _______________________________________________
>> 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/20151006/10d3c219/attachment.html>

2023-06-07 19:42:13

- reply

📅 Original date posted:2015-10-01
📝 Original message:---------- Forwarded message ----------
From: Marcel Jamin <marcel at jamin.net>
Date: 2015-10-01 11:39 GMT+02:00
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
To: Btc Drak <btcdrak at gmail.com>
I guess the question then becomes why bitcoin still is <1.0.0
I'd say it's safe to say that it's used in production.
2015-10-01 11:17 GMT+02:00 Btc Drak <btcdrak at gmail.com>:
> On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>>
>
> We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
> are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/17164b7e/attachment.html>

2023-06-07 19:35:44

- reply

📅 Original date posted:2015-08-17
📝 Original message:His account on that website was also compromised.
2015-08-17 21:02 GMT+02:00 Anon Moto via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Satoshi,
>
> As much as I want to believe this is you it's very difficult to ignore the
> fact that Vistomail could have been hacked and I'm currently speaking to a
> troll.
> Can you copy and paste what you wrote above, to
> http://p2pfoundation.ning.com as well, like how you did during the Dorian
> fiasco?
>
>
> Much appreciated.
>
>
> On Sat, Aug 15, 2015 at 10:43 AM, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have been following the recent block size debates through the mailing
>> list. I had hoped the debate would resolve and that a fork proposal would
>> achieve widespread consensus. However with the formal release of Bitcoin
>> XT 0.11A, this looks unlikely to happen, and so I am forced to share my
>> concerns about this very dangerous fork.
>>
>> The developers of this pretender-Bitcoin claim to be following my
>> original vision, but nothing could be further from the truth. When I
>> designed Bitcoin, I designed it in such a way as to make future
>> modifications to the consensus rules difficult without near unanimous
>> agreement. Bitcoin was designed to be protected from the influence of
>> charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or
>> Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have
>> to do it without being forced or pressured into it. By doing a fork in
>> this way, these developers are violating the "original vision" they claim
>> to honour.
>>
>> They use my old writings to make claims about what Bitcoin was supposed
>> to be. However I acknowledge that a lot has changed since that time, and
>> new knowledge has been gained that contradicts some of my early opinions.
>> For example I didn't anticipate pooled mining and its effects on the
>> security of the network. Making Bitcoin a competitive monetary system
>> while also preserving its security properties is not a trivial problem, and
>> we should take more time to come up with a robust solution. I suspect we
>> need a better incentive for users to run nodes instead of relying solely on
>> altruism.
>>
>> If two developers can fork Bitcoin and succeed in redefining what
>> "Bitcoin" is, in the face of widespread technical criticism and through the
>> use of populist tactics, then I will have no choice but to declare Bitcoin
>> a failed project. Bitcoin was meant to be both technically and socially
>> robust. This present situation has been very disappointing to watch unfold.
>>
>> Satoshi Nakamoto
>>
>> _______________________________________________
>> 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/20150817/cb0411d3/attachment-0001.html>

2023-06-07 17:47:27

- reply

2023-06-07 17:44:19

- reply

📅 Original date posted:2015-07-31
📝 Original message:> Quite possibly bigger blocks == more users == more nodes and more miners.
I agree and would say that this is the only prediction of bitcoin's future
we can be absolutely sure of: more users equals more decentralization as
long as the cost of running a node is not prohibitively high.
It's incredibly cheap today and won't be too high with any of the current
proposals for the time being. If the "laws" of Nielsen & co suddenly don't
apply anymore, we can always react to that with another hardfork reducing
the rate of growth. Hardforks are way easier if the network is in danger
and the necessary change is obvious and non-controversial (e.g. "reduce
blocksize limit growth").
As long as hobbyists can participate in running the network and it's
affordable for everyone to transact on it, bitcoin will grow and its
decentralization with it, however you measure it.
2015-07-31 14:15 GMT+02:00 Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Hey Jorge,
>
> He is not saying that. Whatever the reasons for centralization are, it
>> is obvious that increasing the size won't help.
>>
>
> It's not obvious. Quite possibly bigger blocks == more users == more nodes
> and more miners.
>
> To repeat: it's not obvious to me at all that everything wrong with
> Bitcoin can be solved by shrinking blocks. I don't think that's going to
> suddenly make everything magically more decentralised.
>
> The 8mb cap isn't quite arbitrary. It was picked through negotiation with
> different stakeholders, in particular, Chinese miners. But it should be
> high enough to ensure organic growth is not constrained, which is good
> enough.
>
> I think it would be nice to have some sort of simulation to calculate
>> a "centralization heuristic" for different possible blocksize values
>> so we can compare these arbitrary numbers somehow.
>
>
> Centralization is not a single floating point value that is controlled by
> block size. It's a multi-faceted and complex problem. You cannot "destroy
> Bitcoin through centralization" by adjusting a single constant in the
> source code.
>
> To say once more: block size won't make much difference to how many
> merchants rely on payment processors because they aren't using them due to
> block processing overheads anyway. So trying to calculate such a formula
> won't work. Ditto for end users on phones, ditto for developers who want
> JSON/REST access to an indexed block chain, or hosted wallet services, or
> miners who want to reduce variance.
>
> None of these factors have anything to do with traffic levels.
>
> What people like you are Pieter are doing is making a single number a kind
> of proxy for all fears and concerns about the trend towards outsourcing in
> the Bitcoin community. Everything gets compressed down to one number you
> feel you can control, whether it is relevant or not.
>
> > So why should anyone go through the massive hassle of setting up
>> exchanges,
>> > without the lure of large future profits?
>>
>> Are you suggesting that bitcoin consensus rules should be designed
>> to maximize the profits of Bitcoin exchanges?
>>
>
> That isn't what I said at all Jorge. Let me try again.
>
> Setting up an exchange is a lot of risky and expensive work. The
> motivation is profit, and profits are higher when there are more users to
> sell to. This is business 101.
>
> If you remove the potential for future profit, you remove the motivation
> to create the services that we now enjoy and take for granted. Because if
> you think Bitcoin can be useful without exchanges then let me tell you, I
> was around when there were none. Bitcoin was useless.
>
> _______________________________________________
> 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/20150731/1e4a3fc2/attachment-0001.html>

2023-06-07 17:43:19

- reply

📅 Original date posted:2015-07-23
📝 Original message:He measured the upload capacity of the peers by downloading from them, or
am I being dumb? :)
2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >This does not support the theory that the network has the available
> >bandwidth for increased block sizes, as in its current state 37% of
> >nodes would fail to upload a 20MB block to a single peer in under 20
> >seconds (referencing a number quoted by Gavin). If the bar for
> >suitability is placed at taking only 1% of the block time (6 seconds)
> >to upload one block to one peer, then 69% of the network fails for 20MB
> >blocks. For comparison, only 10% fail this metric for 1MB blocks.
>
> Note how due to bandwidth being generally asymetric your findings are
> probably optimistic - you've measured download capacity. On top of that
> upload is further reduced by the fact that multiple peers at once need to
> be sent blocks for reliability.
>
> Secondly you're measuring a network that isn't under attack - we need
> significant additional margin to resist attack as performance is
> consensus-critical.
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsRCj
> AAoJEMCF8hzn9Lnc47AIAIQbznavjd2Rbqxeq5a3GLqeYoI4BZIQYqfWky+6OQtq
> yGRKaqPtGuES5y9L0k7efivT385mOl87PWnWMy61xxZ9FJgoS+YHkEx8K4tfgfA2
> yLOKzeFSar2ROCcjHYyPWa2XXjRbNmiLzfNuQyIBArg/Ch9//iXUUM+GG0mChF5k
> nUxLstXgXDNh5H8xkHeLi4lEbt9HFiwcZnT1Tzeo2dvVTujrtyNb/zEhNZScMXDc
> UOlT8rBLxzHlytKdXt1GNKIq0feTRJNbreBh7/EB4nYTT54CItaaVXul0LdHd5/2
> kgKtdbUdeyaRUKrKcvxiuIwclyoOuRQp0DZThsB262o=
> =tBUM
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20150723/a4aa2bc7/attachment.html>

2023-06-07 17:38:49

- reply

📅 Original date posted:2015-06-19
📝 Original message:> At the risk of stating cliches, the Mac came before the Windows PC…Yahoo!
came before Google…MySpace came before Facebook…
And TCP/IP came before... oh wait...
2015-06-19 14:02 GMT+02:00 Eric Lombrozo <elombrozo at gmail.com>:
>
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back <adam at cypherspace.org> wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon. They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
>
>
> Exactly, Adam.
>
> Except, I think the genie is out of the bottle - these ideas are too
> powerful for them to be killed forever. They will probably survive even if
> this scenario comes to pass…but in a different network under a different
> name…and Bitcoin will be relegated to the history books and walls of
> museums.
>
> Most of the potential brainpower available on this Earth to make serious,
> profound contributions to this movement haven’t even begun to touch it.
> Just because you happen to run a Bitcoin startup right now…even if you’ve
> received millions of dollars in funding…don’t think that the whole world
> has low standards and is lazy! Someone WILL eventually build something
> better than we can presently imagine.
>
> First mover advantage and the network effect are vastly overrated. At the
> risk of stating cliches, the Mac came before the Windows PC…Yahoo! came
> before Google…MySpace came before Facebook…Bitcoin came before <we don’t
> know yet>.
>
>
> - Eric Lombrozo
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/78d7b5cf/attachment.html>

2023-06-07 17:38:20

- reply

📅 Original date posted:2015-06-16
📝 Original message:> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/5f789e97/attachment.html>