CryptAxe [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 20:10:49

- reply

📅 Original date posted:2018-02-13
📝 Original message:This is ridiculous. We shouldn't bastardize open source principals because
someone hurt your feelings.
This is how open source works, stop using it if you don't like it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/eb94265d/attachment.html>

2023-06-07 20:09:36

- reply

📅 Original date posted:2018-01-17
📝 Original message:Why wouldn't they just test the frequency of words from the wordlist in
entirety?
On Jan 17, 2018 5:10 PM, "Weiwu Zhang via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2018-01-09 19:20 GMT+08:00 Ronald van der Meer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>:
> > After reviewing some bitcoin improvement proposals, I noticed that one
> of the words that can be found on the BIP39 English wordlist is “satoshi”.
> > I suggest removing this word from the list so it’s less obvious that
> it’s a bitcoin seed when found by a malicious third party.
>
> If a malicious third party discovers a word list that look like a
> seed, they would try using it as Bitcoin seed first anyway, with or
> without finding the word 'satoshi' in it. The security threat is that
> a malicious third party may index what they found and test every
> occurrence of 'satoshi' for a lead to a seed.
>
> For example, a hard-disk recycling service would add this word to
> their salvage tools. Any successfully hacked gmail account will be
> 'satoshi' tested too.
>
> So I see this as a reasonable improvement:)
> _______________________________________________
> 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/20180117/ae8bb6fa/attachment.html>

2023-06-07 20:07:32

- reply

📅 Original date posted:2017-11-02
📝 Original message:Is there an issue with the current difficulty adjustment algorithm? It's
worked very well as far as I can tell. Introducing a new one seems pretty
risky, what would the benefit be?
On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> algorithm. Bitcoin itself might need to hard fork to employ a similar
> algorithm. It's about as good as they come because it followed the
> "simplest is best" route. Their averaging window is probably
> significantly too long (N=144). It's:
>
> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
>
> They correctly did not use max(timestamp) - min(timestamp) in the
> denominator like others do.
>
> They've written the code and they're about to use it live, so Bitcoin
> will have a clear, simple, and tested path if it suddenly needs to
> hard fork due to having 20x delays for the next 2000 blocks (taking it
> a year to get unstuck).
>
> Details on it and the decision process:
> https://www.bitcoinabc.org/november
>
> It uses a nice median of 3 for the beginning and end of the window to
> help alleviate bad timestamp problems. It's nice, helps a little, but
> will also slow its response by 1 block. They also have 2x and 1/2
> limits on the adjustment per block, which is a lot more than they will
> ever need.
>
> I recommend bitcoin consider using it and making it N=50 instead of 144.
>
> I have seen that any attempts to modify the above with things like a
> low pass filter, starting the window at MTP, or preventing negative
> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
> limits on the timestamps are sufficient and well chosen, although
> something a bit smaller than the +12 might have been better.
>
> One of the contenders to the above is new and actually better, devised
> by Degnr8 and they call it D622 or wt-144.It's a little better than
> they realize. It's the only real improvement in difficulty algorithms
> since the rolling average. It gives a linearly higher weight to the
> more recent timestamps. Otherwise it is the same. Others have probably
> come across it, but there is too much noise in difficulty algorithms
> to find the good ones.
>
> # Degnr8's D622 difficulty algorithm
> # T=TargetTime, S=Solvetime
> # modified by zawy
> for i = 1 to N (from oldest to most recent block)
> t += T[i] / D[i] * i
> j += i
> next i
> next_D = j / t * T
>
> I believe any modification to the above strict mathematical weighted
> average will reduce it's effectiveness. It does not oscillate anymore
> than regular algos and rises faster and drops faster, when needed.
> _______________________________________________
> 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/20171102/080f5543/attachment.html>

2023-06-07 20:07:04

- reply

