Ricardo Filipe [ARCHIVE]

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

Public Key

npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksaj

Profile Code

nprofile1qqs25hx4ztc48am65v6aw9un7txjr9tfrz9wm27h6q3e8p430amj3kqzfvsny

Author Public Key

npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksaj

Show more details

Last Notes

2023-06-07 22:55:05

- reply

📅 Original date posted:2021-06-28
📝 Original message:I believe Zman meant issuer.
raymo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu
no dia segunda, 28/06/2021 à(s) 18:45:
>
> Hi Greg,
> You are right, the whole scenario is:
> there is an issuer which own a UTXO
> issuers get fiat money or goods or services from creditor in exchange of
> a transaction.
> the transactions are intended to circulate in Sabu protocol instead of
> sending to Bitcoin network.
> creditor can not sign the transaction at all. instead he can ask issuer
> to change the balances (transaction outputs) and transfer some of his
> money to other creditor...
> here is complete paper to read it carefully:
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Cheers
> Raymo
>
>
> On 2021-06-28 17:29, Tao Effect wrote:
> > Hi ZmnSCPxj & Raymo,
> >
> >> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Good morning Raymo,
> >>
> >>> Hi ZmnSCPxj,
> >>
> >>> […]
> >> What prevents the creditor from signing a transaction that is
> >> neither a valid MT nor a GT?
> >>
> >> Nothing.
> >
> > How would the creditor create such a transaction? They need the
> > issuer’s private key, so they can’t create it? Am I
> > misunderstanding the scenario you’re describing? If so could you
> > give a more detailed description?
> >
> > Cheers,
> > Greg
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:17:14

- reply

📅 Original date posted:2019-03-31
📝 Original message:one year seems too long. i think with the BIP-148 experience you have
we could easily get there in 6 months at most.
Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia segunda, 1/04/2019 à(s) 01:33:
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to the
> price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing, weight
> calculation, and so on, the output count must be incremented by one. Prior to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero, and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions. Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1), a
> block is reject as invalid unless all transactions it contains both declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:07:13

- reply

📅 Original date posted:2017-10-30
📝 Original message:start double checking the last few bytes instead?
2017-10-30 8:56 GMT+00:00 shiva sitamraju via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>:
> Hi,
>
> When I copy and paste bitcoin address, I double check the first few bytes,
> to make sure I copied the correct one. This is to make sure some rogue
> software is not changing the address, or I incorrectly pasted the wrong
> address.
>
>
> With Bech32 address, its seems like in this department we are taking as step
> in the backward direction. With the traditional address, I could compare
> first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see and
> compare which is likely to be same anyway. Note that most users will only
> compare the first few bytes only (since addresses themselves are very long
> and will overflow in a mobile text box).
>
> Is there anyway to make the Bech32 addresses format more visually distinct
> (atleast the first few bytes) ?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:49:02

- reply

📅 Original date posted:2016-02-09
📝 Original message:I believe i've seen Luke say this several times before, but there are
several more things that the majority of the devs agree should be in
bitcoin.
I would suggest to compile that list for your stage 3, so that you can have
an hardfork that fixes most of those things, and there should be some
repository with those changes deployed.
2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
>
> Objectives:
>
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
>
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
>
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
>
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
>
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one
> should
> be mining on the old chain at that time)
>
> -------------------------------
> An alternative roadmap would be:
>
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
>
> Stage 3 is fixes that will break all existing full nodes and light nodes.
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
>
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3,
> which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
>
> -------------------------------
>
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
>
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
>
> Reference:
> Matt Corallo's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
>
>
>
>
>
> _______________________________________________
> 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/20160209/8baa5e97/attachment-0001.html>

2023-06-07 17:46:15

- reply

