Matthew Mitchell [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 15:33:14

- reply

📅 Original date posted:2015-05-07
📝 Original message:One thing to add is that perhaps in a future version of Bitcoin Core,
there could be an option for users to continue using the old consensus
rules, or an option to support the new rules (an option when they update
and an ability to change in the settings). Both types of user can
benefit from the software updates and choose with a single piece of
software what they support. Information for whether or not a user is
supporting the changes could be included in the version message.
Possibly this information could be incorporated into transactions also.
If they wish to support the new rules, then their client would support
larger blocks when there is majority miner consensus, otherwise their
clients will always only support the old rules.
This way the decision is not being forced upon the user in any way.
Just an idea.
On 07/05/15 16:58, Matthew Mitchell wrote:
> In my personal opinion, this does make some sense to me, assuming I
> understood Gavin.
>
> I suppose it could be done with a new flag (like the P2SH flag) which
> displays miner support for larger blocks. The new rules would apply when
> a large majority of miners support the new rules by counting the number
> of flagged blocks over a certain number of blocks on the network in a
> deterministic fashion.
>
> This way miners can continue to produce blocks which are supported by
> both old and new clients. When it appears most people have migrated to
> the new client, miners can start flagging support for the new rules, and
> when a large majority of miners agree, the new rules would kick in for
> all miners/clients running the new software. Miners could therefore glue
> together the network during the migration phase until enough people have
> updated to avoid severe fork scenarios. The only problem is ensuring
> that miners will continue to support both networks for long enough to
> enable successful migration.
>
> And if too many people disagree to make a clean hard fork (too many
> people stubbornly stick to the old rules), then it could be that the
> hard fork is aborted and everyone goes back to the old rules, or quite
> simply that the miners never give support for the new rules despite the
> mechanism being included in the new client. In those cases it would be
> as if nothing changed.
>
> This way the hard fork would be determined by user participation as
> judged by the miners.
>
> If it is done, I can't think of a fairer way.
>
> Matthew Mitchell
>
> On 07/05/15 15:52, Gavin Andresen wrote:
>> For reference: the blog post that (re)-started this debate, and which
>> links to individual issues, is here:
>> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>>
>> In it, I asked people to email me objections I might have missed. I
>> would still appreciate it if people do that; it is impossible to keep up
>> with this mailing list, /r/bitcoin posts and comments, and
>> #bitcoin-wizards and also have time to respond thoughtfully to the
>> objections raised.
>>
>> I would very much like to find some concrete course of action that we
>> can come to consensus on. Some compromise so we can tell entrepreneurs
>> "THIS is how much transaction volume the main Bitcoin blockchain will be
>> able to support over the next eleven years."
>>
>> I've been pretty clear on what I think is a reasonable compromise (a
>> one-time increase scheduled for early next year), and I have tried to
>> explain why I think it it is the right set of tradeoffs.
>>
>> There ARE tradeoffs here, and the hard question is what process do we
>> use to decide those tradeoffs? How do we come to consensus? Is it worth
>> my time to spend hours responding thoughtfully to every new objection
>> raised here, or will the same thing happen that happened last year and
>> the year before-- everybody eventually gets tired of arguing
>> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>>
>> I AM considering contributing some version of the bigger blocksize-limit
>> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist
>> with a fast Internet connection, and assume Nelson's law to increase
>> over time), and then encouraging merchants and exchanges and web wallets
>> and individuals who think it strikes a reasonable balance to run it.
>>
>> And then, assuming it became a super-majority of nodes on the network,
>> encourage miners to roll out a soft-fork to start producing bigger
>> blocks and eventually trigger the hard fork.
>>
>> Because ultimately consensus comes down to what software people choose
>> to run.
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/97e8772e/attachment.sig>

2023-06-07 15:33:14

- reply