📅 Original date posted:2017-10-10
📝 Original message:You could technically call myself and Chris 'core developers'. You don't
get to have a fixed rate of Bitcoin and a second way to mint coins at the
same time.
On Oct 10, 2017 1:46 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What?
>
> That is not correct.
>
> There is a fixed amount of Bitcoin, as I said.
>
> The only difference is what chain it is on.
>
> It is precisely because there is a fixed amount that when you
> burn-to-withdraw you mint on another chain.
>
> I will not respond to any more emails unless they’re from core developers.
> Gotta run.
>
> --
> Sent from my mobile device.
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> > On Oct 10, 2017, at 1:23 PM, James Hudon <jameshudon at gmail.com> wrote:
> >
> > You're asking for newly minted bitcoin to go to you but you burned the
> bitcoin used in the peg. You're effectively losing your money and then
> stealing from the miners to gain it back. The miners had to issue your
> amount of bitcoin 2 times (once for your original bitcoin, again to make
> you whole). Why would they agree to this?
> > --
> > hudon
> >
> >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> It would not change the number of Bitcoins in existence.
> >>
> >> --
> >> Sent from my mobile device.
> >> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>
> >>> On Oct 10, 2017, at 12:50 PM, CryptAxe <cryptaxe at gmail.com> wrote:
> >>>
> >>> Your method would change the number of Bitcoins in existence. Why?
> >>>
> >>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> Is that what passes for a technical argument these days? Sheesh.
> >>>
> >>> Whereas in Drivechain users are forced to give up their coins to a
> single group for whatever sidechains they interact with, the generic
> sharding algo lets them (1) keep their coins, (2) trust whatever group they
> want to trust (the miners of the various sidechains).
> >>>
> >>> Drivechain offers objectively worse security.
> >>>
> >>> --
> >>> Sent from my mobile device.
> >>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>
> >>>> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> I think this response speaks for itself.
> >>>>
> >>>>> On 10/10/2017 10:09 AM, Tao Effect wrote:
> >>>>> Hi Paul,
> >>>>>
> >>>>> I thought it was clear, but apparently you are getting stuck on the
> semantics of the word "burn".
> >>>>>
> >>>>> The "burning" applies to the original coins you had.
> >>>>>
> >>>>> When you transfer them back, you get newly minted coins, equivalent
> to the amount you "burned" on the chain you're transferring from ― as
> stated in the OP.
> >>>>>
> >>>>> If you don't like the word "burn", pick another one.
> >>>>>
> >>>>> --
> >>>>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>>>
> >>>>>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com>
> wrote:
> >>>>>>
> >>>>>> Haha, no. Because you "burned" the coins.
> >>>>>>
> >>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com>
> wrote:
> >>>>>> Paul,
> >>>>>>
> >>>>>> It's a two-way peg.
> >>>>>>
> >>>>>> There's nothing preventing transfers back to the main chain.
> >>>>>>
> >>>>>> They work in the exact same manner.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Greg
> >>>>>>
> >>>>>> --
> >>>>>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>>>>
> >>>>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> That is only a one-way peg, not a two-way.
> >>>>>>>
> >>>>>>> In fact, that is exactly what drivechain does, if one chooses
> parameters for the drivechain that make it impossible for any side-to-main
> transfer to succeed.
> >>>>>>>
> >>>>>>> One-way pegs have strong first-mover disadvantages.
> >>>>>>>
> >>>>>>> Paul
> >>>>>>>
> >>>>>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>>>> Dear list,
> >>>>>>>
> >>>>>>> In previous arguments over Drivechain (and Drivechain-like
> proposals) I promised that better scaling proposals ― that do not sacrifice
> Bitcoin's security ― would come along.
> >>>>>>>
> >>>>>>> I planned to do a detailed writeup, but have decided to just send
> off this email with what I have, because I'm unlikely to have time to write
> up a detailed proposal.
> >>>>>>>
> >>>>>>> The idea is very simple (and by no means novel*), and I'm sure
> others have mentioned either exactly it, or similar ideas (e.g. burning
> coins) before.
> >>>>>>>
> >>>>>>> This is a generic sharding protocol for all blockchains, including
> Bitcoin.
> >>>>>>>
> >>>>>>> Users simply say: "My coins on Chain A are going to be sent to
> Chain B".
> >>>>>>>
> >>>>>>> Then they burn the coins on Chain A, and create a minting
> transaction on Chain B. The details of how to ensure that coins do not get
> lost needs to be worked out, but I'm fairly certain the folks on this list
> can figure out those details.
> >>>>>>>
> >>>>>>> - Thin clients, nodes, and miners, can all very easily verify that
> said action took place, and therefore accept the "newly minted" coins on B
> as valid.
> >>>>>>> - Users client software now also knows where to look for the other
> coins (if for some reason it needs to).
> >>>>>>>
> >>>>>>> This doesn't even need much modification to the Bitcoin protocol
> as most of the verification is done client-side.
> >>>>>>>
> >>>>>>> It is fully decentralized, and there's no need to give our
> ownership of our coins to miners to get scale.
> >>>>>>>
> >>>>>>> My sincere apologies if this has been brought up before (in which
> case, I would be very grateful for a link to the proposal).
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Greg Slepak
> >>>>>>>
> >>>>>>> * This idea is similar in spirit to Interledger.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>
> >> _______________________________________________
> >> 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/20171010/2693944e/attachment-0001.html>

