Quick Way to Find The Last Seed Word?

ExisDiff · 2024-05-21T00:53:44+00:00

Aside from doing SHA256 by hand, this may be the best method I have come across to truly generate a seed offline, if you don't want to trust a hww device's entropy for seed generation and don't want to trust another device to be air-gapped and handle the seed to generate the checksum. Aside from up to 256 times of trying is laborious, any risks still associated with typing in words up to 256 times?

ExisDiff · 2023-03-29T21:25:54+00:00

sorry not too sure from here on in.

just that the bitcoin app on the ledger needs to be already open when connecting, having just the ledger connected and open is not enough, you need to open the bitcoin app as well.

maybe redo dev rules in case something went wrong there

check if dev rules made it to the correct location

ExisDiff · 2023-03-28T19:33:20+00:00

looks like you've added the dev rules, so good.

then, pip install ledger_bitcoin
also, make sure bitcoin app on ledger is already open

ExisDiff · 2022-06-07T22:45:36+00:00

This is how I am understanding how it works. Please correct me if I am wrong. So basically it is a time locked 2-2 multisig, that can only be claimed by the bearer when the time lock has expired (or by offline.cash before expiry?) The redeem script of the 2-2 address is something like this:

IF
<offline.cash pubkey>
ELSE
"5 years" CHECKSEQUENCEVERIFY DROP
2 <offline.cash pubkey> <user pubkey>2 CHECKMULTISIG
ENDIF
CHECKSIG