📅 Original date posted:2015-05-07
📝 Original message:In my personal opinion, this does make some sense to me, assuming I
understood Gavin.
I suppose it could be done with a new flag (like the P2SH flag) which
displays miner support for larger blocks. The new rules would apply when
a large majority of miners support the new rules by counting the number
of flagged blocks over a certain number of blocks on the network in a
deterministic fashion.
This way miners can continue to produce blocks which are supported by
both old and new clients. When it appears most people have migrated to
the new client, miners can start flagging support for the new rules, and
when a large majority of miners agree, the new rules would kick in for
all miners/clients running the new software. Miners could therefore glue
together the network during the migration phase until enough people have
updated to avoid severe fork scenarios. The only problem is ensuring
that miners will continue to support both networks for long enough to
enable successful migration.
And if too many people disagree to make a clean hard fork (too many
people stubbornly stick to the old rules), then it could be that the
hard fork is aborted and everyone goes back to the old rules, or quite
simply that the miners never give support for the new rules despite the
mechanism being included in the new client. In those cases it would be
as if nothing changed.
This way the hard fork would be determined by user participation as
judged by the miners.
If it is done, I can't think of a fairer way.
Matthew Mitchell
On 07/05/15 15:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email me objections I might have missed. I
> would still appreciate it if people do that; it is impossible to keep up
> with this mailing list, /r/bitcoin posts and comments, and
> #bitcoin-wizards and also have time to respond thoughtfully to the
> objections raised.
>
> I would very much like to find some concrete course of action that we
> can come to consensus on. Some compromise so we can tell entrepreneurs
> "THIS is how much transaction volume the main Bitcoin blockchain will be
> able to support over the next eleven years."
>
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
>
> There ARE tradeoffs here, and the hard question is what process do we
> use to decide those tradeoffs? How do we come to consensus? Is it worth
> my time to spend hours responding thoughtfully to every new objection
> raised here, or will the same thing happen that happened last year and
> the year before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist
> with a fast Internet connection, and assume Nelson's law to increase
> over time), and then encouraging merchants and exchanges and web wallets
> and individuals who think it strikes a reasonable balance to run it.
>
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger
> blocks and eventually trigger the hard fork.
>
> Because ultimately consensus comes down to what software people choose
> to run.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/733b3667/attachment.sig>

2023-06-07 15:06:46

- reply

📅 Original date posted:2013-09-12
📝 Original message:I removed some more but I haven't added enough back in. It was taking far longer than expected so I gave up, but maybe someone else can try to add some more:
https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt
On 12 Sep 2013, at 13:11, Pavol Rusnak <stick at gk2.sk> wrote:
> On 10/09/13 23:03, Matthew Mitchell wrote:
>> Maybe it would have been better without the aggressive words?
>
> I revisited the wordlist and replaced around 67 words that can be
> found offensive in some context.
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick at gk2.sk>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130912/b6da8674/attachment.sig>

2023-06-07 15:06:44

- reply

📅 Original date posted:2013-09-10
📝 Original message:Well let's hope something like "murder black people", "stupid asian person" or "whip african slave" doesn't come up. :-) Maybe it would have been better without the aggressive words?
Matthew
On 10 Sep 2013, at 21:50, slush <slush at centrum.cz> wrote:
> In many iterations of editing the wordlist we made our best to pick
> words which are easy to remember, still "neutral". Unfortunately it's
> almost impossible to exclude some words which may together create
> negative co-notations.
>
> Thankfully we removed all racist and religious words so I believe all
> three authors mentioned in the BIP are safe against fundamentalist
> bitcoin users :-).
>
> slush
>
> On 9/10/13, Matthew Mitchell <matthewmitchell at godofgod.co.uk> wrote:
>> I like this, though maybe sometimes you'll get rude word combinations come
>> out.
>>
>> Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130910/c70bd147/attachment.sig>

2023-06-07 15:06:44

- reply

