digitsu at gmail.com [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:45:45

- reply

📅 Original date posted:2015-12-12
📝 Original message:If this means essentially that a soft fork deployment of SegWit will require SPV wallet servers to change their logic (or risk not being able to send payments) then it does seem to me that a hard fork to deploy this non controversial change is not only cleaner (on the data structure side) but safer in terms of the potential to affect the user experience.
—
Regards,
On Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> This is basically what I meant by
>>
>> struct hashRootStruct
>> {
>> uint256 hashMerkleRoot;
>> uint256 hashWitnessesRoot;
>> uint256 hashextendedHeader;
>> }
>>
>> but my design doesn't calculate other_root as it appears in your tree (is
>> not necessary).
>>
>> It is necessary to maintain compatibility with SPV nodes/wallets.
> Any code that just checks merkle paths up into the block header would have
> to change if the structure of the merkle tree changed to be three-headed at
> the top.
> If it remains a binary tree, then it doesn't need to change at all-- the
> code that produces the merkle paths will just send a path that is one step
> deeper.
> Plus, it's just weird to have a merkle tree that isn't a binary tree.....
> --
> --
> Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151211/63cf45aa/attachment.html>

2023-06-07 17:44:37

- reply

📅 Original date posted:2015-11-13
📝 Original message:Well I'd like to think that with an economy all parts of it interact with each other in ways more complex than simplistic imperative logic.
I agree that the economic majority is essentially what matters in a hard fork but everyone (miners,devs,public thought leaders,businesses) is part of that economy. Additionally what miners signal as their intention affects the decision of that economic majority (and vice versa). You can see the effects of this in traditional political processes in how preliminary vote polling results affect (reinforce) the final vote.
We also can see the results of this in (dare I mention) the whole XT affair which had the signed intent of many of the economy (payment processors and wallets and one miner pool) and the rest of the miners did not go along with it. This experiment either means that the rest of the miners couldn't be bothered to signal at all (because they didn't know how) or they were affected by the influence of core devs or the opinions of others on the matter and rejected the economic majority. (Which would imply core devs have some power by way of indirect influence) I would be inclined to believe the latter was more likely.
The conclusion which this would seem to imply is that at the very least, miners matter (to what exact extent is debatable). And although there is no direct control of any party over the other in the strict sense, the public vocal opinions of any part of the Bitcoin economy does have an effect in its ability to sway the opinions of the other parts.
Digitsu
—
Regards,
On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke at dashjr.org> wrote:
> On Friday, November 13, 2015 4:01:09 PM digitsu at gmail.com wrote:
>> Forgive the frankness but I don't see why signaling your intent to support
>> an upgrade to one side of a hard fork can be seen as a bad thing. If for
>> nothing else doesn't this make for a smoother flag day? (Because once you
>> signal your intention, it makes it hard to back out on the commitment.)
> It isn't a commitment in any sense, nor does it make it smoother, because for
> a hardfork to be successful, it is the *economy* that must switch entirely.
> The miners are unimportant.
>> If miners don't have any choice in hard forks, who does? Just the core
>> devs?
> Devs have even less of a choice in the matter. What is relevant is the
> economy: who do people want to spend their bitcoins with? There is no
> programmatic way to determine this, especially not in advance, so the best we
> can do is a flag day that gets called off if there isn't clear consensus.
> Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/5cadc0d6/attachment.html>

2023-06-07 17:42:15

- reply