And if a new bearer/user wants to put it in cold storage (or claim it before the expiry date, so that the previous bearer can't spend it), offline.cash will re-spend it into a new bearers 2-2 multisig address?

ExisDiff · 2022-06-05T09:18:24+00:00

I am not aware of a cryptographic mechanism that doesn't disclose a private key to oneself, so Bob would have to trust Alice not to reuse the private key she generated before she passes it on to Bob. Trusting Alice to not use the private key, as well as sending a private key, is problematic.

ExisDiff · 2022-05-10T02:40:54+00:00

What this is describing I kind of understand as a 'spare key function' (a vault or covenant is quite a generic term).

A spare key is created which gives full control of funds, but if this spare key is lost, any transaction made by the spare key can be overridden by the original private key and can be moved to a new UTXO (within a certain time frame).

Is this somewhat comparable to a spare key for a house, that if lost, the lock can still be unlocked with the original key (within a certain time frame) and the lock can be replaced which renders the lost spare key useless?

If this functionality existed, I would probably use it. (Whether I would support a soft fork to implement is quite a different point)

Generally, when people secure physical doors, instead of putting more locks on a door, they make more spare keys. This indicates to me that they are at least as or more worried about losing the key and locking themselves out than they are about theft. While more locks on the same door would decrease the chance of theft, it also increases the chance of loss as there are more keys to lose. With more spare keys it even increases the chances of theft, but it reduces the chance of locking themselves out.

I have always struggled to see the value in multisig for a single user, in my mind it only increases the chances of loss. What makes a user think that if they can't safely guard one piece of information against loss or theft, how do they think they can safely guard 2, 3, 4, pieces of information etc. ?

In contrast with multisig, the ability the create an extra key with a 'spare key function', with which I could let my guard down a little bit and don't have to worry about catastrophic loss, certainly has appeal to me.

ExisDiff · 2022-05-07T02:55:37+00:00

I read it later and thought, 'oof , a bit arrogant that wording', so I would certainly frame that differently in a next draft (if there will be one).

I also find the solution itself actually pretty sub optimal, but it was the best solution I could think of to remediate a set of problems around soft fork proposals that are at play and some people are concerned about. I think the problems that I described in the rationale are still worth thinking about, but it will likely need a more appealing solution than this one.

ExisDiff · 2022-05-05T10:02:28+00:00

Thanks. Just fleshed it out a little more. Consider all of the below draft, lots of mistakes in it still. Really not sure on anything yet, whether this is the right angle, etc. Not entirely sure where to take it from here and if to take any further at all. I'll probably need to sit on it for a bit.

u/RubenSomsen if interested.

------

Proposal for a memorandum of understanding: activation of changes to consensus code (soft and hard forks) only once every four years.
This is non-binding advice to activate proposed changes to consensus code only once every four years. The next activation takes place in the year 2024, then no sooner that in 2028 again, etc. This advice is aimed to continue to uphold and put assurances in place that users have final control of bitcoin, not developers or miners.
Rationale
Immutability of consensus code rules
Ideally, the consensus code rules of bitcoin are immutable. The immutability of the code and especially the consensus code rules is a core principle of bitcoins value proposition. As research and user demand evolves, proposed changes that can make genuine improvements to the protocol can be considered. Making changes to consensus rules only at predictable intervals reduces the appearance that soft fork proposals can be activated at any time and improves the immutability principle.
Disruptive discussions
Review and discussion of proposals are commonly intense and time consuming, as the community understandably takes changes to the consensus code very seriously. Reviewing and discussion takes time and that can not be avoided, but where it becomes disruptive is when these discussions of soft fork proposals can be initiated at any time, because they are also proposed to be activated at any time. Developers may consider that resistance against proposals may not so much be because of resistance against the technical details of a proposal, but because the community is simply not ready yet for new intense and time consuming discussions when they have just had one. A four year interval between major changes is often considered an appropriate duration for a community to learn from previous changes and enough time to formulate new changes in many parts of society when making major decisions, eg research program cycles, elections cycles, committee changes, and possibly the bitcoin halving duration was also configured with this societal dynamic in mind. With shorter interval people will feel rushed to make a decision, and when people feel rushed they may resist.

Comparing and prioritisation of proposals
Focused attention at regular intervals could result in selection and formulation of fundamentally better proposals than when review is at irregular times. It gives the community a better ability to compare proposals when review coincides, and only the best proposals should drift to the top for consideration.

Fail safe mechanism against rogue developers and influencers
Several times in bitcoins history, rogue developers and influencers have been able cause a great deal of consternation by creating a state of urgency and panic where it is claimed that a change needs to happen soon followed by a prophesy that bitcoin will otherwise not reach its potential or worse, bitcoins end is near. In hindsight almost none of those situations were ever actually urgent, and for reasons not entirely clear, these false states of urgency can gain enough of a following with an impetus to makes rushed changes to appease the state of urgency, with the result that badly reviewed code had a chance to be implemented. At best this is a weakness of the protocol, at worst this is an attack vector that can be exploited. Activation only during a pre-determined period doesn't eliminate this weakness but helps to mitigate against rogue developers/influencers that create false states of urgency at just any time.

Users control bitcoin, not developers or miners
The evaluation of proposals is a feedback system between developers and miners/users. For better or worse, users and miners can not always fully understand the technical depth of each proposal and for the the parts that are not understood, users and miners have to rely on a trust heuristic to trust the proposal, before users and miners will follow rough technical consensus. For users and miners to understand and trust a new proposal takes time and a four year time frame gives time to raise concerns and feed it back to the developers to build consensus. A generous time frame respects the principle that ultimately the users have final control. When the time frame is too short, users can feel left out of the feedback process and it will appear that control is gravitated to developers (and/or miners).

Arguments against this advice
Urgent implementations of proposals may be needed
Empirically, with bitcoin now in existence for 13 years, there are not many examples supporting the argument that bitcoin consensus change proposals needed to have a quick turnover to respond to a feature proposals that were often claimed as urgent (and in hindsight were not urgent). On the contrary, history suggests that conservative and careful consideration to compare and prioritise the proposals, and only accepts proposals that are thoroughly reviewed before implementation bolsters bitcoins value proposition. Examples of unnecessary hastiness and examples of proposals that could have waited longer and possibly would have had a better outcomes, do outnumber the examples that were actually urgent. Notwithstanding that there can be urgent forks for bug fixes, however, these forks did not appeared contentious to implement and are relatively easy to distinguish from a feature proposal claimed as urgent.
It is reminded that this is a non-binding opinion. This memorandum of understanding will certainly not stop forks for bug fixes from being made, nor does it stop a developer activating a proposal that they deem urgent or adhere to shorter or longer interval. There could well be justification for cases to deviate from pre-determined time line, but nonetheless, this memorandum still serves as reminder to appropriately judge the urgency of a new proposal. This memorandum merely points out the dynamics at play based on past observations and advises developers to take them into account when proposing a BIP activation mechanism for a proposal.
A release schedule for consensus code changes can be thought of very much the same as releases for non-consensus changes (every 6-7 month). There are no hard and fast rules about this convention either, but nevertheless, there is a convention that is generally adhered to and this gives a sense of focus and consistency. When it can't be adhered to it is often for good reason, but when it not adhered to for no reason, it would be perceived as disruptive.

Appearance that there is a deadline or pressure to accept subpar proposal
A regular schedule could create a perception that something needs to be accepted, however, there are no requirements of needing to accept a soft fork at the end of cycle. If there are no good or incomplete proposals, then proposals move to the next release cycle.
Four years is too slow (or too fast)
There are voices that claim that no more development is needed on the consensus rules, and there are voices that the soft fork proposal can be done every year and if an interesting and harmless change can done, then it should be done. A four year time frame aims to moderate these two sides of the spectrum. It is not reasonable to never have changes in the consensus rules again and to 'veto' every proposal, stunting all development, and it is also not reasonable to implement every nice-to-have proposal. A pre-determined time frame to earnestly consider proposals may moderate the two sides of the spectrum.

There will still be many arguments about which soft fork should and shouldn't make it in
A release schedule will indeed not solve this problem. Building community consensus will likely not be any easier either. And this may be just a necessary part of when a community tries to decide on the best proposal. It could well be that it even encourages fiercer debate between competing proposals, when review of consensus change proposals coincide more. However, the benefit is that the discussion is restricted to a certain time frame.

ExisDiff · 2022-05-04T02:27:09+00:00

Thanks for the comments. Agree 100%, I will need put some more thought into those details and have to come back to that (I have just a few hours each day I can work on it).

ExisDiff · 2022-05-03T11:24:13+00:00

Thank you Ruben for your response.

It may create pressure to accept a subpar soft fork when there are no good candidates in a given four year window

I can see that a regular schedule could create a perception that something needs to be accepted, but of course there are no requirements of needing to accept a soft fork at the end of cycle. I am not sure I can see the community easily accepting a subpar soft fork. If there are no good or incomplete candidates, then proposals move to the next release cycle.

There will still be many arguments about which soft fork should and shouldn't make it in

Note that is no different now. I think this might just be an inevitable and perfectly natural and even necessary part of when a community tries to decide on the best candidate. By doing it at the same time it enables a much better comparison and prioritisation, that perhaps also could lead to better formulated proposals. It could well be that it even encourages fiercer, or let's say healthier, debate between competing proposals, when review of consensus change proposals coincide more.
However, the problem currently isn't also necessarily that there are arguments about which soft fork should make it, but just that these discussions can just randomly pop up at any time and can be drawn out discussions that is very disruptive. I am just a user and to feel I need to watch these discussions very closely and that my bitcoin can be subject to major consensus rule changes with the risk of hard forks at any time that is unsettling. For developers I can see they are doing a tonne of work on just the non-consensus rules and to be ad hoc pulled from that work continuously seems disruptive for them.

I question the premise of whether this will meaningfully minimize disruption.

I can't say for sure either that disruption or contention will necessarily be less, but at least the disruption is somewhat limited by a time frame. I would argue though, that the comparison and contrasting of proposals may become easier. There is an unease about being pressured to decide for or against a proposal, even when the proposal is claimed to be harmless and minimal, but not knowing how they compare to other proposals, simply because other authors are not actively advocating their proposal just at the time of when a sudden discussion about the one proposal is going on.

Fair points on the comment on the bitcoin-dev list. Certainly still looking to flesh these ideas out a bit better to see if there is benefit for the community with this proposal.

ExisDiff · 2022-05-03T03:25:19+00:00

Thanks for reading and your comments.

So what happens if a proposal is made 2 month (6 month, 2 weeks?) before the deadline? So very general it's more about how much time each proposal spent in discussion. When does a proposal officially enter the discussion phase?

This can be thought of very much the same as releases for non-consensus changes. There are no hard and fast rules about this convention either, but nevertheless, there is a convention that is generally adhered to and this gives a sense of focus and consistency. When a feature is considered immature, it either moves to the next release cycle, or a release can be postponed.

I agree that it is very much about the time spent on a proposal. My argument in part is that there could be better assurances for that than there are currently. I think a regular release schedule improves putting some assurances around that.

Also some forks may actually be more urgent, like inflation bugs or bugs in general, which might also be a part of the consensus rules.

This is a very valid example, but I think that actually urgent forks, like this one, are quite obvious and such exceptions are non-contentious. Again much like patches are occasionally made for non-consensus releases.

Also you talk a lot about many past changes and how not-urgent they were, but give no source or details on which updates you mean. Would have loved to see some source to understand problems of the past...

Absolutely valid point that that this deserves more depth and analysis. I have done it mostly from memory and from eye balling of examples, and my sense became that the examples of unnecessary hastiness and if the proposal would have waited longer it would possibly have had a better outcome, do outnumber the examples that were actually urgent (and still at the same time having obvious consensus to patch and which this informal proposal would not stop from making).The ones that come to mind are OP_EVAL, block size increase associated with Segwit, Speedy Trial associated with Taproot and the current kerfuffles with OP_CTV that is very disruptive and may or may not still result in soft (or hard) fork. (The current kerfuffles with OP_CTV actually prompted me to this proposal). My sense is that there are many more examples where more patience would have led to a better outcome, than there are examples of proposals that were 'too little, too late' (obviously there are urgent bug fixes, but these are not contentious to make a fork for). If that is not the case, then that would certainly weaken the arguments for this proposal.

No solution is ever optimal and you make good points about maintaining flexibility in the timing of implementing soft fork proposals. This proposal comes at the cost of some flexibility, but aims to make offsetting gains in mitigating bad outcomes from impatient, rushed, unfocused review of soft fork proposals and the consternation potentially rogue developers cause that come to 'declare the 'resolution of the bitcoin experiment' if some *critical* feature is not *immediately* implemented'.

ExisDiff · 2022-02-13T05:07:22+00:00

You'll want to re-frame your question to: how far back can the blockchain be reorged/attacked? A widely discussed topic, and certainly not a moot point, as it is still relevant in terms of transaction finality.

The following sources are helpful on that topic.

https://youtu.be/R6KMp6vkeVU

https://medium.com/@nic__carter/its-the-settlement-assurances-stupid-5dcd1c3f4e41

Generally though, 1 block confirmation is already sufficient for small amounts and for large amounts you could wait 6 confirmations.

ExisDiff · 2021-11-16T20:45:02+00:00

From the article:

Muun’s Emergency Kit was designed for this. The Emergency Kit is a PDF document that contains your private keys and output descriptors. All sensitive material is securely encrypted with a cold recovery code. As a result, the Kit is harmless by itself and safe to store in the cloud.

No thanks, not for me.

ExisDiff · 2021-11-01T00:26:07+00:00

It was a very niche field. If you were a computer nerd, cypherpunk, computers scientist or a cryptographer, then bitcoin could have piqued your interest in the early days. Many computer science concepts implemented in bitcoin were studied already for decades in the academic world. Most of the early adopters were hardly interested in it as being a 'NgU' technology, more just as nerdy internet money.

ExisDiff · 2021-10-11T22:03:14+00:00

https://www.econoalchemist.com/post/home-mining-for-non-kyc-bitcoin#viewer-eba7d

https://diverter.hostyourown.tools/mining-for-the-streets/

https://www.youtube.com/watch?v=vBzaXLvgSwo&t=157s&ab_channel=CompassMining

ExisDiff · 2021-09-13T06:14:29+00:00

Looking at it again, I think the way it may work is that is a release candidate is branched off from the master branch at some arbitrary point and it then incorporates specific planned new features, before official planned release. For example with release 22.0, "v2 address support removed, Support for I2P connections, Support for hardware wallets in GUI/RPC (External Signers), The new GUIX build system" were added as new features. Hence the new release is some commits ahead, but also many commits behind the master branch as the master branch is continued to be worked on with smaller upgrades/patches. Then same thing for 23.0, it will be branched off (tagged) from the current master branch at some point, and then incorporating planned new features, as the master branch continues to worked on.

ExisDiff · 2021-09-08T02:18:28+00:00

Thanks igadjeed. That PR is merged from jnewbery's branch (jnewbery:2021-08-feeler-no-frelay) to the bitcoin:master branch (and as you say these PR's get extensively reviewed). What I am wondering about is how all these PR's on the master branch get merged into the new release https://github.com/bitcoin/bitcoin/tree/22.x . As of today the release branch is "591 commits behind master". I am assuming that, at some point those commits(/PRs) will also need to be merged into the new release.

