Chris Riley [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-05-10 to 2022-04-27
💬 Posted a total of 9 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:08:23

- reply

📅 Original date posted:2022-04-27
📝 Original message:>> we should not let the wealthy make consensus decisions.
>We shouldn't let the wealthy continue to control our governments. However,
bitcoin is not a government. Its a financial network.
>The fact of the matter is that fundamentally, the economic majority
controls where the chain goes. Its very likely that the wealthy
>are disproportionately represented in the economic majority. Attempting to
subvert the economic majority seems like a bad idea.
>The reality of control there will come out one way or another, and being
honest about it is probably the best way to avoid major schisms in the
future.
Yes, the economic majority is important: Who else has more incentive to
protect the security and thus the value embodied in the network than people
who have invested money and time in the network? A group of people with
1/10/100/1000 bitcoins each has more economic incentive to do so than a
similar sized group with 1/10/100/1000 satoshis each. Likewise, it is
significantly easier to mobilize 1 million people "voting" with 100
satoshis each - a total of 1 BTC - vs 10000 people each voting with 100
bitcoins each - a total of 1 million BTC. I don't think anyone would say
that even if those 1 million people, for example, thought that we should
increase the number of bitcoins via perpetual inflation it would be a good
idea to listen to it however the vote was done whether via transaction
flags or something else. Of course they could fork off.
Cheers, :-)
Chris
On Wed, Apr 27, 2022 at 4:11 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
>
> I feel like I've heard this idea somewhere before. Its an interesting
> idea.
>
> It should be noted that there is a consequence of this: holders wouldn't
> have much say. People that transact a lot (or happen to be transacting a
> lot during the signaling time period) would have a very disproportionate
> ability to pressure miners than people who aren't transacting much. This
> would probably be a pretty good proxy for future mining revenue that
> supports (or is against) a particular thing. However, the network does do
> more than just transact, so I would be a bit worried that such a mechanism
> would bias the system towards things that are good for transactors and bad
> for holders. Things like more coin inflation, larger blocks, etc.
>
> Another consideration is that miners are already incentivized to follow
> the money here. Adding an *additional* incentive might be distorting the
> market, so to speak.
>
> An alternative I proposed was a way to do weighted polling of holders:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html
>
> The polling wouldn't be directly connected to the activation mechanism in
> any way, but would just be a mechanism to gauge some portion of consensus.
> If enough people were involved, theoretically it could be hooked up to
> activation, but I would be pretty wary of doing that directly as well.
>
> > we should not let the wealthy make consensus decisions.
>
> We shouldn't let the wealthy continue to control our governments. However,
> bitcoin is not a government. Its a financial network. The fact of the
> matter is that fundamentally, the economic majority controls where the
> chain goes. Its very likely that the wealthy are disproportionately
> represented in the economic majority. Attempting to subvert the economic
> majority seems like a bad idea. The reality of control there will come out
> one way or another, and being honest about it is probably the best way to
> avoid major schisms in the future.
>
> > Does a scheme like this afford us a better view into consensus than we
> have today?
>
> It does more than provide a view. It directly changes the game theory
> around how activation works. If we wanted to simply get a better view into
> consensus, we could allow the same thing, but allow any block to mine any
> transaction regardless of transaction signaling. Then it would be more
> purely informational.
>
> > Can it be gamed to give us a *worse* view into consensus? How?
> > Does it measure the right thing? If not, what do you think is the right
> thing to measure?
>
> Doesn't seem like it could be gamed, but as I mentioned above, the honest
> mechanics of it might be themselves undesirably distorting.
>
>
>
> On Tue, Apr 26, 2022 at 3:49 PM Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> You may be interested in these posts on transaction signalling:
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html
>>
>>
>> On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Alongside the debate with CTV right now there's a second debate that was
>>> not fully hashed out in the activation of Taproot. There is a lot of
>>> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
>>> etc. A significant reason for the breakdown in civility around this debate
>>> is that because we don't have a means of measuring user support for
>>> proposed sof-fork changes, it invariably devolves into people claiming that
>>> their circles support/reject a proposal, AND that their circles are more
>>> broadly representative of the set of Bitcoin users as a whole.
>>>
>>> It seems everyone in this forum has at one point or another said "I
>>> would support activation of ____ if there was consensus on it, but there
>>> isn't". This statement, in order to be true, requires that there exist a
>>> set of conditions that would convince you that there is consensus. People
>>> have tried to dodge this question by saying "it's obvious", but the reality
>>> is that it fundamentally isn't. My bubble has a different "obvious" answer
>>> than any of yours.
>>>
>>> Secondly, due to the trauma of the block size wars, no one wants to
>>> utter a statement that could imply that miners have any influence over what
>>> rulesets get activated or don't. As such "miner signaling" is consistently
>>> devalued as a signal for market demand. I don't think this is reasonable
>>> since following the events of '17 miners are aware that they have the
>>> strong incentive that they understand market demand. Nevertheless, as it
>>> stands right now the only signal we have to work with is miner signaling,
>>> which I think is rightly frustrating to a lot of people.
>>>
>>> So how can we measure User Support for a proposed rule change?
>>>
>>> I've had this idea floating around in the back of my head for a while,
>>> and I'd like to solicit some feedback here. Currently, all forms of
>>> activation that are under consideration involve miner signaling in one form
>>> or another. What if we could make it such that users could more directly
>>> pressure miners to act on their behalf? After all, if miners are but the
>>> humble servants of user demands, this should be in alignment with how
>>> people want Bitcoin to behave.
>>>
>>> Currently, the only means users have of influencing miner decisions are
>>> A. rejection of blocks that don't follow rules and B. paying fees for
>>> transaction inclusion. I suggest we combine these in such a way that
>>> transactions themselves can signal for upgrade. I believe (though am not
>>> certain) that there are "free" bits in the version field of a transaction
>>> that are presently ignored. If we could devise a mapping between some of
>>> those free bits, and the signaling bits in the block header, it would be
>>> possible to have rules as follows:
>>>
>>> - A transaction signaling in the affirmative MUST NOT be included in a
>>> block that does not signal in the affirmative
>>> - A transaction that is NOT signaling MAY be included in a block
>>> regardless of that block's signaling vector
>>> - (Optional) A transaction signaling in the negative MUST NOT be
>>> included in a block that signals in the affirmative
>>>
>>> Under this set of conditions, a user has the means of sybil-resistant
>>> influence over miner decisions. If a miner cannot collect the fees for a
>>> transaction without signaling, the user's fee becomes active economic
>>> pressure for the miner to signal (or not, if we include some variant of the
>>> negative clause). In this environment, miners could have a better view into
>>> what users do want, as would the Bitcoin network at large.
>>>
>>> Some may take issue with the idea that people can pay for the outcome
>>> they want and may try to compare a method like this to Proof of Stake, but
>>> there are only 3 sybil resistant mechanisms I am aware of, and any "real"
>>> view into what social consensus looks like MUST be sybil resistant:
>>>
>>> - Hashpower
>>> - Proof of personhood (KYC)
>>> - Capital burn/risk
>>>
>>> Letting hashpower decide this is the thing that is currently
>>> contentious, KYC is dead on arrival both on technical and social grounds,
>>> which really just leaves some means of getting capital into the process of
>>> consensus measurement. This mechanism I'm proposing is measurable
>>> completely en-protocol and doesn't require trust in institutions that fork
>>> futures would. Additionally it could be an auxiliary feature of the soft
>>> fork deployment scheme chosen making it something you could neatly package
>>> all together with the deployment itself.
>>>
>>> There are many potential tweaks to the design I propose above:
>>> 1. Do we include a notion of negative signaling (allowing for the
>>> possibility of rejection)
>>> 2. Do we make it such that miner signaling must be congruent with >X% of
>>> transactions, where congruence is that the signal must match any
>>> non-neutral signal of transaction.
>>>
>>> Some anticipated objections:
>>>
>>> 1. signaling isn't voting, no deployment should be made without
>>> consensus first.
>>> - yeah well we can't currently measure consensus right now, so that's
>>> not a super helpful thing to say and is breeding ground for abuse in the
>>> form of certain people making the unsubstantiated claim that consensus does
>>> or does not exist for a particular initiative
>>>
>>> 2. This is just a proposal for "pay to play", we should not let the
>>> wealthy make consensus decisions.
>>> - I agree that wealth should not be able to strong-arm decision making.
>>> But the status quo seems even worse where we let publicly influential
>>> people decide consensus in such a way where not only do they not "lose
>>> ammunition" in the process of campaigning, but actually accrue it, creating
>>> really bad long-term balances of power.
>>>
>>> 3. Enforcing this proposal requires its own soft fork.
>>> - Yes. It does...and there's a certain cosmic irony to that, but before
>>> we consider how to make this happen, I'd like to even discuss whether or
>>> not it's a good idea.
>>>
>>> 4. This gives CoinJoin pool operators and L2 protocol implementations
>>> power over deciding consensus.
>>> - I see this as an improvement over the status quo
>>>
>>> 5. This encourages "spam"
>>> - If you pay the fees, it's not spam.
>>>
>>> The biggest question I'd like to pose to the forum is:
>>> - Does a scheme like this afford us a better view into consensus than we
>>> have today?
>>> - Can it be gamed to give us a *worse* view into consensus? How?
>>> - Does it measure the right thing? If not, what do you think is the
>>> right thing to measure? (assuming we could)
>>> - Should I write a BIP spec'ing this out in detail?
>>>
>>> Cheers,
>>> Keagan
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/815a5da9/attachment-0001.html>