📅 Original date posted:2015-12-13
📝 Original message:I really like ideas that tackle this issue. The question imho is what is
the incentive to run a "Full UTXO node" instead of a pruned or archive node.
For starters, it would be nice to know what would be the savings for Full
UTXO nodes over archive nodes right now.
Also, what advantages would this have over "archive pruned nodes: nodes
that store X blocks of the whole blockchain before 420000". Seems like an
interesting intermediate use case to me too.
2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe at gmail.com>
> wrote:
>
>> What is the current behavior / cost that this proposal is trying to
>> avoid? Are ancient utxos required to be kept in memory always in a fully
>> validating node, or can ancient utxos get pushed out of memory like a
>> normal LRU caching db?
>>
>
> I don't see why it must be kept in memory. But storage is still a problem.
> With the 8 year limit and a fixed max block size, it indirectly sets an
> upper limit for UTXO set.
>
>
> Chris Priest via bitcoin-dev :
>
>> This isn't going to kill bitcoin, but it won't make it any better.
>>
>
> Do you believe that thousands of volunteer full nodes are obliged to store
> an UTXO record, just because one paid US$0.01 to an anonymous miner 100
> years ago? It sounds insanely cheap, isn't it? My proposal (or similar
> proposal by Peter Todd) is to solve this problem. Many commercial banks
> have a dormant threshold less than 8 years so I believe it is a balanced
> choice.
>
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
> Currently, if one holds nothing but a private key, he must consult either
> an archive node or a full UTXO node for the latest UTXO state to spend his
> coin. We currently do not have any lite UTXO node, and such node would not
> work properly beyond block 420000.
>
> With the softfork I described in my original post, if the UTXO is created
> within the last 420000 blocks, the key holder may consult any type of full
> node, including a lite UTXO node, to create the transaction.
>
> If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
> node obviously can't provide the necessary information to spend the coin.
> However, not even a full UTXO node may do so. A full UTXO node could tell
> the position of the UTXO in the blockchain, but can't provide all the
> information required by my specification. Only an archive node may do so.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
> It is not possible to construct the membership prove I require without
> these information. It is designed this way, so that lite UTXO nodes won't
> need to store any dormant UTXO records: not even the hash of individual
> dormant UTXO records. If the blockchain grows to insanely big, it may take
> days or weeks to retrieve to records. However, I don't think this is
> relevant as one has already left his coins dormant for >8 years. Actually,
> you don't even need the full blockchain. For (1), all you need is the
> 420000 blocks from Y to Y+420000 minus any witness data, as you don't need
> to do any validation. For (2), you just need the coinbase of Y+420001 to
> present, where any spending would have been committed, and retrieve the
> full block only if a spending is found.
>
> So the Bitcoin Bank (miners) is not going to shred your record and
> confiscate your money. Instead, the Bank throws your record to the garage
> (raw blockchain). You can search for your record by yourself, or employ
> someone (archive node) to search it for you. In any case it incurs costs.
> But as thousands of bankers have kept your record on their limited desk
> space for 8 years for free (though one of them might receive a fraction of
> a penny from you), you shouldn't complain with any moral, technical, or
> legal reason. And no matter what users say, I believe something like this
> will happen when miners and full nodes can't handle the UTXO set.
>
> I'd like to see more efficient proposals that archive the same goals.
>
> p.s. there were some typos in my original. The second sentence of the
> second paragraph should be read as "For every block X+420000, it will
> commit to a hash for all UTXOs generated in block X."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
> Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
> DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
> Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
> PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
> lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
> VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
> zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
> EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
> =2xRy
> -----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/20151213/67eaba28/attachment.html>

2023-06-07 15:40:21

- reply