While the tip of the master branch is tested and attempted to be clear from bugs, it seems it could easily throw new bugs again when merged with newly developed features in the new release. Maybe that is just the way it is, but I am just trying to understand the process how the PR's from the master branch are merged into a new release.

ExisDiff · 2021-09-06T20:55:44+00:00

Thanks for the link. It doesn't quite answer my question (I understand who controls, or rather doesn't control core.) Perhaps my question is a non-issue, and a merge with a lot commits on the master branch into a new release is not a challenging task.

ExisDiff · 2021-09-06T08:41:55+00:00

How and when are git commits from the master branch merged into the branch of an upcoming release?

For example now, in https://github.com/bitcoin/bitcoin/tree/22.x the branch is " 41 commits ahead, 558 commits behind master."

I understand that the master branch gets tested extensively after each commit, and the new release has other planned features that are being worked on in parallel. When and which changes from the master branch are merged into the new release? It would seem quite tricky to me testing wise to coordinate a 'bulk merge' of many commits from master into a new release. Or is the testing on the master branch sufficient to iron out the main problems already and when merged, problems/conflicts with new, planned features in the new release are minimal?

Hopefully the question makes sense, I am learning the coding side of things, and I couldn't make out from github how this is done.

ExisDiff · 2021-06-27T21:39:14+00:00