📅 Original date posted:2013-09-10
📝 Original message:I like this, though maybe sometimes you'll get rude word combinations come out.
Matthew
On 10 Sep 2013, at 17:44, slush <slush at centrum.cz> wrote:
> Hi all,
>
> we just finalized the draft and reference implementation of BIP39. Regards to rules in BIP0001 we're asking for comments.
>
> The aim of the proposal is to standardize algorithm across various clients and fix some design problems of existing (but not yet standardized) Electrum mnemonic algorithm.
>
> BIP39 is a nice complement to BIP32, which allow users to (paper) backup and share their wallet accross multiple clients easily.
>
> Link to BIP: https://en.bitcoin.it/wiki/BIP_0039
>
> Thanks for your time,
> slush
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk_______________________________________________
> 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/20130910/65e42e3e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130910/65e42e3e/attachment.sig>

2023-06-07 10:30:42

- reply

📅 Original date posted:2012-09-10
📝 Original message:Almost forgot...
Begin forwarded message:
> From: Matthew Mitchell <matthewmitchell at godofgod.co.uk>
> Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
> Date: 10 September 2012 16:23:45 BST
> To: Gregory Maxwell <gmaxwell at gmail.com>
>
> By "gettreelevel" and "treelevel" you get the level of the merle tree with the hashes for the segments you want to download. You could request all the transaction hashes by specifying a very deep level. You could modify the proposal by removing the "level" byte in "gettreelevel" and always send the deepest level ie. The transaction hashes. Though by specifying the level you do not need to download all of the transaction hashes, only the hashes you need to verify each segment.
>
>
> On 10 Sep 2012, at 16:14, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>>
>> Why does this focus on actually sending the hash tree? The block
>> header + transaction list + transactions a node doesn't already know
>> (often just the coinbase) is enough.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120910/6bd57c32/attachment.html>

2023-06-07 10:30:37

- reply

📅 Original date posted:2012-09-13
📝 Original message:On 13 Sep 2012, at 19:59, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> You want to parallellize block downloads, while at the same time preventing re-download of transactions that are already known.
> To do so, a requesting node would first request (for example) the 8 level-3 hashes, then start 8 parallel threads to download the
> transactions from presumably 8 different peers. Each thread then fetches the transaction id's that correspond to its own 1/8th of
> the block, and requests the transactions whose txid is not yet known.
> Comparing this with Gregory's own suggestion (just fetch the entire txid list at first, and then (again as parallellized as needed)
> fetch the unknown transactions from several peers), this does indeed have an advantage: you need to download (relatively) far less
> data before the threaded part can start. If this is what you propose, it is certainly meaningful, but the gains aren't very large,
> in my opinion.
This is not fully correct. I propose downloading the roots of the segments when you are not looking to remove redundant transaction downloads. This would be the case when the node is not up-to-date and is unlikely to have transactions in the required blocks. When a node is up-to-date and can benefit from removing redundant transaction downloads it can switch to downloading all the transactions hashes by specifying a high level number. Also I wouldn't recommend using one thread per connection, I'd recommend using one thread for all connections.
> However, my impression while reading your proposal was at times that you intend to process the different layers of the
> Merkle tree iteratively after starting the initial parallel segments. I don't think that is useful, as you'll need the actual
> txids anyway before deciding whether they need to be downloaded at all, it adds several round-trips, and once you have downloaded
> the intermediate merkle hashes for about 8 levels, you've already transferred more data than the transactions themselves. I think
> Gregory also assumed something like this, making him question why it's useful. Anyway, this whole paragraph is one assumption, so
> if it's not the case, ignore me.
This isn't what I was suggesting. I was suggesting you only need to download one level. Once you have done that you verify everything for the hashes on that level.
>
> Can you clarify what you mean? Preferably by giving a concrete sequence of exchanged messages, with a given purpose?
Well you will need to ask for the headers first. Once you do that you can start downloading the full blocks for the headers. The node should use "get blocks" to find nodes with segments of the blocks they need. Now for each block:
1. Send getsiginv to a number of peers to know the segments of the blocks they have.
2. Send gettreelevel requesting a level of the merkle tree from a peer that can provide it. When up-to-date use a high level to get the transaction hashes to find redundant data.
3. Validate the treelevel response
4. Send getsegment for each segment wanted (at the same time where possible) to the peers that have these segments. Skip transactions already known.
5. Validate the transactions in each segment received. Stop if the block is invalid and disconnect peers that give transactions which do not fit the merkle tree.
6. Revert to getdata if peers using the protocol cannot satisfy the block download.
When a valid block segment is received, include the block in inv and headers messages for other peers using the protocol. Thus relaying can begin before the entire block is downloaded.
I'm thinking about improvements to this proposal. I'll get to that tomorrow perhaps…
Thank you everyone for the replies.