📅 Original date posted:2015-06-28
📝 Original message:Then demonstrate it. He has been raising quite valid points over the
maintenance of bitcoin core.
This is the same problem as the changes to consensus rules in bitcoin
core: they aren't explicitly defined for the external audience. Thus
forcing people to lobby for hard forks.
2015-06-28 21:16 GMT+01:00 Mark Friedenbach <mark at friedenbach.org>:
> Milly you are absolutely wrong as has been pointed out by numerous people
> numerous times. Your idea of how bitcoin development decision making works
> is demonstrably false. Please stop filling our inboxes with trolling
> accusations, or else this will have to become a moderated list. And no one
> wants that.
>
> On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly at bitcoins.info> wrote:
>>
>> I really don't know who has power to do what behind the scenes. From what
>> i understand, if push comes to shove, it is under the ultimate control of
>> one person who can revoke commit privileges. Maybe I am wrong about that
>> but the point is most people don't know for sure.
>>
>> You are correct about the people having the choice to download but the
>> influence of the official release is way beyond the influence of any forked
>> release. What that means in the real world is an open question and would be
>> different depending upon the specific circumstances and difficult to
>> predict. It is significant power to have control over the official release
>> at the present time. If they did not have significant power people would
>> not spend significant efforts lobbying them to make changes. Any new
>> developers hired by companies will do so because they can influence over the
>> official release since that is the only incentive.
>>
>> It seems to me that this block size fork is only the beginning of the
>> issues that will arise over the coming years. Whatever powers the core
>> maintainers have it is going to be exploited one way or another as time goes
>> on. Maybe there are enough feedback mechanisms to protect against that, I
>> don't really know.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/28/2015 3:05 PM, Patrick Murck wrote:
>>
>> Wladimir has no more or less “power” to push change to the Bitcoin Core
>> codebase than any other person with commit privileges to the GitHub repo. If
>> I’m not mistaken there are 7 people with commit privileges and five of them
>> are active. If Wladimir committed a change it could be reverted by any of
>> the others. This is by design and ensures that changes will have reached
>> some level of technical consensus before they are merged, among other
>> things.
>>
>> Furthermore even assuming the Core Maintainer commits a change to Bitcoin
>> Core (that isn’t reverted and that gets packaged up into the next code
>> release) that still doesn’t push a change to the bitcoin network. There is
>> no auto-update on Bitcoin Core so individuals and companies running Bitcoin
>> Core software have to choose to upgrade. Further still, developers that
>> maintain alternative implementations would have to decide to merge those
>> changes to the codebase they are indepently maintaining (and their users
>> would need to update, etc.).
>>
>> I understand why it might *seem* to be the case that the Core Maintainer
>> is empowered to make changes to "teh Bitcoin" but the reality is that the
>> Core Maintainer role is really about cat herding and project management of
>> Bitcoin Core the open-source software project and not the bitcoin network.
>> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
>> the project moving forward.
>>
>> The process might get ugly and inefficient but that’s the cost of having
>> no wizard behind the curtain.
>>
>> -pm
>>
>> --
>> Patrick Murck
>>
>> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly at bitcoins.info) wrote:
>>
>> The core maintainer has always been in control of the consensus rules.
>> Satoshi came up with the rules and put them in there. Since then any
>> changes to any part of the code go through the core maintainer. It
>> looks to me as if people are saying it somehow changed along the way
>> because they don't want to hurt people's feeling, upset up, get them to
>> quit, etc. Sure there are checks and balances and people don't have to
>> use the main code base but if they change the consensus rules they are
>> incompatible.
>>
>> The notion that because people can download different rules and run them
>> is interesting from a theoretical perspective but that is constrained by
>> the network effect. I can say the US government is not the "decider" of
>> laws because I can vote them out, recall them, challenge things in
>> court, or secede and start my own country. You can also say the
>> judge/jury in a criminal court case is not a "decider" because the
>> president can always issue a pardon. But those points are generally not
>> useful in a practical sense.
>>
>> The issue about the developers is the tremendous influence they have to
>> veto any changes. I don't have veto power yet I have more bitcoins than
>> garzik says he has. The whole Bitcoin software development system is
>> subject to attack from just a couple of people who have this veto
>> power. With all the crying and moaning about centralization on this
>> list I would think that would be a concern.
>>
>> Russ
>>
>>
>>
>> On 6/28/2015 11:35 AM, Jorge Timón wrote:
>> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info>
>> > wrote:
>> >> I never said something was approved by garzik added something after it
>> >> was
>> >> opposed. What I said was a proposal was made and 4 people commented on
>> >> the
>> >> Github. He then tweeted there was near universal approval before most
>> >> people even heard about the subject. It was not controversial but i was
>> >> pointing out the arrogance of some of the developers. He considers the
>> >> entire universe of Bitcoin stakeholders to be a very small group of
>> >> insiders, not the entire universe of Bitcoin users. Another thing I
>> >> have
>> >> seen on Github for bitcoin.org is how some the maintainers change the
>> >> rules
>> >> on the fly. Sometimes they say a proposal had no objections so it is
>> >> approved. Other times they say a proposal has no support so it is
>> >> rejected.
>> > Ok, I misunderstood.
>> > Well, the fact is that the number of capable reviewers is quite small.
>> > If more companies hired and trained more developers to become bitcoin
>> > core developers that situation could change, but that's where we are
>> > now.
>> >
>> >> You are also trying to say that the core developers actually have
>> >> little
>> >> influence and are not "deciders" because anyone can fork the code. That
>> >> has
>> >> already been discussed at length and such an argument is faulty because
>> >> there is a constraint that your software is incompatible with everyone
>> >> else.
>> > Only if you change the consensus rules (which are, in fact, a
>> > relatively small part of the code).
>> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
>> > with the replace by fee policy, libbitcoin also changes many
>> > non-consensus things, there's code written in other languages...
>> > There's multiple counter-examples to your claim of that argument being
>> > faulty.
>> > Seriously, forking the project is just one click. You should try it
>> > out like at least 9627 other people have done.
>> > >From there, you can pay your own developers (if you don't know how to
>> > code yourself) and maybe they're also fine being insulted by you as
>> > part of the job.
>> > What you still can't do is unilaterally change the consensus rules of
>> > a running p2p consensus system, because you cannot force the current
>> > users to run any software they don't want to run.
>> >
>> >> The issue is that there is no way right now to change the consensus
>> >> rules
>> >> except to go through the core maintainer unless you get everybody on
>> >> the
>> >> network to switch to your fork. People who keep repeating that the
>> >> software
>> >> development is "decentralized because you fork the code" without
>> >> explaining
>> >> the constraints are just cultists.
>> > Please, stop the cultist crap. Maybe insulting people like that is how
>> > you got people to call you a troll.
>> > But, yes, you are right: there's no known mechanism for safely
>> > deploying controversial changes to the consensus rules
>> >
>> >> The discussion has nothing to do with who has the position now and I
>> >> never
>> >> said he has "control over the consensus rules." The maintainer has a
>> >> very
>> >> large influence way beyond anyone else. As for your claim that I want
>> >> someone hurt because I am explaining the process, that is ridiculous.
>> >> If
>> >> the Core maintainers did not have significant influence to change the
>> >> consensus rules then everybody would not be spending all this time
>> >> lobbying
>> >> them to have them changed.
>> > Well, if you don't think he has control over the consensus rules we're
>> > advancing.
>> > I think that was implied from some of your previous claims. He is no
>> > "decider" on consensus changes.
>> > Insisting on it can indeed get him hurt, so I'm happy that you're
>> > taking that back (or clarifying that really wasn't your position).
>> > Influence is very relative and not only core devs have "influence".
>> > Maybe Andreas Antonopolous has more "influence" than I have because he
>> > is a more public figure?
>> > Well, that's fine I think. I don't see the point in discussing who has
>> > how much influence.
>> >
>> >> The outside influences and stake of the developer is a relevant topic.
>> >> The
>> >> same types of things are discussed on this list all the time in the
>> >> context
>> >> of miners, users, merchants, and exchanges. Again, the developers try
>> >> to
>> >> place themselves on some kind of pedestal where they are the protectors
>> >> and
>> >> pure and everyone else (miners, users, merchants) are abusers,
>> >> spammers,
>> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made
>> >> an
>> >> issue of how many bitcoins he holds and he made that issue in the same
>> >> place
>> >> where he announces many of the technical issues. It is very relevant
>> >> that
>> >> he has a minimal stake in Bitcoin holdings yet he goes around making
>> >> major
>> >> decisions about Bitcoin and trying to dictate who is allowed to
>> >> participate
>> >> in discussions. If a core developer has minimal stake in Bitcoin yet
>> >> has
>> >> major veto power over code change that is a problem.
>> > Please, don't generalize. I don't think I put myself in any kind of
>> > pedestal.
>> > That is insulting to me and many others (you may not even know and
>> > you're insulting them).
>> > And I think my Bitcoin holdings are completely irrelevant when judging
>> > my contributions to the software: either they're good or not, and who
>> > I am or how many Bitcoins I have at any given time shouldn't matter.
>> > Again, nobody forces you to use our software, as said there's
>> > alternatives (including forking the project right now).
>> >
>> >> You are correct that you cannot give power to any person over the
>> >> Internet
>> >> which is why some kind of process needs to be developed that does not
>> >> involve trying to convince one person to make the changes or a system
>> >> that
>> >> depends on unwritten, ever-changing rules maintained by a handful of
>> >> people.
>> > Well, for now the process we have is seeking consensus, and although
>> > our definition of "uncontroversial" is very vague, I think it is quite
>> > obvious when a proposed change is not "uncontroversial" (like in the
>> > block size debate).
>> > It seems to me that any other "formal process" would imply
>> > centralization in the decision making of the consensus rules (and from
>> > there you only have to corrupt that centralized organization to
>> > destroy Bitcoin).
>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:36:11

- reply

📅 Original date posted:2015-06-01
📝 Original message:I've been following the discussion of the block size limit and IMO it
is clear that any constant block size limit is, as many have said
before, just kicking the can down the road.
My problem with the dynamic lower limit solution based on past blocks
is that it doesn't account for usage spikes. I would like to propose
another dynamic lower limit scheme:
Let the block size limit be a function of the number of current
transactions in the mempool. This way, bitcoin usage regulates the
block size limit.
I'm sorry i don't have the knowledge of the code base or time to make
simulations on this kind of approach, but nevertheless I would like to
leave it here for discussion or foster other ideas.
cheers

2023-06-07 15:35:59

- reply

📅 Original date posted:2015-05-31
📝 Original message:He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between the miners. If there is a difference in network speed, the
miner is incentivized to invest in their network infrastructure.
2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
> You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
> Did you just lie to Chun?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:35:59

- reply

📅 Original date posted:2015-05-31
📝 Original message:2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong at gmail.com>:
>
>
> On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe at gmail.com>
> wrote:
>>
>> He also said that the equation for miners has many variables, as it
>> should. There is no disadvantage if the network speed is the same
>> between the miners.
>
>
> Hi,
>
> Is that an assumption?
no, let me rephrase: The disadvantage alex refers to only exists if
miners do not have the same network speed.
>
>> If there is a difference in network speed, the
>> miner is incentivized to invest in their network infrastructure.
>
>
> Perhaps it's best not to assume that investing in Internet network
> infrastructure's a free or open market everywhere.
Just like easy ASIC access, low price electricity, etc are not a free
and open market.
>
> p.
>
>>
>>
>> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> >> Yes, if you are on a slow network then you are at a (slight)
>> >> disadvantage.
>> >> So?
>> >
>> >
>> > Chun mentioned that his pool is on a slow network, and thus bigger
>> > blocks
>> > give it an disadvantage. (Orphan rate is proportional to block size.)
>> > You said that no, on contrary those who make big blocks have a
>> > disadvantage.
>> > And now you say that yes, this disadvantage exist.
>> >
>> > Did you just lie to Chun?
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > 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:31:41

- reply

📅 Original date posted:2015-03-02
📝 Original message:As a researcher in a distributed systems group, it is awesome to see
these papers flocking up that help convince the supervisors to pay
more attention to blockchain technologies.
thanks for keeping us up to speed.
2015-03-02 16:48 GMT+00:00 Andrew Miller <amiller at cs.umd.edu>:
> We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten,
> Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have
> written a “systemization” paper about Bitcoin-related research. It’s
> going to appear in the Oakland security conference later this year
> (IEEE Security and Privacy) but we wanted to announce a draft to this
> community ahead of time.
>
> http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf
>
> One of the main goals of our work is to build a bridge between the
> computer science research community and the cryptocurrency community.
> Many of the most interesting ideas and proposals for Bitcoin come from
> this mailing list and forums/wikis/irc channels, where many academic
> researchers simply don’t know to look! In fact, we started out by
> scraping all the interesting posts/articles we could find and trying
> to figure out how we could organize them. We hope our paper helps some
> of the best ideas and research questions from the Bitcoin community
> bubble up and inspires researchers to build on them.
>
> We didn’t limit our scope to Bitcoin, but we also decided not to
> provide a complete survey of altcoins and other next-generation
> cryptocurrency designs. Instead, we tried to explain all the
> dimensions along which these designs differ from Bitcoin.
>
> This effort has roughly been in progress over two years, though it
> stopped and restarted several times along the way.
>
> If anyone has comments or suggestions, we still have a week before the
> final version is due, and regardless we plan to continue updating our
> online version for the forseeable future.
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Ricardo Filipe
GSD/INESC-ID Lisboa

2023-06-07 15:31:26

- reply

📅 Original date posted:2015-03-11
📝 Original message:i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in standards as our industries have in
the past...
2015-03-11 19:04 GMT+00:00 Jim <jim618 at fastmail.co.uk>:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
>
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
>
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
>
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
>
> --
> http://bitcoin-solutions.co.uk
>
> On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
>> Sigh. The wallet words system is turning into kind of a mess.
>>
>> I thought the word list is in fact not a fixed part of the spec, because
>> the entropy is a hash of the words. But perhaps I'm misunderstanding
>> something.
>>
>> The main problem regular SPV wallets have with BIP39 is that there is no
>> birth time included in the data. Therefore we must ask users to write down
>> a timestamp as well, so we know where to start rescanning the chain. It
>> sounds like the Electrum version doesn't fix this, so now we have at least
>> FIVE incompatible results from a 12 word list:
>>
>> - Electrum v2 with a version number but no date
>> - myTREZOR with no version and no date and BIP44 key derivation. Some
>> seeds I believe are now being generated with 24 words instead of 12.
>> - MultiBit HD with no version and a date in a custom form that creates
>> non-date-like codes you are expected to write down. I think BIP32 and BIP44
>> are both supported (sorta).
>> - GreenAddress with no version, no date and BIP32
>> - Other bitcoinj based wallets, with no version and a date written down
>> in normal human form, BIP32 only.
>>
>> I really hope we can recover from this somehow because otherwise all
>> wallets will have to provide the user with a complicated matrix of
>> possibilities and software combinations, and in practice many won't bother
>> so these word combinations will actually end up being wallet specific for
>> no particularly good reason, just very minor details like the presence or
>> absence of single fields.
>>
>> It feels like we somehow fell flat on our faces just before the finishing
>> line. This is deeply unfortunate. Compatibility and UX consistency is
>> important!
>>
>> Currently, I don't have any bright ideas for how to get everyone back onto
>> the same page with a fully compatible system that is acceptable to all. If
>> anyone else has suggestions, I'm all ears.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:18:30

- reply

📅 Original date posted:2014-04-10
📝 Original message:that's what blockchain pruning is all about :)
2014-04-10 17:47 GMT+01:00 Brian Hoffman <brianchoffman at gmail.com>:
> Looks like only about ~30% disk space savings so I see your point. Is there
> a critical reason why blocks couldn't be formed into "superblocks" that are
> chained together and nodes could serve a specific superblock, which could be
> pieced together from different nodes to get the full blockchain? This would
> allow participants with limited resources to serve full portions of the
> blockchain rather than limited pieces of the entire blockchain.
>
>
> On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
>>
>> Suggestions always welcome!
>>
>> The main problem with this is that the block chain is mostly random bytes
>> (hashes, keys) so it doesn't compress that well. It compresses a bit, but
>> not enough to change the fundamental physics.
>>
>> However, that does not mean the entire chain has to be stored on expensive
>> rotating platters. I've suggested that in some star trek future where the
>> chain really is gigantic, it could be stored on tape and spooled off at high
>> speed. Literally a direct DMA from tape drive to NIC. But we're not there
>> yet :)
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:41

- reply

📅 Original date posted:2014-04-07
📝 Original message:Or have blocks distributed through pruned nodes as a DHT.
2014-04-07 20:13 GMT+01:00 Mark Friedenbach <mark at monetize.io>:
>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:17:32

- reply

📅 Original date posted:2014-04-07
📝 Original message:phasing out of bitcoinqt into spv wallets?
2014-04-07 12:34 GMT+01:00 Mike Hearn <mike at plan99.net>:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people might stop running a node (uses too much
> disk space, bandwidth, lost interest etc). But does anyone have any idea how
> we might get more insight into what's really going on? It'd be convenient if
> the subVer contained the operating system, as then we could tell if the
> bleed was mostly from desktops/laptops (Windows/Mac), which would be
> expected, or from virtual servers (Linux), which would be more concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things you
> should know about. If we did the same, we could have a little exit survey:
> if your node disappears for long enough, we could email the operator and ask
> why they stopped.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:20

- reply

📅 Original date posted:2014-04-07
📝 Original message:2014-04-07 21:08 GMT+01:00 Troy Benjegerdes <hozer at hozed.org>:
> I have to play dissenter here again..
>
> Using a bitcoin address as a persistent identity key is the first real-world
> use of Bitcoin that I can imagine will make it a 'killer app' that everyone
> and their grandma will want to use.
>
I am of the same opinion, although i understand Gavin's point. Would
the multisig seed work for this purpose?
I have been toying with this idea and I think that for this BIP to
make sense it would require a "root" key as your login. Then if you
need to make transfers the system would request you to create and
associate a new key to your account for each purchase (signing the new
key with the root one for example).

2023-06-07 15:17:01

- reply

📅 Original date posted:2014-04-02
📝 Original message:Kevin,
the thing is you gave us a bad link... what is the correct URL of your project?
2014-04-02 16:30 GMT+01:00 Kevin <kevinsisco61784 at gmail.com>:
> On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
>> Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special?
>>
>> On Apr 2, 2014, at 2:53 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>
>>> On 4/2/2014 9:08 AM, Jeff Garzik wrote:
>>>> At first, this is a poor choice of URL.
>>>>
>>>> But it really looks like a phishing attempt that no one should visit.
>>>>
>>>>
>>>> On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>>> I've sat on this for some time after starting this. I have forked this
>>>>> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
>>>>> is written in Autoit. I know I know, scripting language alert! I would
>>>>> like people to look at:
>>>>> http://www.githubb.com/bitcoin/bitcoin
>>>>> Look at it, and let's have an open dialog about it. I want to know the
>>>>> good, the bad, and the ugly!
>>>>>
>>>>> --
>>>>> Kevin
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>> As far as choice of U R L, it may be a poor choice but I did this
>>> because I wanted it connected with the core. As far as fishing it
>>> certainly is not that! This is a serious project.
>>>
>>>
>>> --
>>> Kevin
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> I tell you that this is a serious project for bitcoin. You are free to
> assume the worst. After all, I did say the good the bad and the ugly
> would come out of this. I happen to be a big believer in bitcoin and I
> feel this project holds water. If you disagree, that's fine.
>
>
> --
> Kevin
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:16:07

- reply

📅 Original date posted:2014-03-25
📝 Original message:2014-03-25 13:49 GMT+00:00 Peter Todd <pete at petertodd.org>:
> On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
>> On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>>
>> > Bitcoin doesn't scale. There's a lot of issues at hand here, but the
>> > most fundemental of them is that to create a block you need to update
>> > the state of the UTXO set, and the way Bitcoin is designed means that
>> > updating that state requires bandwidth equal to all the transaction
>> > volume to keep up with the changes to what set. Long story short, we get
>> > O(n^2) scaling, which is just plain infeasible.
>> >
>>
>> We have a fundamental disagreement here.
>>
>> If you go back and read Satoshi's original thoughts on scaling, it is clear
>> that he imagined tens of thousands of mining nodes and hundreds of millions
>> of lightweight SPV users.
>
> Yeah, about that...
>
> https://blockchain.info/pools
>
On-topic:
This argument is quite the fallacy. The only reason we have that few
pools is because each of their miners doesn't find it feasible to mine
"on their own". if you count the individual miners on those pools you
will get to the scale Gavin was trying to point out.
Nevertheless i think that is just a minor disagreement, since tree
chains help decentralization.
> For someone with 'Chief Scientist' as their job title, I'm surprised you
> think so little of hard evidence and so much of idol worshipping.
>
>
> P.S. A year or so ago you complained that if I cared so much about
> decentralization, I should make P2Pool better. Your homework: What do
> tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do
> with that? What about the cube-square law? And why don't I think TXO
> commitments solve the blocksize problem?
>
> 1) https://bitcointalk.org/index.php?topic=309073.0;all
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000020366a15799010ae0432be831c197e06b19133028a9aa6f3
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:15:29