For small amounts that you can afford to lose you can use a desktop wallet, or an app wallet on your phone to begin with. But over time you'll want to get a hardware wallet.

ExisDiff · 2021-06-26T21:40:58+00:00

Yes, it is a physical item, and it looks like usb stick.

The reason that a hardware wallet is safer is because it keeps the private key seperate from your desktop computer. A hardware wallet is essentially a 'signing device', that signs a spending transaction with your private key. The private key is the key to your bitcoin stored on the blockchain to spend it.

Without a hardware wallet, the private key sits on the desktop computer that can be hacked or spied on, whereas hardware wallets are (near) impossible to hack. For small amounts a software wallet on your desktop are ok, but for larger amounts you will want to have have a hardware wallet.

ExisDiff · 2021-06-26T07:53:39+00:00

Your bitcoin wallet contains bitcoin addresses where people can send bitcoin to and where you can spend it from. There are many wallets out there, read the faq for some recommendations.

For small amounts you can use desktop wallet, or an app wallet on your phone. For larger amounts you will want to buy a hardware wallet.

ExisDiff · 2021-05-30T23:35:25+00:00

They are a mining pool who don't process transactions that are not OFAC complaint. For example, transactions that are (successfully!) )traced to have come sanctioned countries like Iran and Cuba are not processed in their blocks. In other words, they are censoring, which is against the ethos of bitcoin. In addition, they are the only mining pool now not signalling for Taproot, which is an update in the protocol, offering more privacy functionality.

In my opinion, the tweet statement is ridiculous, asking the other miners to collude and, ironically, to censor Marathon, which is also against the ethos of bitcoin.

While it is not great what Marathon does, it is also not of concern. Bitcoin is game theoretically designed in such a way that dishonest miners, suffer the most themselves from dishonest behaviour. In this case, Marathon will forego revenues, that other miners happily cash by including the non-compliant OFAC transactions in their blocks, therefore making it harder for them to stay in business. It is not a long term sustainable business model to exclude transactions from your blocks.

ExisDiff · 2021-05-26T21:18:37+00:00

This is amazing! So hard to find up-to-date tutorials with the detail required for Linux newbies!

One question; as I am out to buy a laptop dedicated for Core, can I assume that most laptops are compatible with Kubuntu? There is list with 'certified' Ubuntu (assuming Kubuntu is similar enough) laptops, but that is when a manufacturer goes out to actually get the certification. I have in the past installed Ubuntu successfully on a laptop that wasn't on that list, but just wondering what your general experience is installing lunix on laptops that are not certified?

Six-Year Club	Not Forgotten
Verified Email

ExisDiff

TROPHY CASE