2023-06-07 20:07:01

- reply

📅 Original date posted:2017-10-10
📝 Original message:Your method would change the number of Bitcoins in existence. Why?
On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Is that what passes for a technical argument these days? Sheesh.
>
> Whereas in Drivechain users are forced to give up their coins to a single
> group for whatever sidechains they interact with, the generic sharding algo
> lets them (1) keep their coins, (2) trust whatever group they want to trust
> (the miners of the various sidechains).
>
> Drivechain offers objectively worse security.
>
> --
> Sent from my mobile device.
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I think this response speaks for itself.
>
> On 10/10/2017 10:09 AM, Tao Effect wrote:
>
> Hi Paul,
>
> I thought it was clear, but apparently you are getting stuck on the
> semantics of the word "burn".
>
> The "burning" applies to the original coins you had.
>
> When you transfer them back, you get newly minted coins, equivalent to the
> amount you "burned" on the chain you're transferring from — as stated in
> the OP.
>
> If you don't like the word "burn", pick another one.
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> Haha, no. Because you "burned" the coins.
>
> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com> wrote:
>
>> Paul,
>>
>> It's a two-way peg.
>>
>> There's nothing preventing transfers back to the main chain.
>>
>> They work in the exact same manner.
>>
>> Cheers,
>> Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with
>> the NSA.
>>
>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>
>> That is only a one-way peg, not a two-way.
>>
>> In fact, that is exactly what drivechain does, if one chooses parameters
>> for the drivechain that make it impossible for any side-to-main transfer to
>> succeed.
>>
>> One-way pegs have strong first-mover disadvantages.
>>
>> Paul
>>
>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Dear list,
>>
>> In previous arguments over Drivechain (and Drivechain-like proposals) I
>> promised that better scaling proposals — that do not sacrifice Bitcoin's
>> security — would come along.
>>
>> I planned to do a detailed writeup, but have decided to just send off
>> this email with what I have, because I'm unlikely to have time to write up
>> a detailed proposal.
>>
>> The idea is very simple (and by no means novel*), and I'm sure others
>> have mentioned either exactly it, or similar ideas (e.g. burning coins)
>> before.
>>
>> This is a generic sharding protocol for all blockchains, including
>> Bitcoin.
>>
>> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>>
>> Then they burn the coins on Chain A, and create a minting transaction on
>> Chain B. The details of how to ensure that coins do not get lost needs to
>> be worked out, but I'm fairly certain the folks on this list can figure out
>> those details.
>>
>> - Thin clients, nodes, and miners, can all very easily verify that said
>> action took place, and therefore accept the "newly minted" coins on B as
>> valid.
>> - Users client software now also knows where to look for the other coins
>> (if for some reason it needs to).
>>
>> This doesn't even need much modification to the Bitcoin protocol as most
>> of the verification is done client-side.
>>
>> It is fully decentralized, and there's no need to give our ownership of
>> our coins to miners to get scale.
>>
>> My sincere apologies if this has been brought up before (in which case, I
>> would be very grateful for a link to the proposal).
>>
>> Cheers,
>> Greg Slepak
>>
>> * This idea is similar in spirit to Interledger.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with
>> the NSA.
>>
>>
>> _______________________________________________
>> 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/20171010/de8cb97c/attachment.html>

2023-06-07 20:06:21

- reply

