<unnamed>

Public Key

npub18unhg43arsfv864rhmsdr2w28lmqcc65025rrvquq6wslrfharrsezct0n

Profile Code

nprofile1qqsr7fm52c73cykra23macx3489rlasvvd2842p3kqwqd8g035m733cpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mq55lf3z

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:33:14 UTC

- 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 UTC

- 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 10:30:11 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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>