2023-06-07 18:25:16

- reply

📅 Original date posted:2020-06-09
📝 Original message:Hello,
Just a few comments.
>But there is no guarantee that ndes should keep all of them from the
genesis. It depends. Maybe some nodes want to keep all the transactions,
some part of them and might nothing.
There is no guarantee that nodes keep them all from the genesis now, nodes
can turn on pruning if the operator doesn't desire to keep all the
transactions from the genesis block
(https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning).
Likewise, light clients may not keep any transaction history.
>Also we can think about check pointing. When a new node connects to the
network, it doesn't need to validate all the blocks since genesis. It can
start validating from a checkpoint.
>Transactions have their own way to survive. Owner of the coin can keep the
history of his transactions.
There have been some checkpoint discussions on here too, which have
discussed the pros and cons of them.
see, e.g.:
site:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ checkpointand:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016001.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017209.html
Without introducing trusted people, how can you prove that the "owner" is
person A or B without verification from the genesis block? For example, A
or B could claim to be the owner and provide an altered client with an
altered checkpoint to "prove" it.
>Anytime the bitcoin community decides to make a hard-fork, you might
consider this change as well
>From reading the initial bitcoin paper, many proposals etc since and having
been around the "bitcoin community" for 9 years, I think that this change
has a very, very small chance of ever happening because full transaction
verification is an important part of the blockchain bank. Not to say this
isn't a useful, interesting, informative, and educational discussion, but
it seems unlikely to happen. Likewise, it could lead to something related
that would be likely to occur, so full discussions like this are useful.
Regards, :-)
Chris
On Tue, Jun 9, 2020 at 7:20 AM Mostafa Sedaghat joo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good day ZmnSCPxj
>
> As I said before, I don't expect a hard fork for this change. I wanted to
> share my thoughts with you guys. Anytime the bitcoin community decides to
> make a hard-fork, you might consider this change as well.
> I believe decoupling transactions from the block is beautiful.
>
> About transaction verification,
> Transactions have their own way to survive. Owner of the coin can keep the
> history of his transactions.
> But there is no guarantee that ndes should keep all of them from the
> genesis. It depends. Maybe some nodes want to keep all the transactions,
> some part of them and might nothing.
> Also we can think about check pointing. When a new node connects to the
> network, it doesn't need to validate all the blocks since genesis. It can
> start validating from a checkpoint.
>
> And also adding 32 bits to the header of translation (which won't be saved
> inside the block) is not a big deal.
>
>
> Adios,
> Mostafa
>
>
>
> On Sun, Jun 7, 2020 at 11:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Mostafa,
>>
>>
>> > The main point of stamping transactions is decoupling transactions from
>> the block.
>> >
>> > Blockchain size matters
>> > SegWit is a good witness that shows blockchain size matters.
>> Nowadays, Data storage is cheap and easy, but that doesn't mean it's a
>> simple matter. If you need to have a data-center to keep a copy of a
>> blockchain, then you are far from a decentralization system.
>> >
>> > A Solution
>> > Stamping transaction is a simple idea to keep the size of the
>> blockchain as small as possible. The question that I was looking to answer
>> is how we can decouple the transaction from the blocks.
>> > Who cares about the transaction that happened 10 years ago. In the real
>> world you may go to your bank and ask them to give you transaction history.
>> But they probably have limits. They might say we just only keep the last 3
>> months in our system.
>>
>> Stamping transaction is not how you would be able to keep **blockchain**
>> size low.
>>
>> The reason why very old history is retained is that, if a new node is
>> brought up, you need to prove to that node that you are in fact the correct
>> owner of the current coins.
>> Thus the entire history of Bitcoin is needed when starting a new node,
>> and why archive nodes exist.
>>
>> You might argue that banks do not do that, and that is because we want to
>> do better than banks; we know that existing currency systems have not only
>> the "official" minter, but also many "unofficial" minters (commonly called
>> counterfeiters) which dilute the value of the currency.
>> It is this insistence on a full accounting of the provenance for every
>> satoshi that separates Bitcoin from previous currency systems; bank fraud
>> exists, and it hides in such sloppy techniques as deleting old transaction
>> records.
>>
>> Work has been done to have client-side validation (i.e. the owner of a
>> coin keeps the entire history, and when paying, you hand over the entire
>> history of your coin to the payee, instead of everyone validating every
>> transaction).
>> Look up Peter Todd for some initial work on this.
>>
>>
>> > Implementation
>> >
>> > > First off, the proposed mechanism can be made into a softfork by
>> using an unspendable `scriptPubKey` with 0 output value.
>> > SoftFork is not possible here. Because the transaction will not be
>> saved inside the block (only tx hashes). Block format needs to be changed.
>> Therefore the block will be invalid.
>>
>> That greatly reduces the chances your proposal will get into Bitcoin; you
>> would need to have very good advantages to counterbalance the tremendous
>> risk that hardforks introduce in the continuity of the coin.
>>
>> Bitcoin has never gone through a hardfork that has not instead created a
>> new cryptocurrency, so any solution that requires a hardfork is going to be
>> unlikely to be accepted by everyone.
>>
>> > > Engineering-wise, block validation now needs to memorize the last N
>> block hashes.
>> > I don't think we need to memorize the last N block hashes. We can have
>> something like:
>> > ```
>> > Current_Height - Height_Of(tx.stamp) <= N
>> > ```
>>
>> ...
>>
>>
>> `Height_Of()` would basically be a mapping from block hashes to block
>> heights, with the number of elements equal to the height of the blockchain,
>> and thus continuously growing.
>> Thus, validation is expected to become more expensive as the blockchain
>> grows.
>>
>> Since stamped transactions have a time-to-live anyway, instead you can
>> use a *set* of the most recent N block hashes.
>> Then you simply check if the stamp is in the set.
>> This creates a data structure that is constant in size (at each block,
>> you remove the block from N blocks ago), which is good for validation.
>>
>> > Incentives
>> > I think Stamping transactions have nothing to do with the
>> incentivization mechanism. Forgive me if I couldn't get your point.
>>
>> A stamped tranasction has a stamp, an unstamped transaction has no stamp.
>> The stamped transaction is larger because of the stamp.
>> Larger transactions are more expensive because fees.
>>
>> Thus, stamped transactions are more expensive than unstamped transactions.
>>
>> Convince me why I would make *my* transaction stamped when I can just
>> convince *everyone else* to stamp *their* transactions and use unstamped
>> transactions myself.
>>
>> If you propose that all transactions must be stamped in a new version of
>> Bitcoin, then take note that users will prefer to run older versions and
>> never upgrade to the new version that requires stamped transactions.
>> Why should users prefer a more expensive transaction format?
>> For the good of the network?
>> That is precisely an incentives problem: if it is so good for the
>> network, then it should be good for an individual user, because the network
>> is made up of individual users anyway; if individual users are not
>> incentivized to use it, then that fact suggests it might not be as good for
>> the network as you might think.
>>
>> If you answer "the stamp can be discounted" then be aware that validating
>> the stamp is still a cost on every node, and it is that cost that we want
>> to be reflected in pricing every byte in the transaction.
>> For instance, UTXOs are retained, potentially indefinitely, and the UTXO
>> lookup structure has to be very fast and is referred to at every
>> transaction validation, so outputs (which create new UTXO entries) in
>> SegWit are 4x more expensive than signatures, since signatures are only
>> validated once when the transaction is queued to be put in the mempool.
>>
>>
>> > Mempool
>> > It's bad of me that I don't really know how mempool works in Bitcoin.
>> My assumption is that there are some junk transactions (transactions that
>> are valid but have very low or zero fees) inside the mempool. Stamping
>> transactions might help to get rid of them time to time.
>>
>> Why would you think that stamping reduces mempool size?
>>
>> If I wanted to I could just re-send the transaction with a fresh stamp.
>> Then the mempool usage would still be the same, and bandwidth use will
>> increase (because the same transaction is now re-broadcast with a fresh
>> stamp, and the added size of the stamps themselves).
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>> _______________________________________________
> 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/20200609/158605a4/attachment.html>