2023-06-07 10:30:31

- reply

📅 Original date posted:2012-09-13
📝 Original message:On 13 Sep 2012, at 16:51, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> I thoroughly understand the value of tree hashes. That wasn't what I
> was asking about.
>
> If you're validating a block you need all the transactions, once you
> have them or their hashes you can build the tree without transferring
> more, e.g. what a fully validating node needs. If you're checking a
> single transaction to need the path from the transaction to the root
> (what a SPV nodes need, for example).
>
> Can you spell out the 'end user'ish application for fetching a tree level?
A merkle tree root is found by hashing the two children together and those children are found the same way until you get to the greatest level down the tree. This means you can validate children as being correct as long as they hash together to form the root. This means you do not need all the transaction hashes to validate segments of the block, you only need the root hashes for all the segments you want. Let's say there are 8 transactions and you want to verify 4 segments (2 transactions each), The merkle tree looks like this (Might not work depending on the font):
Level 0: *
/ \
/ \
/ \
/ \
/ \
/ \
/ \
Level 1: * *
/ \ / \
/ \ / \
/ \ / \
Level 2: * * * *
/ \ / \ / \ / \
Level 3: * * * * * * * *
When you look at any non-leaf node you can see a separate merkle tree where the root can be found exactly the same as any other merkle tree. In this example you want four segments, so you ask for level 2. Now imagine a tree without level 3, you can validate the root with level 2. In fact you can validate that the root exists for any level. So you first check that the level 2 hashes do indeed calculate to the root. Once this is done you can now use these hashes to validate the segments. When you receive a segment, you check that segment against the segment's root. So you've validated the segment transactions for the segment root and the segment root was validated for the entire tree's root. You validate the segments for each segment root and this way you know all the transactions are valid for the four segments and thus are valid for the entire tree. This way you have downloaded 4 hashes instead of 8.
Downloading the transactions hashes are therefore not necessary only the level for the segment roots. You might for instance want to divide the block into two segments in which case you ask for level 1 and download 2 hashes.
I hope that made sense.
And yes the merkle tree is particularly useful for validating a single transaction exists in a block as that saves a large proportion of the data required. The redundant data removed in the proposal here is smaller as a proportion of the total data (Because most of the data is the actual transactions themselves), so you might argue it's not worth it but it's simple to implement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120913/5e035fd4/attachment.html>

2023-06-07 10:30:27

- reply

📅 Original date posted:2012-09-13
📝 Original message:On 13 Sep 2012, at 16:16, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Sorry, I'm still not seeing what the value is. How is the tree level
> useful to anyone? If you did want to get only parts of the
> transaction list, why not just ranges from the lowest level?
Obtaining a particular tree level allows you to verify segments without needing to download all the transaction hashes first. You only need one hash per segment. For instance if you want to divide the block into 8 segments you specify level 3 and download 8 hashes. You could download all transaction hashes if you wanted and it would still work, it just requires more data transfer for the hashes. This was the reason why merkle trees were used in bitcoin, to avoid requiring all hashes to verify data.

2023-06-07 10:30:21

- reply

