CryptAxe [ARCHIVE]

⚠️ 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.

Public Key

npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309

Profile Code

nprofile1qqs9qlfpvcx5rmrx5r37fp483feknar55wyvpt8t6uzr8wayfnf2grgxhx6et

Author Public Key

npub12p7jzesdg8kxdg8rujr20znnd868fgugczkwh4cyxwa6gnxj5sxsnjs309

Show more details

Last Notes

2023-06-07 18:14:52

- reply

📅 Original date posted:2018-09-25
📝 Original message:Feel free to take a look at my implementation of UTXO loading (for core
~0.16.99) here:
https://github.com/DriveNetTESTDRIVE/DriveNet/commit/60189ea9a23865180e25207ecf66f95d84f642c6
Note that this has consensus implications, and that there are bugs (some of
which are fixed in later commits to that repository)
On Tue, Sep 25, 2018 at 4:56 PM Damian Williamson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> A fairly decent rework would be needed but it seems that the idea has
> merit initially.
>
>
> As it is now, it is not only that a utxo exists but, that the transaction
> it references and the block it is within can also be fully validated.
>
>
> So, if a utxo block set type existed then by consensus every so often a
> bunch of blocks containing just the validated utxo set to a given height,
> say 100,000 blocks below the current blockheight, and necessary header data
> could be appended onto the valid chain and nodes would be free to drop all
> preceding blocks. I suspect that many wouldn't and that even many new nodes
> would still desire to download the full blockchain but, for the use case
> you mention it would make sense.
>
>
> If done [right/wrong] it may even make Satoshi's fortune spendable.
> Something to watch out for.
> ------------------------------
> *From:* bitcoin-discuss-bounces at lists.linuxfoundation.org <
> bitcoin-discuss-bounces at lists.linuxfoundation.org> on behalf of Dave
> Scotese via bitcoin-discuss <bitcoin-discuss at lists.linuxfoundation.org>
> *Sent:* Wednesday, 26 September 2018 1:46:54 AM
> *To:* Bitcoin Discuss
> *Subject:* Re: [bitcoin-discuss] Proposal to replace full blockchain with
> recent history plus UTXO Set
>
> The image at imgur and the pastebin both reference block 542324 but the
> correct block is 542322. As the pastebin shows, the decimal and hex
> representations I gave for the block height did not match, and this is
> why. If you use the Merkle root for block 542322 instead of 542324, you'll
> be able to see the correct Game of Life play out and make the apron image.
>
> Dave.
>
> On Sun, Sep 23, 2018 at 11:38 AM Dave Scotese <dscotese at litmocracy.com>
> wrote:
>
> I thought I didn't have access to the dev list and so intended to post the
> following proposal to this discussion list, but used the wrong email
> address. Anyway, my email did get into the dev list (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016420.html)
> but I'll repeat it here:
>
> I've been working on an idea that relieves full nodes of storing the
> entire blockchain. Open source software generally relies on the fact that
> "enough" people agree that it's secure. Bitcoin software works that way
> too. So if you understand enough to see that a UTXO set is valid at a
> certain block height, and there are enough other people who agree and that
> set is recognizable by humans, then we can use that UTXO set and ditch the
> blockchain that existed up to that point. It would save a lot of storage
> and make it a lot easier to run a full node.
>
> Have you reviewed the source code from which your wallets were compiled?
> At some point, we all trust third parties, but generally (at least among
> people who understand Bitcoin) they are large composite groups so that no
> small group or individual can profit from cheating.
>
> I look forward to answering any concerns and also to any offers of help.
> I used block 542324 of the Bitcoin blockchain to make a memorable
> experience using the game of life. I wrote a script for the open-source
> Game-of-Life software Golly and shared it in the paste at
> https://pastebin.com/k5Ssc0qk. It produces the image at
> https://imgur.com/a/rwIQuVz. If someone can tell me how to get a UTXO Set
> from the bitcoin client, I'll send them $50 of bitcoin. Then I could get
> the SHA256 hash of that set and try to make a recognizable checkpoint for
> the Bitcoin blockchain. If someone runs Golly and shares a video of the
> game playing out (into the apron-shaped image), I'll send them $50 of
> bitcoin too.
>
> In a few decades when the blockchain has grown to a few terabytes and the
> UTXO Set is still just a few gigabytes, I'd like to see more people start
> running full nodes without the hassle of a long wait and loads of storage
> space. That's what stops me from running one.
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
> _______________________________________________
> 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/20180925/13bd5761/attachment.html>