2023-06-07 18:08:37

- reply

📅 Original date posted:2017-12-11
📝 Original message:Hi,
1. If there are 16.4 million mined and 4 million are lost, that results in
12.4 million in circulation vs 14.4 million.
2. Satoshi addressed this as have numerous other people (
https://bitcointalk.org/index.php?topic=198.msg1647#msg1647 ) - lost coins
decrease supply, increasing value of the remaining coins.
3. This assumes this is a problem. Bitcoin is divisible, 100 million,
potentially more if necessary. (
https://en.bitcoin.it/wiki/Help:FAQ#How_divisible_are_bitcoins.3F)
4. Why is it okay to steal bitcoins from people who's bitcoins have been
"dormant" for a fixed period, 10 years in your example?
5. What happens to bitcoins that, say, Hal Finney still had (if any) and he
put in cold storage while he is in ultimate cold storage (
https://en.wikipedia.org/wiki/Hal_Finney_(computer_scientist)#Death) ?
Ditto for someone, say, in a coma for 11 years, in jail for 11 years or any
other similar event? Or a 20 year old sets aside coins for retirement.
The following year, the system is changed, and when he looks again after
not paying attention for a decade or two, they are gone.
6. This encourages censorship by miners for people attempting to move coins.
7. This has been discussed many times before and everyone is welcome to
fork bitcoin code and the block chain and convince people to follow this
chain and code. Then you can see if you can get many people to agree that
this is a good idea.
On Mon, Dec 11, 2017 at 12:30 PM, Teweldemedhin Aberra via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It is estimated that about 4 million of the about 16.4 Bitcoins ever mined
> are lost forever because no one knows the private keys of some Bitcoin
> addresses. This effectively mean there are actually only 14.4 million
> Bitcoins in circulation even though 16.4 million are mined. There is no way
> of eliminating the human errors that cause these losses of Bitcoin from
> circulation, while the number of Bitcoin that will ever be mined is capped
> at 21 million. This means the total number of Bitcoins that are in
> circulation will eventually become zero, bringing the network to an end.
>
> The solution this BIP proposes is to implementing a dead man's switch to
> Bitcoin addresses. The dead man's switch causes the Bitcoins assigned to
> dormant addresses to automatically expire. A Bitcoin address is deemed
> dormant if it is not used in transactions for some fixed length of time,
> say ten years.
>
> The calculation of the miner's reward should take into account the
> Bitcoins that has expired. This means there is a possibility that miner's
> reward can increase if sufficient number of Bitcoins expire.
>
> Ref:
>
> http://fortune.com/2017/11/25/lost-bitcoins/
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_2495265241835744459_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> 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/20171211/bae02d55/attachment-0001.html>

2023-06-07 18:08:25

- reply

📅 Original date posted:2017-12-18
📝 Original message:Regarding "problem" #2 where you say "How do we ensure that all valid
transactions are eventually included in the blockchain?": I do not believe
that all people would (a) agree this is a problem or (b) that we do want to
*ENSURE* that *ALL* valid transactions are eventually included in the
blockchain. There are many *valid* transactions that oftentimes miners do
not (and should not) wish to require be confirmed and included in the
blockchain. Spam transactions for example can be valid, but used to attack
bitcoin by using no or low fee. Any valid transaction MAY be included by a
miner, but requiring it in some fashion at this point would open the
network to other attack vectors. Perhaps you meant it a different way.
On Fri, Dec 15, 2017 at 3:59 PM, Damian Williamson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There are really two separate problems to solve.
>
>
> How does Bitcoin scale with fixed block size?
> How do we ensure that all valid transactions are eventually included in
the blockchain?
>
>
> Those are the two issues that the proposal attempts to address. It makes
sense to resolve these two problems together. Using the proposed system for
variable block sizes would solve the first problem but there would still be
a whole bunch of never confirming transactions. I am not sure how to
reliably solve the second problem at scale without first solving the first.
>
>
> >* Every node has a (potentially) different mempool, you can't use it to
decide consensus values like the max block size.
>
>
> I do not suggest a consensus. Depending on which node solves a block the
value for next block size will be different. The consensus would be that
blocks will adhere to the next block size value transmitted with the
current block. It is easy to verify that the consensus is being adhered to
once in place.
>
> >* Increasing the entropy in a block to make it more unpredictable
doesn't really make sense.
>
> Not a necessary function, just an effect of using a probability-based
distribution.
>
> >* Bitcoin should be roughly incentive compatible. Your proposal
explicits asks miners to ignore their best interests, and confirm
transactions by "priority". What are you going to do if a "malicious"
miner decides to go after their profits and order by what makes them the
most money. Add "ordered by priority" as a consensus requirement? And even
if you miners can still sort their mempool by fee, and then order the top
1MB by priority.
>
> I entirely agree with your sentiment that Bitcoin must be incentive
compatible. It is necessary.
>
> It is in only miners immediate interest to make the most profitable block
from the available transaction pool. As with so many other things, it is
necessary to partially ignore short-term gain for long-term benefit. It is
in miners and everybody's long-term interest to have a reliable transaction
service. A busy transaction service that confirms lots of transactions per
hour will become more profitable as demand increases and more users are
prepared to pay for priority. As it is there is currently no way to fully
scale because of the transaction bandwidth limit and that is problematic.
If all valid transactions must eventually confirm then there must be a way
to resolve that problem.
>
> Bitcoin deliberately removes traditional scale by ensuring blocks take
ten minutes on average to solve, an ingenious idea and, incentive
compatible but, fixed block sizes leaves us with a problem to solve when we
want to scale.
>
> >If you could find a good solution that would allow you to know if miners
were following your rule or not (and thus ignore it if it doesn't) then you
wouldn't even need bitcoin in the first place.
>
> I am confident that the math to verify blocks based on the proposal can
be developed (and I think it will not be too complex for a mathematician
with the relevant experience), however, I am nowhere near experienced
enough with probability and statistical analysis to do it. Yes, if Bitcoin
doesn't then it might make another great opportunity for an altcoin but I
am not even nearly interested in promoting any altcoins.
>
>
> If not the proposal that I have put forward, then, hopefully, someone can
come up with a better solution. The important thing is that the issues are
resolved.
>
>
> Regards,
>
> Damian Williamson
>
>
>
> ________________________________
> From: Rhavar <rhavar at protonmail.com>
> Sent: Saturday, 16 December 2017 3:38 AM
> To: Damian Williamson
> Cc: Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use
Transaction Priority For Ordering Transactions In Blocks
>
> > I understand that there would be technical issues to resolve in
implementation, but, are there no fundamental errors?
>
> Unfortunately your proposal is really fundamentally broken, on a few
levels. I think you might need to do a bit more research into how bitcoin
works before coming up with such improvements =)
>
> But just some quick notes:
>
> * Every node has a (potentially) different mempool, you can't use it to
decide consensus values like the max block size.
>
> * Increasing the entropy in a block to make it more unpredictable doesn't
really make sense.
>
> * Bitcoin should be roughly incentive compatible. Your proposal explicits
asks miners to ignore their best interests, and confirm transactions by
"priority". What are you going to do if a "malicious" miner decides to go
after their profits and order by what makes them the most money. Add
"ordered by priority" as a consensus requirement? And even if you miners
can still sort their mempool by fee, and then order the top 1MB by priority.
>
> If you could find a good solution that would allow you to know if miners
were following your rule or not (and thus ignore it if it doesn't) then you
wouldn't even need bitcoin in the first place.
>
>
>
>
> -Ryan
>
>
> -------- Original Message --------
> Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
Priority For Ordering Transactions In Blocks
> Local Time: December 15, 2017 3:42 AM
> UTC Time: December 15, 2017 9:42 AM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
>
>
> I should not take it that the lack of critical feedback to this revised
proposal is a glowing endorsement. I understand that there would be
technical issues to resolve in implementation, but, are there no
fundamental errors?
>
> I suppose that it if is difficult to determine how long a transaction has
been waiting in the pool then, each node could simply keep track of when a
transaction was first seen. This may have implications for a verify
routine, however, for example, if a node was offline, how should it
differentiate how long each transaction was waiting in that case? If a node
was restarted daily would it always think that all transactions had been
waiting in the pool less than one day If each node keeps the current
transaction pool in a file and updates it, as transactions are included in
blocks and, as new transactions appear in the pool, then that would go some
way to alleviate the issue, apart from entirely new nodes. There should be
no reason the contents of a transaction pool files cannot be shared without
agreement as to the transaction pool between nodes, just as nodes transmit
new transactions freely.
>
> It has been questioned why miners could not cheat. For the question of
how many transactions to include in a block, I say it is a standoff and
miners will conform to the proposal, not wanting to leave transactions with
valid fees standing, and, not wanting to shrink the transaction pool. In
any case, if miners shrink the transaction pool then I am not immediately
concerned since it provides a more efficient service. For the question of
including transactions according to the proposal, I say if it is possible
to keep track of how long transactions are waiting in the pool so that they
can be included on a probability curve then it is possible to verify that
blocks conform to the proposal, since the input is a probability, the
output should conform to a probability curve.
>
>
> If someone has the necessary skill, would anyone be willing to develop
the math necessary for the proposal?
>
> Regards,
> Damian Williamson
>
>
> ________________________________
>
> From: bitcoin-dev-bounces at lists.linuxfoundation.org <
bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Damian
Williamson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Friday, 8 December 2017 8:01 AM
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
Priority For Ordering Transactions In Blocks
>
>
>
> Good afternoon,
>
> The need for this proposal:
>
> We all must learn to admit that transaction bandwidth is still lurking as
a serious issue for the operation, reliability, safety, consumer
acceptance, uptake and, for the value of Bitcoin.
>
> I recently sent a payment which was not urgent so; I chose three-day
target confirmation from the fee recommendation. That transaction has still
not confirmed after now more than six days - even waiting twice as long
seems quite reasonable to me. That transaction is a valid transaction; it
is not rubbish, junk or, spam. Under the current model with transaction
bandwidth limitation, the longer a transaction waits, the less likely it is
ever to confirm due to rising transaction numbers and being pushed back by
transactions with rising fees.
>
> I argue that no transactions are rubbish or junk, only some zero fee
transactions might be spam. Having an ever-increasing number of valid
transactions that do not confirm as more new transactions with higher fees
are created is the opposite of operating a robust, reliable transaction
system.
>
> Business cannot operate with a model where transactions may or may not
confirm. Even a business choosing a modest fee has no guarantee that their
valid transaction will not be shuffled down by new transactions to the
realm of never confirming after it is created. Consumers also will not
accept this model as Bitcoin expands. If Bitcoin cannot be a reliable
payment system for confirmed transactions then consumers, by and large,
will simply not accept the model once they understand. Bitcoin will be a
dirty payment system, and this will kill the value of Bitcoin.
>
> Under the current system, a minority of transactions will eventually be
the lucky few who have fees high enough to escape being pushed down the
list.
>
> Once there are more than x transactions (transaction bandwidth limit)
every ten minutes, only those choosing twenty-minute confirmation (2
blocks) will have initially at most a fifty percent chance of ever having
their payment confirm. Presently, not even using fee recommendations can
ensure a sufficiently high fee is paid to ensure transaction confirmation.
>
> I also argue that the current auction model for limited transaction
bandwidth is wrong, is not suitable for a reliable transaction system and,
is wrong for Bitcoin. All transactions must confirm in due time. Currently,
Bitcoin is not a safe way to send payments.
>
> I do not believe that consumers and business are against paying fees,
even high fees. What is required is operational reliability.
>
> This great issue needs to be resolved for the safety and reliability of
Bitcoin. The time to resolve issues in commerce is before they become great
big issues. The time to resolve this issue is now. We must have the
foresight to identify and resolve problems before they trip us over.
Simply doubling block sizes every so often is reactionary and is not a
reliable permanent solution. I have written a BIP proposal for a technical
solution but, need your help to write it up to an acceptable standard to be
a full BIP.
>
> I have formatted the following with markdown which is human readable so,
I hope nobody minds. I have done as much with this proposal as I feel that
I am able so far but continue to take your feedback.
>
> # BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering
Transactions In Blocks
>
> ## The problem:
> Everybody wants value. Miners want to maximize revenue from fees (and we
presume, to minimize block size). Consumers need transaction reliability
and, (we presume) want low fees.
>
> The current transaction bandwidth limit is a limiting factor for both. As
the operational safety of transactions is limited, so is consumer
confidence as they realize the issue and, accordingly, uptake is limited.
Fees are artificially inflated due to bandwidth limitations while failing
to provide a full confirmation service for all transactions.
>
> Current fee recommendations provide no satisfaction for transaction
reliability and, as Bitcoin scales, this will worsen.
>
> Bitcoin must be a fully scalable and reliable service, providing full
transaction confirmation for every valid transaction.
>
> The possibility to send a transaction with a fee lower than one that is
acceptable to allow eventual transaction confirmation should be removed
from the protocol and also from the user interface.
>
> ## Solution summary:
> Provide each transaction with an individual transaction priority each
time before choosing transactions to include in the current block, the
priority being a function of the fee paid (on a curve), and the time
waiting in the transaction pool (also on a curve) out to n days (n=60 ?).
The transaction priority to serve as the likelihood of a transaction being
included in the current block, and for determining the order in which
transactions are tried to see if they will be included.
>
> Use a target block size. Determine the target block size using; current
transaction pool size x ( 1 / (144 x n days ) ) = number of transactions to
be included in the current block. Broadcast the next target block size with
the current block when it is solved so that nodes know the next target
block size for the block that they are building on.
>
> The curves used for the priority of transactions would have to be
appropriate. Perhaps a mathematician with experience in probability can
develop the right formulae. My thinking is a steep curve. I suppose that
the probability of all transactions should probably account for a
sufficient number of inclusions that the target block size is met although,
it may not always be. As a suggestion, consider including some zero fee
transactions to pad, highest BTC value first?
>
> **Explanation of the operation of priority:**
> > If transaction priority is, for example, a number between one (low) and
one-hundred (high) it can be directly understood as the percentage chance
in one-hundred of a transaction being included in the block. Using
probability or likelihood infers that there is some function of random. If
random (100) < transaction priority then the transaction is included.
>
> >To break it down further, if both the fee on a curve value and the time
waiting on a curve value are each a number between one and one-hundred, a
rudimentary method may be to simply multiply those two numbers, to find the
priority number. For example, a middle fee transaction waiting thirty days
(if n = 60 days) may have a value of five for each part (yes, just five,
the values are on a curve). When multiplied that will give a priority value
of twenty-five, or, a twenty-five percent chance at that moment of being
included in the block; it will likely be included in one of the next four
blocks, getting more likely each chance. If it is still not included then
the value of time waiting will be higher, making for more probability. A
very low fee transaction would have a value for the fee of one. It would
not be until near sixty-days that the particular low fee transaction has a
high likelihood of being included in the block.
>
> I am not concerned with low (or high) transaction fees, the primary
reason for addressing the issue is to ensure transactional reliability and
scalability while having each transaction confirm in due time.
>
> ## Pros:
> * Maximizes transaction reliability.
> * Fully scalable.
> * Maximizes possibility for consumer and business uptake.
> * Maximizes total fees paid per block without reducing reliability;
because of reliability, in time confidence and overall uptake are greater;
therefore, more transactions.
> * Market determines fee paid for transaction priority.
> * Fee recommendations work all the way out to 30 days or greater.
> * Provides additional block entropy; greater security since there is less
probability of predicting the next block.
>
> ## Cons:
> * Could initially lower total transaction fees per block.
> * Must be first be programmed.
>
> ## Solution operation:
> This is a simplistic view of the operation. The actual operation will
need to be determined in a spec for the programmer.
>
> 1. Determine the target block size for the current block.
> 2. Assign a transaction priority to each transaction in the pool.
> 3. Select transactions to include in the current block using probability
in transaction priority order until the target block size is met.
> 5. Solve block.
> 6. Broadcast the next target block size with the current block when it is
solved.
> 7. Block is received.
> 8. Block verification process.
> 9. Accept/reject block based on verification result.
> 10. Repeat.
>
> ## Closing comments:
> It may be possible to verify blocks conform to the proposal by showing
that the probability for all transactions included in the block
statistically conforms to a probability distribution curve, *if* the
individual transaction priority can be recreated. I am not that deep into
the mathematics; however, it may also be possible to use a similar method
to do this just based on the fee, that statistically, the blocks conform to
a fee distribution. Any zero fee transactions would have to be ignored.
This solution needs a clever mathematician.
>
> I implore, at the very least, that we use some method that validates full
transaction reliability and enables scalability of block sizes. If not this
proposal, an alternative.
>
> Regards,
> Damian Williamson
>
>
>
>
> _______________________________________________
> 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/20171218/50d68c11/attachment-0001.html>

2023-06-07 18:04:55

- reply

📅 Original date posted:2017-08-22
📝 Original message:The initial message I replied to stated in part, "Okay so I quite like this
idea. If we start removing at height 630000 or 840000 (gives us 4-8 years
to develop this solution), it stays nice and neat with the halving
interval...."
That is less than 3 years or less than 7 years away. Much sooner than it
is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as
to require that early coins start getting "scavenged" at that date seems
unneeded and irresponsible. Besides, your ECDSA is only revealed when you
spend the coins which does provide some quantum resistance. Hal was just
an example of people putting their coins away expecting them to be there at
X years in the future, whether it is for himself or for his kids and wife.
:-)
On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton at gmail.com>
wrote:
> Very true, if Moore's law is still functional in 200 years, computers will
> be 2^100 times faster (possibly more if quantum computing becomes
> commonplace), and so old wallets may be easily cracked.
>
> We will need a way to force people to use newer, higher security wallets,
> and turning coins to mining rewards is better solution than them just being
> hacked.
>
> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
>
>> In any case when Hal Finney do not wake up from his 200years
>> cryo-preservation (because unfortunately for him 200 years earlier they did
>> not know how to preserve a body well enough to resurrect it) he would find
>> that advance in computer technology made it trivial for anyone to steal his
>> coins using the long-obsolete secp256k1 ec curve (which was done long
>> before, as soon as it became profitable to crack down the huge stash of
>> coins stale in the early blocks)
>>
>> I just don't get that argument that you can't be "your own bank". The
>> only requirement coming from this would be to move your coins about once
>> every 10 years or so, which you should be able to do if you have your
>> private keys (you should!). You say it may be something to consider when
>> computer breakthroughs makes old outputs vulnerable, but I say it's not
>> "if" but "when" it happens, and by telling firsthand people that their
>> coins requires moving every once in a long while you ensure they won't do
>> stupid things or come back 50 years from now and complain their addresses
>> have been scavenged.
>>
>> --
>> Thomas
>>
>>
>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>
>> I agree, it is only a good idea in the event of a quantum computing
>> threat to the security of Bitcoin.
>>
>> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> This seems to be drifting off into alt-coin discussion. The idea that
>>> we can change the rules and steal coins at a later date because they are
>>> "stale" or someone is "hoarding" is antithetical to one of the points of
>>> bitcoin in that you can no longer control your own money ("be your own
>>> bank") because someone can at a later date take your coins for some reason
>>> that is outside your control and solely based on some rationalization by a
>>> third party. Once the rule is established that there are valid reasons why
>>> someone should not have control of their own bitcoins, what other reasons
>>> will then be determined to be valid?
>>>
>>> I can imagine Hal Finney being revived (he was cryo-preserved at Alcor
>>> if you aren't aware) after 100 or 200 years expecting his coins to be there
>>> only to find out that his coins were deemed "stale" so were "reclaimed" (in
>>> the current doublespeak - e.g. stolen or confiscated). Or perhaps he
>>> locked some for his children and they are found to be "stale" before they
>>> are available. He said in March 2013, "I think they're safe enough" stored
>>> in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
>>>
>>> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better
>>> in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many
>>> times since 2010 and still do not agree with the rational that embracing
>>> allowing someone to steal someone else's coins for any reason is a useful
>>> change to bitcoin.
>>>
>>>
>>>
>>>
>>> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Okay so I quite like this idea. If we start removing at height 630000
>>>> or 840000 (gives us 4-8 years to develop this solution), it stays nice and
>>>> neat with the halving interval. We can look at this like so:
>>>>
>>>> B - the current block number
>>>> P - how many blocks behind current the coin burning block is. (630000,
>>>> 840000, or otherwise.)
>>>>
>>>> Every time we mine a new block, we go to block (B-P), and check for
>>>> stale coins. These coins get burnt up and pooled into block B's miner fees.
>>>> This keeps the mining rewards up in the long term, people are less likely
>>>> to stop mining due to too low fees. It also encourages people to keep
>>>> moving their money around the enconomy instead of just hording and leaving
>>>> it.
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/b9c37929/attachment.html>

2023-06-07 18:04:54

- reply

📅 Original date posted:2017-08-22
📝 Original message:This seems to be drifting off into alt-coin discussion. The idea that we
can change the rules and steal coins at a later date because they are
"stale" or someone is "hoarding" is antithetical to one of the points of
bitcoin in that you can no longer control your own money ("be your own
bank") because someone can at a later date take your coins for some reason
that is outside your control and solely based on some rationalization by a
third party. Once the rule is established that there are valid reasons why
someone should not have control of their own bitcoins, what other reasons
will then be determined to be valid?
I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if
you aren't aware) after 100 or 200 years expecting his coins to be there
only to find out that his coins were deemed "stale" so were "reclaimed" (in
the current doublespeak - e.g. stolen or confiscated). Or perhaps he
locked some for his children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're safe enough" stored
in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in
bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times
since 2010 and still do not agree with the rational that embracing allowing
someone to steal someone else's coins for any reason is a useful change to
bitcoin.
On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Okay so I quite like this idea. If we start removing at height 630000 or
> 840000 (gives us 4-8 years to develop this solution), it stays nice and
> neat with the halving interval. We can look at this like so:
>
> B - the current block number
> P - how many blocks behind current the coin burning block is. (630000,
> 840000, or otherwise.)
>
> Every time we mine a new block, we go to block (B-P), and check for stale
> coins. These coins get burnt up and pooled into block B's miner fees. This
> keeps the mining rewards up in the long term, people are less likely to
> stop mining due to too low fees. It also encourages people to keep moving
> their money around the enconomy instead of just hording and leaving it.
> _______________________________________________
> 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/20170822/0237425a/attachment.html>

2023-06-07 17:54:59

- reply

📅 Original date posted:2016-12-18
📝 Original message:I agree that finding the right line is difficult and purposefully crippling
(too strong a term?) the software is not necessarily the best way to
encourage long term adoption.
For example, I ran version 0.3.x from July/August 2010 for several years on
a miner without upgrading to anything higher than the 0.3.24 release since
the usage pattern on that machine didn't require it. It might have been to
the ~0.7.0 release, I am not sure when I finally upgraded it. On a machine
that had my wallet, I kept it updated, but forcing upgrades may not be the
best plan given that hard forks should be few and far between. Security
updates, are important, but leaving it up to the operator of the node to
determine when to upgrade is an important feature.
Chris
On Sun, Dec 18, 2016 at 5:34 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> One thing which hasn't been addressed yet in this thread is developer
> centralization. Unlike other applications we want to ensure that it's not
> only possible for users to refuse an upgrade, but easy. While this by no
> means lessens the retirement that users run up to date software for
> security reasons, finding the right line to draw is difficult.
>
> Matt
>
> On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >I assume this has been well discussed in at some point in the Bitcoin
> >community, so I apologize if I'm repeating old ideas.
> >
> >Problem exploitable nodes:
> >It is plausible that people running these versions of bitcoind may not
> >be applying patches. Thus, these nodes may be vulnerable to known
> >exploits. I would hope none of these nodes are gateway nodes for
> >miners, web wallets or exchanges. How difficult would it be to crawl
> >the network to find vulnerable nodes and exploit them? What percentage
> >of the network is running vulnerable versions of bitcoind?
> >
> >Problem eclipsable nodes:
> >Currently a bitcoind node disconnects from any node with a version
> >below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse
> >attack because they are partitioned from the newer nodes, especially
> >when they are "freshly obsolete". I have not examined how protocol
> >versioning works in detail so I could be missing something.
> >
> >One option could be that after a grace period:
> >1. to still connect to obsolete nodes and even to transmit
> >blockheaders,
> >2. but to stop sending the full-blocks and transactions to these
> >nodes, thereby alerting the operator that something is wrong and
> >causing them to upgrade.
> >It may make sense to create this as a rule, if your longest chain
> >consists of only blockheaders and no one will tell you the
> >transactions for over 1000 blocks you are obsolete, spit out an error
> >message and shutdown.
> >
> >This would not address the issue of alt-coins which are forked from
> >old vulnerable versions of bitcoind, but that is probably out of
> >scope.
> >
> >On Thu, Dec 15, 2016 at 1:48 PM, Jorge Timón via bitcoin-dev
> ><bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> Older node versions may generate issues because some upgrades will
> >make
> >>> several of the nodes running older protocol versions obsolete and or
> >>> incompatible. There may be other hard to predict behaviors on older
> >versions
> >>> of the client.
> >>
> >> Hard to predict or not, you can't force people to run newer software.
> >>
> >>> In order to avoid such wide fragmentation of "Bitcoin Core” node
> >versions
> >>> and to help there be a more predictable protocol improvement
> >process, I
> >>> consider it worth it to analyze introducing some planned
> >obsolescence in
> >>> each new version. In the last year we had 4 new versions so if each
> >version
> >>> is valid for about 1 year (52560 blocks) this may be a reasonable
> >time frame
> >>> for node operators to upgrade. If a node does not upgrade it will
> >stop
> >>> working instead of participating in the network with an outdated
> >protocol
> >>> version.
> >>
> >> When you introduce anti-features like this in free software they can
> >> be trivially removed and they likely will.
> >>
> >>> These changes may also simplify the developer's jobs in some cases
> >by
> >>> avoiding them having to deal with ancient versions of the client.
> >>
> >> There's a simpler solution for this which is what is being done now:
> >> stop maintaining and giving support for older versions.
> >> There's limited resources and developers are rarely interested in
> >> fixing bugs for very old versions. Users shouldn't expect things to
> >be
> >> backported to old versions (if developers do it and there's enough
> >> testing, there's no reason not to do more releases of old versions,
> >it
> >> is just rarely the case).
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161218/8ef11efb/attachment.html>

2023-06-07 17:52:33

- reply

📅 Original date posted:2016-08-09
📝 Original message:Have you checked AudioModem out:
https://github.com/applidium/AudioModem
Or Chirp:
http://www.chirp.io/faq/
Or this Network World article (particularly the last portion on bitcoin):
http://www.networkworld.com/article/2956450/smartphones/sending-data-over-sound-revisited.html
and
http://www.networkworld.com/article/2689597/opensource-subnet/how-a-tv-network-is-being-used-to-move-financial-transactions.html
Instead of re-inventing the wheel, perhaps take a look at them. Or at
least to see their design choices and rationale.
Cheers!
On Tue, Aug 9, 2016 at 7:06 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699 at gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>> Thanks for proposing this. I think this could have some useful use
>>>> cases as you state. I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here: https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin at netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/231ed5cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/231ed5cb/attachment-0001.tiff>

2023-06-07 17:50:34

- reply

📅 Original date posted:2016-05-10
📝 Original message:The second like "2)" has a link to the paper:
http://www.math.rwth-aachen.de/~Timo.Hanke/AsicBoostWhitepaperrev5.pdf
which does discuss the fact that it is "patent-pending". Likewise it
discusses ASIC improvements. Avoiding patents that impact bitcoin and are
not freely licensed, is something that is worthwhile for discussion.
On Tue, May 10, 2016 at 6:17 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Tue, May 10, 2016 at 3:57 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like to
>> make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>>
>> You say that you want to make patented optimization useless, but you
> point to a link that doesn't say anything about ASIC improvements or
> patents, which means that you have been planning to change the protocol
> rules with some miners (but not all the community).
>
> All changes to the protocol should be discussed in public here. If you
> want to make "further similar optimizations useless as well" then maybe you
> should propose a switch to EquiHash.
>
>
>
>>
>> 1)
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>>
>> 2)
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/cd50e919/attachment.html>