📅 Original date posted:2017-09-27
📝 Original message:I do agree with you to a degree, but address reuse is actually not even
supposed to work (it is a bug). Peter Todd is suggesting only to make
expiration a part of a new address format, and we could have a GUI
warning (but no protocol change) for the existing formats. What do you
think about that?
On 09/27/2017 01:23 PM, Nick Pudar via bitcoin-dev wrote:
>
> As a long term silent reader of this list, I felt compelled to comment
> on this address expiration topic. I don't believe that address
> expiration should be part of the protocol. I think instead that the
> "sending" feature should by default offer guidance to request a fresh
> address from the recipient. Also allow the receiver of funds to be
> able to generate an "invoice" that the sender acts on.
>
>
> I also think that re-directs are fraught with privacy issues. At the
> end of the day, the ultimate burden is on the sender (with much self
> interest from the receiver) that the correct address is being used.
>
>
>
> ------------------------------------------------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org
> <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Chris
> Priest via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Wednesday, September 27, 2017 3:35 PM
> *To:* Peter Todd; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] Address expiration times should be added
> to BIP-173
>
> A better solution is to just have the sending wallet check to see if
> the address you are about to send to has been used before. If it's a
> fresh address, it sends it through without any popup alert. If the
> address has history going back a certain amount of time, then a popup
> comes up and notifies the sender that they are sending to a non-fresh
> address that may no longer be controlled by the receiver anymore.
>
> Also, an even better idea is to set up an "address expiration
> service". When you delete a wallet, you first send off an "expiration
> notice" which is just a message (signed with the private key) saying
> "I am about to delete this address, here is my new address". When
> someone tries to send to that address, they first consult the address
> expiration service, and the service will either tell them "this
> address is not expired, proceed", or "this address has been expired,
> please send to this other address instead...". Basically like a 301
> redirect, but for addresses. I don't think address expiration should
> be part of the protocol.
>
> On Wed, Sep 27, 2017 at 10:06 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Re-use of old addresses is a major problem, not only for privacy,
> but also
> operationally: services like exchanges frequently have problems
> with users
> sending funds to addresses whose private keys have been lost or
> stolen; there
> are multiple examples of exchanges getting hacked, with users
> continuing to
> lose funds well after the actual hack has occured due to
> continuing deposits.
> This also makes it difficult operationally to rotate private keys.
> I personally
> have even lost funds in the past due to people sending me BTC to
> addresses that
> I gave them long ago for different reasons, rather than asking me
> for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level
> expiration time
> to the new BIP173 address format. Wallets would be expected to
> consider
> addresses as invalid as a destination for funds after the
> expiration time is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and
> terminology
> questions. Notably, the entire notion of addresses is flawed from
> a user point
> of view: their experience with them should be more like "payment
> codes", with a
> code being valid for payment for a short period of time; wallets
> should not be
> displaying addresses as actually associated with specific funds. I
> suspect
> we'll see users thinking that an expired address risks the funds
> themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is
> unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level
> regardless of
> timezone: the former is sufficiently short that UI's can simply
> display an
> "exact" time (though note different leap second interpretations),
> while the
> latter is long enough that rounding off to the nearest day in the
> local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the
> advantage of making
> it easy for services like exchanges to use addresses with
> relatively short
> validity periods, to reduce the risks of losses after a hack.
> Also, using at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> <http://petertodd.org>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
>
> --
> Chris Priest
> 786-531-5938
>
>
> _______________________________________________
> 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/20170927/c2fbfa44/attachment-0001.html>

2023-06-07 20:06:21

- reply

📅 Original date posted:2017-09-27
📝 Original message:See https://github.com/bitcoin/bitcoin/pull/9722
What still needs to be done is that during the first start up after
updating with this popup, the wallet needs to scan for addresses that
have been used in the past. That way the popup isn't only shown for
addresses that are reused after updating.
On 09/27/2017 12:35 PM, Chris Priest via bitcoin-dev wrote:
> A better solution is to just have the sending wallet check to see if
> the address you are about to send to has been used before. If it's a
> fresh address, it sends it through without any popup alert. If the
> address has history going back a certain amount of time, then a popup
> comes up and notifies the sender that they are sending to a non-fresh
> address that may no longer be controlled by the receiver anymore.
>
> Also, an even better idea is to set up an "address expiration
> service". When you delete a wallet, you first send off an "expiration
> notice" which is just a message (signed with the private key) saying
> "I am about to delete this address, here is my new address". When
> someone tries to send to that address, they first consult the address
> expiration service, and the service will either tell them "this
> address is not expired, proceed", or "this address has been expired,
> please send to this other address instead...". Basically like a 301
> redirect, but for addresses. I don't think address expiration should
> be part of the protocol.
>
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/305de41f/attachment-0001.html>

2023-06-07 20:06:19

- reply

📅 Original date posted:2017-09-27
📝 Original message:I think we need something like this. Hour resolution seems like the
correct choice to me.
Please someone steal whatever code you can from this PR when
implementing the UI for BIP173 expiration:
https://github.com/bitcoin/bitcoin/pull/9722
I have a rebased version as well if anyone wants it.
On 09/27/2017 09:06 AM, Peter Todd via bitcoin-dev wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen; there
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I personally
> have even lost funds in the past due to people sending me BTC to addresses that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
>
>
> _______________________________________________
> 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/20170927/e671823a/attachment-0001.html>