2023-06-07 18:13:59

- reply

📅 Original date posted:2018-08-05
📝 Original message:Don't worry about claiming it. There are no reserved prefixes enforced by
the software. For example anyone could create an output that uses the
witness coinbase commitment prefix bytes. It would just be ignored (unless
it was in the coinbase, in which case it would also need to be valid).
On Sun, Aug 5, 2018, 6:47 PM Lautaro Dragan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks Peter for your prompt reply.
>
> And now that I think of it you're right - as easy as it is for us to
> differentiate OP_RETURN outputs that contain the Po.et prefix it would be
> for miners to block those transactions altogether. Is this what you mean?
>
> Still, a prefix is something we may have to live with for a little while
> until we can address that issue.
>
> Is there a formal / standard process to claim it we should follow?
>
>
>
>
> El dom., 5 de ago. de 2018 a la(s) 20:58, Peter Todd <pete at petertodd.org>
> escribió:
>
>>
>>
>> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >Hi everyone,
>> >
>> >My name's Lautaro and I'm currently acting as Tech Lead of Po.et
>> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
>> >use
>> >colored coins
>> ><
>> https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110
>> >
>> >to
>> >store data on the Bitcoin blockchain with prefix "POET".
>> >
>> >I've read in an old version of the OP_RETURN entry of the bitcoin wiki
>> ><https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
>> >*protocols
>> >wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>> >Improvement Proposals process*.
>> >
>> >That entry seems to have changed recently
>> ><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
>> >stating that we should follow the BIP process, and I haven't been able
>> >to
>> >find any existing BIP claiming an OP_RETURN prexif, but for the sake of
>> >thoroughness I'd like to ask for your help or confirmation here.
>> >
>> >Should we actually be using the BIP process to claim a prefix?
>>
>> It's better if you don't use a prefix at all from a censorship resistance
>> and anonymity perspective; you're application should not require a prefix
>> for technical reasons.
>>
>> --
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180805/616dd36b/attachment.html>

2023-06-07 18: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 18:09:53

- reply

📅 Original date posted:2018-01-18
📝 Original message:Technically the change would be an improvement. People should be allowed to
opt-in to systems and big changes like that though, not have developers
change what their outputs mean or open them up to new security risks on
their behalf.
On Jan 18, 2018 11:30 AM, "Gregory Maxwell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> A common question when discussing newer more efficient pubkey types--
> like signature aggregation or even just segwit-- is "will this thing
> make the spending of already existing outputs more efficient", which
> unfortunately gets an answer of No because the redemption instructions
> for existing outputs have already been set, and don't incorporate
> these new features.
>
> This is good news in that no one ends up being forced to expose their
> own funds to new cryptosystems whos security they may not trust. When
> sigagg is deployed, for example, any cryptographic risk in it is borne
> by people who opted into using it.
>
> Lets imagine though that segwit-with-sigagg has been long deployed,
> widely used, and is more or less universally accepted as at least as
> good as an old P2PKH.
>
> In that case, it might be plausible to include in a hardfork a
> consensus rule that lets someone spend scriptPubkey's matching
> specific templates as though they were an alternative template. So
> then an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent
> as though it used the analogous p2w-sigagg script.
>
> The main limitation is that there is some risk of breaking the
> security assumptions of some complicated external protocol e.g. that
> assumed that having a schnorr oracle for a key wouldn't let you spend
> coins connected to that key. This seems like a pretty contrived
> concern to me however, and it's one that can largely be addressed by
> ample communication in advance. (E.g. discouraging the creation of
> excessively fragile things like that, and finding out if any exist so
> they can be worked around).
>
> Am I missing any other arguments?
> _______________________________________________
> 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/20180118/938ee169/attachment.html>

2023-06-07 18: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 18:08:22

- reply

