Raystonn [ARCHIVE]

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

Public Key

npub1lwk885jp853atdhxp0zrz9fqdxvpu44ffn2avfkfaz9kczsce02s5vyywk

Profile Code

nprofile1qqs0htrn6fqn6g74kmnqh3p3z5sxnxq72655e4wkymy73zmvpgvvh4g9h7vsr

Author Public Key

npub1lwk885jp853atdhxp0zrz9fqdxvpu44ffn2avfkfaz9kczsce02s5vyywk

Show more details

Last Notes

2023-06-07 15:43:54

- reply

📅 Original date posted:2015-07-30
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/ac587502/attachment.html>

2023-06-07 15:43:07

- reply

📅 Original date posted:2015-07-22
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/282f6685/attachment.html>

2023-06-07 15:42:36

- reply

📅 Original date posted:2015-07-17
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/719347de/attachment.html>

2023-06-07 15:41:50

- reply

📅 Original date posted:2015-07-09
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150709/27c792da/attachment.html>

2023-06-07 15:41:49

- reply

2023-06-07 15:41:41

- reply

📅 Original date posted:2015-07-04
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150703/3589410a/attachment.html>

2023-06-07 15:41:39

- reply

2023-06-07 15:41:38

- reply

2023-06-07 15:41:36

- reply

📅 Original date posted:2015-07-04
📝 Original message:We need some analysis on why this has happened. It appears the larger hashrate is violating BIP66. Thus it appears the network is rejecting this BIP, though potentially accidentally. If this is an accident, how is such a large portion of hashrate forking, and what can we do to avoid this in the future?
Raystonn

2023-06-07 15:40:53

- reply

📅 Original date posted:2015-06-28
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/3f441f1e/attachment.html>

2023-06-07 15:40:24

- reply

📅 Original date posted:2015-06-25
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/66e3d82c/attachment.html>

2023-06-07 15:40:15

- reply

📅 Original date posted:2015-06-24
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/f4a52371/attachment.html>

2023-06-07 15:40:15

- reply

2023-06-07 15:40:02

- reply

📅 Original date posted:2015-06-24
📝 Original message:I would like to start a civil discussion on an undefined, or at least unwritten, portion of the BIP process. Who should get to vote on approval to commit a BIP implementation into Bitcoin Core? Is a simple majority of these voters sufficient for approval? If not, then what is?
Raystonn

2023-06-07 15:39:57

- reply

2023-06-07 15:39:55

- reply

2023-06-07 15:38:08

- reply

📅 Original date posted:2015-06-16
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/28f61064/attachment.html>

2023-06-07 15:37:39

- reply

📅 Original date posted:2015-06-13
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/9194c627/attachment.html>

2023-06-07 15:35:55

- reply

📅 Original date posted:2015-05-29
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/19cf34ff/attachment.html>

2023-06-07 15:34:36

- reply

📅 Original date posted:2015-05-26
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/06a5078b/attachment.html>

2023-06-07 15:34:29

- reply

📅 Original date posted:2015-05-09
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/fe07c35b/attachment.html>

2023-06-07 15:34:29

- reply

2023-06-07 15:34:28

- reply

2023-06-07 15:34:20

- reply

📅 Original date posted:2015-05-08
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b010c625/attachment.html>

2023-06-07 15:34:12

- reply

📅 Original date posted:2015-05-08
📝 Original message:It seems to me all this would do is encourage 0-transaction blocks, crippling the network. Individual blocks don't have a "maximum" block size, they have an actual block size. Rational miners would pick blocks to minimize difficulty, lowering the "effective" maximum block size as defined by the optimal size for rational miners. This would be a tragedy of the commons.
In addition to that, average block cinfirmation time, and hence rate of inflation of the bitcoin currency, would now be subject to manipulation. This undermined a core value of Bitcoin.
> On Fri, May 8, 2015 at 1:33 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> * For each block, the miner is allowed to select a different difficulty (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, and this miner-selected difficulty is used for the proof of work check. In addition to adjusting the hashcash target, selecting a different difficulty also raises or lowers the maximum block size for that block by a function of the difference in difficulty.

2023-06-07 15:33:48

- reply

📅 Original date posted:2015-05-30
📝 Original message:An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/7028370e/attachment.html>

2023-06-07 15:33:33

- reply

📅 Original date posted:2015-05-08
📝 Original message:Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain
-Raystonn
On 8 May 2015 1:41 pm, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however.
>
> On Fri, May 8, 2015 at 1:38 PM, Raystonn . <raystonn at hotmail.com> wrote:
>>
>> I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to advertise to the network. Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions. In this manner, transactions are never left hanging for days, and probably not even for hours.
>>
>> -Raystonn
>>
>> On 8 May 2015 1:17 pm, Aaron Voisine <voisine at gmail.com> wrote:
>>>
>>> As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal.
>>>
>>> The best argument I've heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users' experience.
>>>
>>> When users pay too low a fee, they should:
>>>
>>> 1) See immediate failure as they do now with fees that fail to propagate.
>>>
>>> 2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future.
>>>
>>> The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future.
>>>
>>> We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach.
>>>
>>> Aaron Voisine
>>> co-founder and CEO
>>> breadwallet.com
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>

2023-06-07 15:33:33

- reply