- reply

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

2023-06-07 15:01:12

- reply

📅 Original date posted:2013-05-16
📝 Original message:Of course.
My proposal was just for the pruned nodes.
I.e. You would have a majority (maybe not even a majority required) of
nodes storing the whole blockchain and pruned nodes would store
"random" parts of the blockchain, according to the resources they
have, which would be organized as a DHT.
2013/5/16 Jeff Garzik <jgarzik at exmulti.com>:
> On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe
> <ricardojdfilipe at gmail.com> wrote:
>> We would only end up with few copies of the historic data if users
>> could choose what parts of the blockchain to store. Simply store
>> chunks randomly, according to users available space, and give priority
>> to the "N most recent" chunks to have more replicas in the network.
>>
>> You don't need bittorrent specifically for a DHT, if publicity is a
>> problem. There are many DHT proposals and implementations, and i bet
>> one of them should be more suitable to the bitcoin network than
>> bittorrent's.
>
> That's just about the worst thing you could do for bitcoin. DoS one
> part of the DHT, you DoS the entire blockchain by breaking the chain.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com

2023-06-07 15:01:11

- reply

📅 Original date posted:2013-05-16
📝 Original message:We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the "N most recent" chunks to have more replicas in the network.
You don't need bittorrent specifically for a DHT, if publicity is a
problem. There are many DHT proposals and implementations, and i bet
one of them should be more suitable to the bitcoin network than
bittorrent's.
>On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn <mike at ...> wrote:
>> I'd imagined that nodes would be able to pick their own ranges to keep
>> rather than have fixed chosen intervals. "Everything or two weeks" is rather
>
>X most recent is special for two reasons: It meshes well with actual demand,
>and the data is required for reorganization.
>
>So whatever we do for historic data, N most recent should be treated specially.
>
>But I also agree that its important that <everything> be splittable into ranges
>because otherwise when having to choose between serving historic data
>and— say— 40 GB storage, a great many are going to choose not to serve
>historic data... and so nodes may be willing to contribute 4-39 GB storage
>to the network there will be no good way for them to do so and we may end
>up with too few copies of the historic data available.
>
>As can be seen in the graph, once you get past the most recent 4000
>blocks the probability is fairly uniform... so "N most recent" is not a
>good way to divide load for the older blocks. But simple ranges— perhaps
>quantized to groups of 100 or 1000 blocks or something— would work fine.
>
>This doesn't have to come in the first cut, however— and it needs new
>addr messages in any case.