📅 Original date posted:2017-12-05
📝 Original message:Perhaps instead of a flag that can be used to disable a specific operation,
there should be a "-ignoredflags=x,y,z" section of the URI that can be used
to ignore whatever BIP this might also be useful for in the future?
On Dec 5, 2017 11:34 AM, "Sjors Provoost via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125
> [0]. It allows wallets to recommend lower fees, because if a transaction
> gets stuck due to underestimation, the fee can easily be bumped.
>
> Bitcoin Core has had support for RBF for a while, and as of v0.15.0
> recommends lower fees [1] when the user chooses to use RBF.
>
> I recently submitted a pull request that would turn on RBF by default,
> which triggered some discussion [2]. To ease the transition for merchants
> who are reluctant to see their customers use RBF, Matt Corallo suggested
> that wallets honor a no125=1 flag.
>
> So a BIP-21 URI would look like this: bitcoin:175t...45W?amount=20.
> 3&no125=1
>
> When this flag is set, wallets should not use RBF, regardless of their
> default, unless the user explicitly overrides the merchant's preference.
>
> Afaik adding this flag won't break existing BIP-21 support. It doesn't use
> the req- prefix, because it's optional. I'm also not aware of any ad hoc
> standards that use no125 in BIP-21-ish URIs.
>
> - Sjors
>
> P.S. I'd similarly suggest adding a bech32 param, but that's for another
> discussion
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
> [1] https://bitcoincore.org/en/2017/09/01/release-0.15.0/#
> better-fee-estimates
> [2] https://github.com/bitcoin/bitcoin/pull/11605
> [3] https://github.com/bitcoin/bitcoin/issues/11828
>
> _______________________________________________
> 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/20171205/923ac704/attachment-0001.html>

2023-06-07 18:08:21

- reply

📅 Original date posted:2017-12-05
📝 Original message:On Dec 5, 2017 12:00 PM, "Sjors Provoost" <sjors at sprovoost.nl> wrote:
...
I don't think all BIPs lend themselves to this pattern. Can you think of
another example?
Not right now, just seemed like a good idea to consider making it useful
for more than one thing (maybe CT or something else could use it in the
future?).
I also suspect each ignored flag requires carefully defined behavior, so
it's probably better to spell that out in the BIP.
Sjors
Agreed, no reason they couldn't reuse the same section of the payment
request URI though. (And define that behavior in the BIP)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/f2230fff/attachment.html>

2023-06-07 18:08:11

- reply

📅 Original date posted:2017-12-06
📝 Original message:On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote:
> ...
> This vulnerability can be fixed if withdrawals are restricted to
> simple P2PKH or P2WPKH only,
Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there
be any network benefit to supporting witness pubkeys for withdrawals?)
wouldn't be too much work for me. The downside is that people might want
to withdraw to multisig scripts, or any other legitimate P2SH. If it
prevents a huge issue, then it is probably worth it.
> but in the presence of Scriptless Script and Bellare-Neven signatures,
> that may be sufficient to create the Theft Contract and the Accomplice
> Contract (but I know too little of Scriptless Script to be sure).
>
> Regards,
> ZmnSCPxj
>
I'm curious if anyone on this list could help answer this.
Thanks!

2023-06-07 18: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 18: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 18: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 18: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 18: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 18: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 18:06:12

- reply

📅 Original date posted:2017-09-25
📝 Original message:Have you taken a look at Elements or Drivechains yet by chance?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170925/0ce30d83/attachment.html>

2023-06-07 18: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 18: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 18: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 18:04:24

- reply