📅 Original date posted:2012-09-13
📝 Original message:On 13 Sep 2012, at 09:42, Mike Hearn <mike at plan99.net> wrote:
> For what it's worth I disagree with Gregory on nearly all these
> points, so don't take it as some kind of consensus from the Bitcoin
> community ;)
>
> Matts change is reasonable but I think we all agree it has minimal
> impact at the moment relative to other things, so something even more
> complex than that seems like a non-starter. Bloom filtering is a lot
> more important.
Sure other things may be done before this, I was seeing this as a change somewhere down the line but not urgent.
@Gregory
> But you only need to request the transactions you don't have. Most of
> time you should already have almost all of the transactions.
Yes, my proposal allows you to do this. You skip out transactions your already have. My proposal is simply better than others because it takes full advantage of the merkle tree structure with minor additions that are simple to implement. How hard is it to get the hashes at a particular level of a merkle tree? Not hard at all. How hard is it to place a selection of transactions from a block into a message Not hard at all. Implementation of the protocol requirements would be a piece of cake. The harder bit would be to create an algorithm to determine the best level of segmentation but this is not required to comply with the protocol.
> Because there is no motivation not to set them to zero, if you don't
> someone else will
The motivation to incentivise miners and maintain stronger security? The difficulty only has to be high enough to prevent a cartel of malicious miners taking control of the network, something that is potentially a problem today with the large mining pools. Remember that the more transactions there are the more fees there can be for miners to collect. The more people that are using bitcoin, the greater bitcoins will be worth. A bigger network should be good for miners when relying on fees.
> And yes, of course, you schedule the change
> for the future, but as you note that it doesn't solve the problem of
> people opposing it.
If it's so controversial that it creates a split making two separated currencies then I'd see it turning out like the format wars (VHS vs Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one or the other since it's better for people to have universalised agreement on a system.

2023-06-07 10:30:11

- reply

📅 Original date posted:2012-09-11
📝 Original message:On 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Someone can do that just by pipelining the one at a time requests.
> How much bandwidth do you think you could save over that?
You wouldn't need to pipeline the requests, just place more than one inventory vector in get data, right? Well my messages would save the space of those inventory vectors. Instead of needing 36 byte inventory vectors for each transaction and a var int, you would need two var ints only. And then the transaction responses only need one header, so you save 24 bytes for each transaction after the first. You could say that is a small benefit.
> I don't see what value this provides. For protecting against the
> future you might as well suggest uploading x86 code which gets
> executed to select transactions. "Protects against the future". Can
> you clarify some more about exactly how you think it would help?
Well it depends on wether you seriously think bitcoin blocks should be limited at a million bytes or not.
> it's not clear to me how your proposal is really all that useful for
> very large blocks: I looks like it would lot of bytes sending
> redundant tree data.
Look at bittorrent. With bittorrent you don't download files from a single peer all at once.
> Bitcoin gets its value through scarcity. There are two kinds of
> scarcity that are economically important, scarcity of the coins— there
> will never be more than 21 million— and scarcity of the block space
> which, as the protocol is defined and enforced by every node can not
> be more than 1MB. The latter scarcity is what makes the security model
> economically sane.
Why wouldn't requesting minimum fees in the software work as is done currently?
> Fortunately, its perfectly possible to make transactions denominated
> in bitcoin outside of the blockchain, and in a secure and distributed
> manner that respects the principles that make bitcoin attractive, but
> with information hiding that improves privacy, transaction speed, and
> scalability. See, e.g. the good work being done by Open transactions
> to create distributed cryptographic banks. So blockchain scarcity
> itself doesn't prevent Bitcoin from being a one world currency
> (something which isn't at all sane no matter how big you make the
> blocks if you don't allow for other modes of transaction processing—
> who the heck wants to possibly wait an hour to get a 1 confirm
> sodapop??).
So what you essentially suggest is having bitcoin banks that maintain trust through Open Transaction contracts which contains proof of agreement, providing some legal protection? One wonders why have bitcoin at all then? Why not have an elaborate e-money system between several banks using Open Transactions? Bitcoin doesn't just contain proof of if something was done right or not, it contains actual certainty that it will be done right. And how does Open Transactions prevent fractional reserve fraud?
I suppose when people consider bitcoin banks, they will consider bitcoin being useless.
> but I know that changing it is precisely as
> technically difficult as changing the 21 million limit
Set the change to occur at some block in the future leaving time for people to upgrade. Send out alert messages to notify users to upgrade. Issue is, some people might not like the change for whatever reasons.
As far as I see it, if bitcoin won't scale, then it's worth looking at something different to bitcoin that will scale.

2023-06-07 10:30:05

- reply

📅 Original date posted:2012-09-11
📝 Original message:For some reason sourceforge is not sending me updates anymore but I can see the replies online…
There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then download the transactions separately. However there are two problems:
1. Downloading all the transactions individually might be inefficient. My proposal will allow nodes to request multiple transactions at once.
2. Why not add a few additional components to the protocol to allow requests for any level of the merkle tree? It's not very complicated at all and protects against the future.
Sure, analysis needs to be done to see at what point the proposal would give benefit and I will hopefully get around to doing some measurements of peer behaviour to aid with this.
I think it's a good idea to think ahead rather than only do what is beneficial for the network currently. The block sizes at the moment are about 0.1MB but what if the bitcoin demand starts pushing that into megabytes? And yes the ~0.95MB limit needs to be changed in order for bitcoin to grow that far. Why would the limit not be lifted? How will bitcoin demand be satisfied other than having large fees to deter transactions, hoping the fees are large enough to balance the demand with the block size limits to prevent many transactions being unconfirmed and annoying users? That limit has got to go eventually. And then it could be that block sizes do become large enough to worry about the performance in relaying.
Best not to leave this to the last minute, so at the very least I think it's good to talk about this.

2023-06-07 10:29:55

- reply

📅 Original date posted:2012-09-10
📝 Original message:Do you mean getdata? Here is the reason for the 6 new messages:
getseginv,seginv - These are for learning about what segments of a block a node has. Else you could remove these messages and simply have nodes advertise blocks via inventory messages. In this case nodes would have to wait until they had fully received a block before relaying anything. No longer is there a benefit with nodes being able to relay segments of blocks before they have received the entire block.
gettreelevel,treelevel - These are to received a level of the merle tree. Instead you might use get data but gettreelevel is more compact than get data and is clearly differentiates itself as part of the new protocol. Perhaps these messages could include the block headers alongside the hashes and you could request many at once like with the getheaders message? If you skip these messages, then you could verify the transactions at the end but there would be problems when peers give bad segments where data would need to be downloaded again.
getsegment,segment - These are clearly important to request and receive segments for the blocks. These allows for nodes to download arbitrary segments of blocks. The optimum number of segments could be calculated by node software using measurements of download speeds and latency times, the number of connections and how likely redundancy is to occur. If a node is up-to-date and likely has many of the transactions in blocks, it can start asking for the deepest merle level (tx hashes) and ask nodes for segments, avoiding transactions it already has.
I'll get around to doing measurements myself sometime to estimate the benefit of this proposal. It will certainly be beneficial when block sizes reach some size but not much is really known except what can be assumed/guessed.
I should also mention the bitcointalk topic here: https://bitcointalk.org/index.php?topic=103295.0
On 10 Sep 2012, at 19:59, "Luke-Jr" <luke at dashjr.org> wrote:
>
> Most of the problem with block propagation lies in implementation, not
> protocol... Distributing missing transaction on an as-needed basis is a
> possible improvement at the protocol level, but there hasn't (AFAIK) been any
> research into whether the little benefit outweighs the cost yet. In any case,
> I don't see why 6 new messages are needed instead of simply adding a single
> new type to getinv?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120910/ea129c44/attachment.html>

2023-06-07 10:29:43

- reply

📅 Original date posted:2012-09-10
📝 Original message:Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.
https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal
Matthew Mitchell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120910/053635ab/attachment.html>