📅 Original date posted:2015-10-01
📝 Original message:Because Bitcoin XT is 1.0.0
;-)
---------- Forwarded message ----------
From: Marcel Jamin <marcel at jamin.net>
Date: 2015-10-01 11:39 GMT+02:00
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
To: Btc Drak <btcdrak at gmail.com>
I guess the question then becomes why bitcoin still is <1.0.0
I'd say it's safe to say that it's used in production.
—
Regards,
On Thu, Oct 1, 2015 at 6:57 PM, null
<bitcoin-dev-request at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
> Today's Topics:
> 1. Re: Design Competition (odinn)
> 2. Re: Bitcoin Core 0.12.0 release schedule
> (Wladimir J. van der Laan)
> 3. Re: Bitcoin Core 0.12.0 release schedule (Marcel Jamin)
> 4. Re: Bitcoin Core 0.12.0 release schedule (Btc Drak)
> 5. Fwd: Bitcoin Core 0.12.0 release schedule (Marcel Jamin)
> 6. Re: Fwd: Bitcoin Core 0.12.0 release schedule
> (Wladimir J. van der Laan)
> ----------------------------------------------------------------------
> Message: 1
> Date: Thu, 01 Oct 2015 04:38:50 +0000
> From: odinn <odinn.cyberguerrilla at riseup.net>
> To: Richard Olsen <richard.olsen at lykkex.com>, bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Design Competition
> Message-ID: <560CB8DA.6060801 at riseup.net>
> Content-Type: text/plain; charset=windows-1252
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> Grosses me out that you have enforced KYC as part of what you are
> doing for anyone who would decide to get involved:
> https://wiki.lykkex.com/?id=start#lykke_citizens
> Good luck with that, I'm sure not going to be a part of it, and I
> recommend that no-one else does either.
> - - O
> Richard Olsen via bitcoin-dev:
>> All,
>>
>> We are looking for participants in a Bitcoin related competition:
>> the aim is to build a trading platform (initially for foreign
>> exchange, other assets will follow) which lets participants settle
>> their trades through the blockchain via coloured coins. To
>> facilitate a quicker trade reconciliation, the use of a sidechain
>> is a suggestion but by no means a requirement. There will be an
>> online briefing event today where we will outline the requirements
>> in more detail, though much of it we have posted on our website
>> www.lykkex.com .
>>
>> As we want this to be a community driven effort rather than
>> something turning into a proprietary technology, all contributions
>> will be made available under a MIT license on Github.
>>
>> I look forward to answering your questions at the online briefing
>> event or over email,
>>
>> Thank you and kind regards, Richard Olsen
>>
>>
>>
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> iQEcBAEBCgAGBQJWDLjaAAoJEGxwq/inSG8CkQAH/i6603ivtZXjNw5ZlH1W2p7z
> c88sb5CcTuTUi+zEx6Q0MRUFfdYcrcBrGsua3CKU9226rpL4acD2Bby5kUPZ1h2/
> Rl5EiZa11oeqZaZaO5ZmXZ33BOaO2gxqqYEF1zBOzDgky6cqRrj8t4VAj5CKsxsP
> ktM98UqVXdcuOfBP7y/xqX1Yw9e55PpwUCtaazLo8UkPLMrtdzrbKVZBtjqGxMnG
> ZxmYku8g6xdmZAMz9xn9oVGtuMHrEjhIVycz3FMHBjoZNLE9yK4YeWyEvLI4YPFt
> KBR7HvGDava3dzMM5ugw3hgFShfegjrIunWQ/vC9RCjBMLVGVX5RgEblgQe29eY=
> =41DC
> -----END PGP SIGNATURE-----
> ------------------------------
> Message: 2
> Date: Thu, 1 Oct 2015 10:50:59 +0200
> From: "Wladimir J. van der Laan" <laanwj at gmail.com>
> To: Luke Dashjr <luke at dashjr.org>
> Cc: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
> Message-ID: <20151001085058.GA10010 at amethyst.visucore.com>
> Content-Type: text/plain; charset=utf-8
> On Wed, Sep 30, 2015 at 05:57:42PM +0000, Luke Dashjr wrote:
>> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
>> bitcoin-dev wrote:
>> > 2015-12-01
>> > -----------
>> > - Feature freeze
>>
>> Where is "Consensus freeze"? Shouldn't this be put off until after the HK
>> workshop in case a hardfork is decided on? Or have we de-coupled it from the
>> release process entirely anyway (since old versions need an update for it
>> too)?
> In principle, "feature freeze" means that any large code changes will no longer go into 0.12, unless fixing critical bugs.
> I'm not keen on postponing 0.12 for such reasons - after the HK workshop I'm sure that it will take some development/testing/review before code makes it into anything. Apart from that there's a good point to decouple consensus changes from Bitcoin Core major releases.
> We've seen lot of release date drift due to "this and this change needs to make it in" in the past, that was a major reason to switch to a time-based instead of feature-based release schedule.
> We can always do a 0.12.1.
> Wladimir
> ------------------------------
> Message: 3
> Date: Thu, 1 Oct 2015 11:05:59 +0200
> From: Marcel Jamin <marcel at jamin.net>
> To: "Wladimir J. van der Laan" <laanwj at gmail.com>
> Cc: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
> Message-ID:
> <CAAUq486=TisNp0MbFjWYdCsyVX-qx5dV_KKZuNR7Jp63KNWeiQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
> 2015-10-01 10:50 GMT+02:00 Wladimir J. van der Laan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>> On Wed, Sep 30, 2015 at 05:57:42PM +0000, Luke Dashjr wrote:
>> > On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
>> > bitcoin-dev wrote:
>> > > 2015-12-01
>> > > -----------
>> > > - Feature freeze
>> >
>> > Where is "Consensus freeze"? Shouldn't this be put off until after the HK
>> > workshop in case a hardfork is decided on? Or have we de-coupled it from
>> the
>> > release process entirely anyway (since old versions need an update for it
>> > too)?
>>
>> In principle, "feature freeze" means that any large code changes will no
>> longer go into 0.12, unless fixing critical bugs.
>>
>> I'm not keen on postponing 0.12 for such reasons - after the HK workshop
>> I'm sure that it will take some development/testing/review before code
>> makes it into anything. Apart from that there's a good point to decouple
>> consensus changes from Bitcoin Core major releases.
>>
>> We've seen lot of release date drift due to "this and this change needs to
>> make it in" in the past, that was a major reason to switch to a time-based
>> instead of feature-based release schedule.
>>
>> We can always do a 0.12.1.
>>
>> Wladimir
>> _______________________________________________
>> 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/20151001/5dca9e61/attachment-0001.html>
> ------------------------------
> Message: 4
> Date: Thu, 1 Oct 2015 10:17:52 +0100
> From: Btc Drak <btcdrak at gmail.com>
> To: Marcel Jamin <marcel at jamin.net>
> Cc: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
> Message-ID:
> <CADJgMzuDPoQacdrH7n_ajwuYLMZ4-Z19KZSa=w=rLhmOkJhfQg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>>
> We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
> are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/dc91562f/attachment-0001.html>
> ------------------------------
> Message: 5
> Date: Thu, 1 Oct 2015 11:41:25 +0200
> From: Marcel Jamin <marcel at jamin.net>
> To: Btc Drak <btcdrak at gmail.com>
> Cc: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule
> Message-ID:
> <CAAUq4861Wd2c42gVy7SoW9414R8RGY+Yzp7rDtzagrwQewnFWg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> ---------- Forwarded message ----------
> From: Marcel Jamin <marcel at jamin.net>
> Date: 2015-10-01 11:39 GMT+02:00
> Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
> To: Btc Drak <btcdrak at gmail.com>
> I guess the question then becomes why bitcoin still is <1.0.0
> I'd say it's safe to say that it's used in production.
> 2015-10-01 11:17 GMT+02:00 Btc Drak <btcdrak at gmail.com>:
>> On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>>>
>>
>> We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
>> are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/17164b7e/attachment-0001.html>
> ------------------------------
> Message: 6
> Date: Thu, 1 Oct 2015 11:56:55 +0200
> From: "Wladimir J. van der Laan" <laanwj at gmail.com>
> To: Marcel Jamin <marcel at jamin.net>
> Cc: Bitcoin development mailing list
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule
> Message-ID: <20151001095654.GB10010 at amethyst.visucore.com>
> Content-Type: text/plain; charset=utf-8
> On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
>> I guess the question then becomes why bitcoin still is <1.0.0
> I'll interpret the question as "why is the Bitcoin Core software still <1.0.0". Bitcoin the currency doesn't have a version, the block/transaction versions are at v3/v1 respectively, and the highest network protocol version is 70011.
> Mostly because we don't use the numbers as a signaling mechanism. They just count up, every half year.
> Otherwise, one'd have to ask hard questions like 'is the software mature enough to be called 1.0.0', which would lead to long arguments, all of which would eventually lead to nothing more than potentially increasing a number. We're horribly stressed-out as is.
> Wladimir
> ------------------------------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> End of bitcoin-dev Digest, Vol 5, Issue 2
> *****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151001/0656d173/attachment-0001.html>