📅 Original date posted:2017-07-12
📝 Original message:You guys are both right that it is a different security model, with the
important distinction that it is opt-in. What I disagree with about what
you said is only that we are encouraging more risky behavior by adding
consensus rules via softfork. There are additional risks with
drivechains, but not because of how the new consensus rules would be
added (it would be the same risk as the P2SH softfork).
What's been explained to me a few times is that the
anyone-can-spend-ness of new transaction types that depend on softforked
consensus rules are exponentially less risky to the point that it is
infeasible to steal them as blocks are added to the chain that activated
the soft fork. I believe that Luke-Jr and Lopp are both very good at
explaining this and I know that Lopp has actually done some research as
to the cost of stealing these outputs. I can't remember the link but you
might find that with a google. One of them might even chime in and
explain that I'm totally wrong again!
Sorry for being a bit heated in my last response.
On 07/12/2017 02:55 PM, Tao Effect wrote:
> That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].
>
> Isn't it different in the case of P2SH and SegWit, don't full nodes
> validate the script?
>
> In other words, miners don't have complete control over the coins,
> full nodes keep a check on them.
>
> At least that was my understanding, and if that's not the case then it
> doesn't make sense to me why Pieter would earlier in this thread
> object to Drivechain on the grounds that it's a different security model.
>
> - Greg
>
> [1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes
>
>
> --
> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
>
>> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> 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.
>>>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/c5024186/attachment.html>

2023-06-07 18: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 18: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 18:03:54

- reply

📅 Original date posted:2017-07-12
📝 Original message:In case anyone wants to do this, I added the CSidechainAddress class to the
mainchainBMM branch of the Drivechain project a long time ago. The only
purpose it serves right now is to show that sidechain deposit addresses can
start with a '4'. We could simply add the sha256 hash described by Paul to
a script with OP_RETURN at the front and make that the standard.
On Jul 12, 2017 4:47 PM, "Paul Sztorc via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
On 7/12/2017 4:50 AM, ZmnSCPxj wrote:
...
That said, I am fully in favor of forcing the sidechain's permanent
deposit address to be equal to some deterministic function of the sha256
hash of its version 0.1 release.
Paul
_______________________________________________
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/20170712/908a011a/attachment.html>

2023-06-07 18:03:45

- reply

📅 Original date posted:2017-06-30
📝 Original message:To ZmnSCPxj:
I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
But I suppose you are considering something like the Ethereum mutability
feature, which I do not think is something you would want in a sidechain.
The goal was to allow for sidechain reorgs without effecting the mainchain
at all. With the ratchet system (WIP) the sidechain miners can either move
the side chain forward or start a split at some previous sidechain block
height. This happens as the main chain moves forward normally.
>From your other emails on this list, it seems the ratchet is for
withdrawals from sidechain to mainchain? ...
The ratchet system is actually what links the h* data from bribes to
sidechain blocks. h*'s (which are sidechain block hashes) are added to the
ratchet system if they move the sidechain forward or start a split like I
mentioned before. Then a sidechain can request of their local mainchain
node to verify the headers they have downloaded from sidechain peers and
form the side chain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170630/9a6557d5/attachment-0001.html>

2023-06-07 18:02:56

- reply

📅 Original date posted:2017-06-18
📝 Original message:> >OP_RETURN <sidechain_id> <critical hash>
>
> I think it is redundant here to have the <sidechain id>, we can
> implicitly assume what the sidechain_id is since we have a fixed set
> of drivechains. I.e. mining reward is index 0, mimblewimble sidechain
> is index 1, etc. CryptAxe has specific indexes defined already in his
> implementation:
> https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30.
>
Since the sidechain has the sidechain BMM headers that they want the LD
(bribe) data for, I think that they could specifically request LD data
relevant only to that sidechain by providing a list of hashes to the
mainchain, and the mainchain can return a list of boolean values telling
the sidechain if the LD data exists. That way the data never even has to
go over the network, just a verification that it exists on the mainchain
and we can drop the sidechain_id from the script.
> I think it would be wise to include a version byte to allow us to
> upgrade this commitment structure in the future. Similar to how
> witness program's are now versioned.
Agreed, we need that.
>
> ><block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> If <block height> is an argument that OP_BRIBE_VERIFY takes, doesn't
> that mean the mainchain miner has to validate this *is* the actual
> block height on the sidechain? Does that take the 'blindness' away
> from BMM?
No, OP_BRIBE (the old version) didn't care about the block height. Where
the blockheight was relevant is when bribe data is added to LD. In order
to be added to LD, the bribe needed to either be a fork (block height
less than the sidechain tip height) or extending the current side-chain
(block height = sidechain tip height + 1). The goal of this was to allow
for reorgs, and also make it so that people cannot skip forward (which
would never be valid so it's a waste of time and space) so that the
sidechain makes progress. With the new design that we have been talking
about, I think that we will need to drop this requirement from the
mainchain, and have the sidechain handle filtering out invalid LD data /
only requesting the verification of LD data that they know to be valid
as far as chain order goes.
>
> Overall, I think we need to work on the commitment structure to the
> coinbase tx.
Agreed. It might be helpful if you outlined the idea you had on IRC to
the mailing list.
> If I understand the current implementation correctly we can have up to
> 256 OP_RETURNs embedded in the coinbase tx signifying new blocks mined
> on drivechains.. this seems less than ideal. It might be prudent to
> make these outputs ANYONECANSPEND, and then have miners spending these
> outputs to themselves for every block mined.. maybe this doesn't have
> a benefit over using OP_RETURNs though?
>
> The structure could be something like:
> <version> <critical hash>
>
> and then in a subsequent block the miner spends that output to
> themselves. I will admit I'm not super familiar with how OP_RETURNs
> work with the UTXO set -- maybe this scheme doesn't have any benefit.
>
> -Chris
I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

2023-06-07 18: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>