2023-06-07 20:05:51

- reply

📅 Original date posted:2017-09-10
📝 Original message:I don't think we should put any Bitcoin users at additional risk to help
altcoins. If they fork the code they are making maintenance their own
responsibly.
It's hard to disclose a bitcoin vulnerability considering the network is
decentralised and core can't force everyone to update. Maybe a timeout
period for vulnerabilities could be decided. People might be expected to
patched before then at which point the vulnerability can be published. Is
that not already sort of how it works?
On Sep 10, 2017 4:10 PM, "Matt Corallo via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe there continues to be concern over a number of altcoins which
> are running old, unpatched forks of Bitcoin Core, making it rather
> difficult to disclose issues without putting people at risk (see, eg,
> some of the dos issues which are preventing release of the alert key).
> I'd encourage the list to have a discussion about what reasonable
> approaches could be taken there.
>
> On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
> > Hi,
> >
> > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
> > conference, and the subsequent discussion around responsible disclosure
> > and industry practice, perhaps now would be a good time to discuss
> > "Bitcoin and CVEs" which has gone unanswered for 6 months.
> >
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013751.html
> >
> > To quote:
> >
> > "Are there are any vulnerabilities in Bitcoin which have been fixed but
> > not yet publicly disclosed? Is the following list of Bitcoin CVEs
> > up-to-date?
> >
> > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
> >
> > There have been no new CVEs posted for almost three years, except for
> > CVE-2015-3641, but there appears to be no information publicly available
> > for that issue:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
> >
> > It would be of great benefit to end users if the community of clients
> > and altcoins derived from Bitcoin Core could be patched for any known
> > vulnerabilities.
> >
> > Does anyone keep track of security related bugs and patches, where the
> > defect severity is similar to those found on the CVE list above? If
> > yes, can that list be shared with other developers?"
> >
> > Best Regards,
> > Simon
> > _______________________________________________
> > 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/20170910/1b3bfb59/attachment.html>

2023-06-07 20:05:25

- reply

📅 Original date posted:2017-09-07
📝 Original message:After reading
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
I see that Adam is correct. Unfortunately this SF would make Felix's
confidential transactions
more complicated. The blinding and unblinding transactions would have to
be created with
minimal output values, and this will need to be considered when checking
that the fee is equal
to the total amount of input. (it would now be SUM(inputs) -
SUM(minimalOutputs))
Blinding transaction:
Ins:
All non-confidential inputs are valid
Outs:
- 0..N: (new confidential outputs)
amount: 0
scriptPubkey: OP_2 <0x{32-byte-hash-value}>
witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
- last:
amount: 0
scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
Fee: Sum of the all inputs value
However, looking at the format of the blinding transaction, and how the
GCTXO is added to the UTXO set
by miners, it seems that a change to the blinding scriptPubKey could
allow for the use of 0 value
outputs. Even with the SF proposed by this email thread.
OP_RETURN could be added to the scriptPubKey during blinding. The amount
and scriptPubKey destination of
unblinded funds is part of the witness and the outputs of an unblinded
transaction are unspendable, so
why not also make them unspendable in the blind transaction? As far as I
can tell those outputs don't need to
be spendable, they are really just encoding data. It doesn't seem like
anything besides the confidential base
transaction and the fee output from the blind transaction need to be in
the UTXO set.
Is it still possible to add this data to the witness if the scriptPubKey
is unspendable? :
witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
I think I'm missing something obvious, someone point out why this is
stupid please :)
On 09/06/2017 06:29 PM, Adam Back wrote:
> The pattern used by Felix Weiss' BIP for Confidential Transactions
> depends on or is tidier with 0-value outputs.
>
> Adam
>
>
> On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> As long as an unspendable outputs (OP_RETURN outputs for example) with
>> amount=0 are still allowed I don't see it being an issue for anything.
>>
>> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev"
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> This is not a priority, not very important either.
>>> Right now it is possible to create 0-value outputs that are spendable
>>> and thus stay in the utxo (potentially forever). Requiring at least 1
>>> satoshi per output doesn't really do much against a spam attack to the
>>> utxo, but I think it would be slightly better than the current
>>> situation.
>>>
>>> Is there any reason or use case to keep allowing spendable outputs
>>> with null amounts in them?
>>>
>>> If not, I'm happy to create a BIP with its code, this should be simple.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

2023-06-07 20:05:24

- reply