2023-06-07 17:42:06

- reply

📅 Original date posted:2015-10-12
📝 Original message:Thanks AJ,
That is a must more concise example, which I think makes it very clear all the variables at play.
I agree with its conclusion.
Though I'm wondering about its actual significance in ability to do harm as with 5% hash power we would have to wait quite a long time before such a block was created and it would be unpredictable when exactly this would occur, and in order to actually execute such a double spend maliciously you would have to 1) notice that such a block was mined and 2) be in a position to double spend a payment with a merchant for physical goods who you would know was using an SPV wallet at that exact time, correct? (By deliberately publishing a txn which would be blocked by the upgraded network)
Isn't that in itself unlikely enough to make this form of double spend unlikely to be exploitable?
Perhaps with malicious wallet software which always publishes "bad" (will be mostly rejected) txn first and then retries with a normal one?
But I agree with you that if the risk is there why not avoid it if possible.
—
Regards,
On Tue, Oct 13, 2015 at 2:06 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote:
>> First I think your unsaid assumption about the fragility of a soft
>> fork showing incorrect confirmations is dependent on the percentage
>> of hash power that didn't upgrade. If using your same numbers this
>> was only 5% of the hash power, the attack is effectively not effective
>> (u less the attacker knew an exact merchant that was unfortunately on
>> the minority of the network.
> Actually, just to take this scenario more explicitly...
> Say you've got 5% of hashpower running on old software, along with,
> say, 1500 nodes; and meanwhile you've got 95% of hashpower running new
> software, along with 4000 nodes.
> There's still about 750 nodes running 0.9 or 0.8 of 5400 total according
> to bitnodes.21.co/nodes, so those numbers seems at least plausible to
> me for the first week or two after a soft-fork is activated.
> Eventually an old-rules block gets found by the 5% hashpower. The 4000
> new nodes and 95% of hashpower ignore it, of course. With 8 random
> connections, old nodes should have 92% chance of seeing an old node
> as a peer, so I think around ~1300 of them should still be a connected
> subgraph, and the old-rules block should get propogated amongst them
> (until two new-rules blocks come along and orphan it).
> An SPV client with 12 random connections here has 96% chance of having one
> of the ~1300 old nodes as a peer, and if so, will see the old-rules block,
> that will be orphaned, and may be at risk from double-spends as a result.
> So I think even with just 5% hashpower and ~30% of nodes left running
> the old version, a "damaging soft fork" still poses a fairly high risk to
> someone receiving payments via an SPV client, and trusting transactions
> with few confirmations.
> Cheers,
> aj
> _______________________________________________
> 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/20151012/1e39a4a9/attachment.html>

2023-06-07 17:42:05

- reply

📅 Original date posted:2015-10-12
📝 Original message:Thanks for that great breakdown Anthony. I think it helps a lot of us get a better handle on the matter without getting too technical.
A couple of questions on some of the points you made I'd like to put out there:
First I think your unsaid assumption about the fragility of a soft fork showing incorrect confirmations is dependent on the percentage of hash power that didn't upgrade. If using your same numbers this was only 5% of the hash power, the attack is effectively not effective (u less the attacker knew an exact merchant that was unfortunately on the minority of the network.
-- snip --
- non-upgraded bitcoin nodes: total breakage. there will be a push
alert telling you to upgrade. anyone who doesn't will think they're
tracking "bitcoin" but will actually be tracking a new "bitcoin-old"
altcoin. most non-upgraded miners will presumably realise they're
wasting hashpower and stop doing this pretty quick; and remaining
miners will only create blocks very slowly due to sudden reduced
hashpower, without possibility of difficulty adjustment.
----
Is this true? I thought that un-upgraded nodes would just dump the new blocks from the upgraded miner majority as invalid. This how would they even know (besides the PSA) that they were on the wrong side?
----snip---
users who
don't uprade will try to do transactions, but won't see them confirm
for hours or days due to lack of hashpower.
----
But only for txns for users who are using the new OP code right? Regular transactions will get relayed by both upgraded and in-upgraded nodes and miners alike.
—
Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151012/ce9edfb5/attachment.html>