📅 Original date posted:2017-09-06
📝 Original message:As long as an unspendable outputs (OP_RETURN outputs for example) with
amount=0 are still allowed I don't see it being an issue for anything.
On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is not a priority, not very important either.
> Right now it is possible to create 0-value outputs that are spendable
> and thus stay in the utxo (potentially forever). Requiring at least 1
> satoshi per output doesn't really do much against a spam attack to the
> utxo, but I think it would be slightly better than the current
> situation.
>
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
> If not, I'm happy to create a BIP with its code, this should be simple.
> _______________________________________________
> 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/20170906/83476b7f/attachment.html>

2023-06-07 20:04:19

- reply

📅 Original date posted:2017-07-12
📝 Original message:Are we just pulling numbers out of thin air now? https://p2sh.info/
BIP16 for example is widely used. It would be difficult to find a single
wallet that doesn't support BIP16 I have no idea what you are talking about.
On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
> ...
> In the present situation, anyone-can-spend outputs are used by
> probably less than 0.1% of users, and most software doesn't even allow
> for the possibility.
>
> In Drivechain it's *encouraged-by-design*!
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/a11413d2/attachment-0001.html>

2023-06-07 20:04:14

- reply

📅 Original date posted:2017-07-11
📝 Original message:If users can opt-in to another security model, why can't they opt-in to
another scaling model? The mainchain (Bitcoin) does not have to adopt
any of the changes made to a sidechain such as larger blocks for example.
On 07/11/2017 01:01 PM, Pieter Wuille via bitcoin-dev wrote:
> On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Concept ACK.
>
> If drivechains are successful they should be viewed as the way we
> scale
>
>
> I strongly disagree with that statement.
>
> Drivechains, and several earlier sidechains ideas, are not a
> scalability improvement, but merely enabling users to opt-in for
> another security model.
>
> While obviously any future with wider adoption will need different
> technologies that have different trade-offs, and anyone is free to
> choose their security model, I don't think this particular one is
> interesting. In terms of validation cost to auditors, it is as bad as
> just a capacity increase on chain, while simultaneously adding the
> extra risk of miners being able to vote to steal your money.
>
> Cheers,
>
> --
> Pieter
>
>
>
> _______________________________________________
> 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/20170711/1de23cb2/attachment.html>

2023-06-07 20:01:31

- reply

📅 Original date posted:2017-05-24
📝 Original message:Your assumptions of the bribe process are indeed correct you seem to
have a pretty good handle on all of that.
Hopefully I can clear up a few things. BMM among other things is still a
work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on
github right now just has the block hash
part of the critical hash script. The completed version needs to check
the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1
or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.
Here's what the script looks like on github:
Note that the h* is just a block hash.
script << OP_RETURN << ToByteVector(h*);
Here's what I'm testing right now as I'm working on BMM:
script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block
hash h*)
One other thing I want to make sure is clear enough is that the block
number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess
up the new format you have
suggested for bribes. And the reason a sidechain miner would want to
refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded
block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.
We were thinking about making bribe outputs have a maturity period like
generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also
check the lock time?
I like all of your suggestions so far, thank you for taking a look!
On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
> On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan at gmail.com
> <mailto:tier.nolan at gmail.com>> wrote:
>
> OP_BRIBE_VERIFY could then operate as follows
>
> <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> This causes the script to fail if
> <block height> does not match the block height, or
> <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
> there is no hash for that sidechain in the block's coinbase
>
>
> I was thinking more on the process for these transactions.
>
> I assume that the process is
>
> - sidechain miner broadcasts transaction with OP_BRIBE output
> - this transaction ends up in the memory pool of miners
> - Miners add the transaction to their next block
> - Miners add a transaction which spends the output to one of their own
> addresses
>
> I think you need an additional rule that OP_BRIBE checks fails unless
> the output is locked 100 or more blocks.
>
> The output script would end up something like
>
> IF
> <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
> ELSE
> <public key> OP_CHECKSIG
> ENDIF
>
> This output acts like "anyone can spend" for the one block height.
> Otherwise, only the sidechain miner can spend the output.
>
> This allows the sidechain miner to reclaim their coins if the
> transaction ends up in a different block.
>
> OP_BRIBE_VERIFY would have an additional rule
>
> The script to fails if
> one or more of the transaction outputs start with something other
> than the template
> <block height> does not match the block height, or
> <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
> there is no hash for that sidechain in the block's coinbase
>
> The template is
> <100> OP_CHECKSEQUENCE_VERIFY
>
>
> _______________________________________________
> 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/20170524/6970f30f/attachment-0001.html>