Be careful with that, or you'll end up like coldcard user who used their dice generation feature with weak entropy and lost all his coins. Let's just say that, fortunately, SeedSigner won't allow me to use a single dice result as an entropy!  Same could be said for any generation that is not true random, and that means that it can be reproduced and cracked much easier. Is it just me or is the phrase "true randomness" a bit of mixture of pleonasm and misleadingness? It kinda bothers me. If something is random, then people can't guess it; the outcome is totally unpredictable, and every possible outcome has the same probability. If that would be false, you wouldn't call it "fake randomness". You would simply call it non-random, or biased. In the case with generating entropy, both /dev/urandom and dice rolls are evidently random, hereby "truly random". But what matters in the end is being provably random. Rolling dice is provably random, because you control the interface. /dev/urandom on the other hand requires some trust on the hardware. |
|
|
|
Is it me or you compare the disk (card) size the OS image file with the device's RAM capacity? My bad! It doesn't have a RAM requirement, so it probably works with all models as displayed. |
|
|
|
You can install Linux on RPi Zero 2W which is the model I have. I have installed Raspbian Lite. It is odd, though, because Raspbian Lite OS requires 520 MB of RAM, whereas Pi zero can handle up to 512 MB. Am I missing anything? Anyway, SeedSigner is an OS, so we need to go deep into its code to check if we can use something like /dev/urandom. If SeedSigner is like a linux distribution, it could be possible, but I seriously have no idea if it is doable. It is not a Linux distro. How do I know? Hint: 99.9% of the code is written in Python! Anyways, I don't believe that users should put trust on a CSPRNG that is not tested enough (as we wouldn't go with /dev/urandom). Besides, the spirit of the project is to trust none, including your RNG!  |
|
|
|
However, I dislike the "enter your own randomness" idea. Therefore I don't really use it. I disregard the "take a seed picture" for generating entropy too. However, using coin / dice results as the entropy is the single most provable way to generate randomness. I agree that /dev/urandom is sufficient for the most part, but not for the paranoid (AKA, those who don't trust their device). Do you believe it would be a good idea to slightly change the code to generate entropy using some CSPRNG source? Raspberry Pi zero isn't designed to run Linux, as far as I'm concerned. It has 512 MB RAM, and almost all distros I know require more than that. How do you suggest we utilize such a source without having e.g., /dev/urandom? |
|
|
|
My take on it is that he understood that absolute privacy of transactions - be it BTC, fiat, or whatever - naturally opens the doors to a myriad of illicit uses. I just don't get how you've reached to this conclusion. There is no message of him discouraging the use of absolute privacy tools. To me it rather seems as he saw it as "private enough". The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous. You could use TOR if you don't want anyone to know you're even using Bitcoin. He even talked about key blinding and group signatures long before Monero and other privacy protocols were introduced in concept: Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related. There's something here in the general area: http://www.users.zetnet.co.uk/hopwood/crypto/rh/What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m. When paying to a bitcoin address, you would generate a new blinded key for each use.
In my experience, the simple answers are usually the correct ones. Satoshi simply lacked the competence to do that. It wouldn't be surprising. The very first Bitcoin version was quite simple in concept, and if you read the source code, you could tell it was just above the average. He did some mistakes, like the value overflow or reorganizing based on block height instead of chainwork. Maybe he ignored privacy enhancing techniques on purpose, but that's because it would be more difficult to explain to the public. Another guess: Maybe he didn't ignore them on purpose, but simply because it was too late to introduce them at the date he revealed interest about them. |
|
|
|
To find an optimised solution in an NP-hard problem computational power is needed And as I've already demonstrated, miners choose to go with the "good enough" solution, rather than the ideal. It is simply not worth the effort to find the ideal solution with the given cost. Do you think your rapspi will be able to handle a massive amount of paths and liquidity if/when LN is implemented ? Lightning is implemented. The algorithms used are as I've already said optimized not for the cheapest, but for the cheap enough fee. It will work on even larger network, likely less accurately. But still people in here claim that it will work There is a variety of opinions about LN in this board, and I highly doubt we all believe it will work flawlessly. There are tradeoffs, just as with everything. LN is even more centralised than mining . Have a look at how much liquidity and channels belong to the top 10 Now, who's arbitrarily using the word "centralized"?  |
|
|
|
Good luck with your LN trying to solve an NP hard problem . Transaction selection is NP-hard, but the software isn't trying to find the ideal fee; just one that is cheap enough. That's why they use variations of Dijkstra and A*, and not these algorithms per se. In LND, for instance, you can check yourself how optimized it is, comparably to a simple Dijkstra algorithm implementation: https://github.com/lightningnetwork/lnd/blob/master/routing/pathfind.go#L494-L504. But, I don't understand why you focus on routing algorithm being NP-hard, and ignore mining which is NP-hard itself. The typical way to resolve this, is just to select a "good enough solution" rather finding the ideal. This is why you can find cases of blocks which could include higher paying transactions instead. System works pretty fine after all. |
|
|
|
You do realize that Bitcoin evolves, don't you? The "longest chain" has changed to the "chain with most accumulated work" wins, for obvious reasons. That's actually a noteworthy fact of the Bitcoin history. The whitepaper does include the phrase "longest chain", and while most people believe he meant "longest difficulty-wise chain", he actually didn't. The "longest chain" in the whitepaper is meant literally; the chain with the highest block. If you search for "chainwork" in the v0.1, you will find no results. On the other hand, let's see the only part of the source code where "longest chain" and "longest branch" appear. //
// The block chain is a tree shaped structure starting with the
// genesis block at the root, with each block potentially having multiple
// candidates to be the next block. pprev and pnext link a path through the
// main/longest chain. A blockindex may have multiple pprev pointing back
// to it, but pnext will only point forward to the longest branch, or will
// be null if the block is not part of the longest chain.
//
class CBlockIndex
{
<defines the BlockIndex class> If you read the function Reorganize, you can notice yourself it doesn't check for most-worked chain at all; instead, it relies on the highest block number: bool Reorganize(CTxDB& txdb, CBlockIndex* pindexNew)
{
printf("*** REORGANIZE ***\n");
// Find the fork
CBlockIndex* pfork = pindexBest;
CBlockIndex* plonger = pindexNew;
while (pfork != plonger)
{
if (!(pfork = pfork->pprev))
return error("Reorganize() : pfork->pprev is null");
while (plonger->nHeight > pfork->nHeight)
if (!(plonger = plonger->pprev))
return error("Reorganize() : plonger->pprev is null");
}
// List of what to disconnect
vector<CBlockIndex*> vDisconnect;
for (CBlockIndex* pindex = pindexBest; pindex != pfork; pindex = pindex->pprev)
vDisconnect.push_back(pindex);
// List of what to connect
vector<CBlockIndex*> vConnect;
for (CBlockIndex* pindex = pindexNew; pindex != pfork; pindex = pindex->pprev)
vConnect.push_back(pindex);
reverse(vConnect.begin(), vConnect.end());
// Disconnect shorter branch
vector<CTransaction> vResurrect;
foreach(CBlockIndex* pindex, vDisconnect)
{
CBlock block;
if (!block.ReadFromDisk(pindex->nFile, pindex->nBlockPos, true))
return error("Reorganize() : ReadFromDisk for disconnect failed");
if (!block.DisconnectBlock(txdb, pindex))
return error("Reorganize() : DisconnectBlock failed");
// Queue memory transactions to resurrect
foreach(const CTransaction& tx, block.vtx)
if (!tx.IsCoinBase())
vResurrect.push_back(tx);
}
// Connect longer branch
vector<CTransaction> vDelete;
for (int i = 0; i < vConnect.size(); i++)
{
CBlockIndex* pindex = vConnect[i];
CBlock block;
if (!block.ReadFromDisk(pindex->nFile, pindex->nBlockPos, true))
return error("Reorganize() : ReadFromDisk for connect failed");
if (!block.ConnectBlock(txdb, pindex))
{
// Invalid block, delete the rest of this branch
txdb.TxnAbort();
for (int j = i; j < vConnect.size(); j++)
{
CBlockIndex* pindex = vConnect[j];
pindex->EraseBlockFromDisk();
txdb.EraseBlockIndex(pindex->GetBlockHash());
mapBlockIndex.erase(pindex->GetBlockHash());
delete pindex;
}
return error("Reorganize() : ConnectBlock failed");
}
// Queue memory transactions to delete
foreach(const CTransaction& tx, block.vtx)
vDelete.push_back(tx);
}
if (!txdb.WriteHashBestChain(pindexNew->GetBlockHash()))
return error("Reorganize() : WriteHashBestChain failed");
// Commit now because resurrecting could take some time
txdb.TxnCommit();
// Disconnect shorter branch
foreach(CBlockIndex* pindex, vDisconnect)
if (pindex->pprev)
pindex->pprev->pnext = NULL;
// Connect longer branch
foreach(CBlockIndex* pindex, vConnect)
if (pindex->pprev)
pindex->pprev->pnext = pindex;
// Resurrect memory transactions that were in the disconnected branch
foreach(CTransaction& tx, vResurrect)
tx.AcceptTransaction(txdb, false);
// Delete redundant memory transactions that are in the connected branch
foreach(CTransaction& tx, vDelete)
tx.RemoveFromMemoryPool();
return true;
} Satoshi made other mistakes too, like the value overflow incident. It is reasonable though; no human is infallible. |
|
|
|
I have found some good options in BISQ with very low fees. It is debatable if Bisq is better than eXch in BTC<->XMR swaps, if we ignored self-custody for a moment. In Bisq, both traders need to make a total of four Bitcoin transactions. At current fee rates (~28 sat/vb for medium priority), that's about $7. Then, it is the trading fees (funding the DAO). If you pay in BSQ, it can come as cheap as 0.075% of the amount exchanged, if you're the maker. That's really low, and from my experience, you do find takers if you leave it open for at least a day. Just don't sell it at a premium price. People don't choose premium as they do with fiat trades. To me, eXch is better if you're in hurry. Otherwise, Bisq is more flexible and cheaper for large amounts. |
|
|
|
So, let me get this straight. - You are not directly enhancing any security of the seed, you're just adding another barrier needed from the user to pass.
- You've written software that uses cryptography in Javascript, which is not recommended.
- You're asking from the user to submit their seed phrase, when the user is properly warned by every single wallet software to never do that.
What problem does this solve, again? 1. How many iterations do you use for the key? According to their github repo, it uses 1000 iterations of a 256-bit key. 2. Is it normal that the same phrase always produces different cipher? I am not familiar with AES. It is normal. That's the use of the initialization vector, which is a random value that is used along with the key. Every time you perform encryption, there is a new IV value, so it results in an entirely different ciphertext. |
|
|
|
The forum doesn't acknowledge the use of AI, so whoever that uses Al has disobey the rules and regulations of the forum If the forum doesn't acknowledge AI, how is it against the rules? Spamming the board with zero-value posts is what's against the rules, and that's why AI generated posts are getting deleted. We come to the forum to communicate with people, don't we? Fortunately, it is still easy to spot humans on the Internet; each one of us has a unique writing style of their own. It is very easy to spot an AI account. If it's a brand new account, appeared out of nowhere, writing an extensive list of what one needs to consider before starting a new crypto project, using plain bold, then it's probably an AI. |
|
|
|
The 5% fee is back to 0.5 or 1% again. Probably because Binance delisting Monero. Monero dropped 17% now. Imagine that, people dumping their privacy coin because they can no longer trade it on a KYC exchange.... That's an action of some real cypherpunks right there. |
|
|
|
Usually, Internet providers don't enforce bandwidth limits that influence the operation of such a non-expensive protocol. There are protocols like BitTorrent that work flawlessly, and with much greater bandwidth. These policies vary based on region and specific providers; it has never been a problem for the Bitcoin network as far as I'm concerned. You can also choose to not accept incoming connections (which is the default) and reduce your total bandwidth by a lot. Attack targets: where Bitcoin core users are being attacked with an intention to disrupt the network as Bitcoin core powers Peer to peer services which would in a way limit bandwidth limits.
There are over 50,000 nodes as we speak, 20%+ of them operating under a hidden service. I very much doubt you can effectively disrupt the network in that way. |
|
|
|
Confirmation talks about having to confirm that there is something and with respect to the context of discussion, I’ll say confirming that there is a Bitcoin transaction been sent… is that it? Read this: - Confirmation of a transaction: the act of including the transaction in a block, and mining on top of it. If the most recent block contains your transaction, it has 1 confirmation. If somebody mined a block on top of that, it now has 2 confirmations.
- Validation of a transaction: the act of verifying if a transaction complies with the consensus rules.
- In validation, you validate the authenticity. If someone tries to counterfeit bitcoins, for instance by spending non-existent inputs, the Bitcoin software will treat this as invalid. - In confirmation, you confirm that it's been included in the chain with the most work. Mining is what increases the confirmation of a transaction. The article provided didn’t talk more on what could result as per breakdowns in terms of the disruption of the data upload by limits of due to the network providers. Can you give us an example of a breakdown that would disrupt the network? |
|
|
|
|
Theoretically, Bitcoin goes up when there is inflation and people conceive it as a hedge. However, this is not always the case, at least not in the short term, because there are people who view it as a luxury asset. And when inflation hits the pocket, and these people need money, then the first to withdraw is their luxuries.
That being said, on the long term it has acted as more than a hedge against inflation. Strictly speaking, though, that does not count as evidence of a long-term inflation hedge either. It does have good chances to work, though, I believe.
|
|
|
|
I don't agree with lobbying when it comes to politics, but I don't think the solution to that problem is to tell people that they can't make donations. This sounds similar as to installing surveillance cameras everywhere, inside every person's house-- completely violating everyone's privacy to prevent criminality. Or at least with that excuse. I am not entirely certain, but just as I do not believe that residing in the year 1984 would eliminate criminality, I also hold the view that "banning donations" would not necessarily deter lobbying. Don't just accept financial servitude!!! Come on!!!
Please, for the love of God, put fruitloops1 on ignore. The fact that he's banned in the Dev & Tech board should tell you a lot about his technical viewpoints on Bitcoin. In general, he denies reality, derails topics, and can never have a constructive discussion with anyone. |
|
|
|
Email used to create this forum? Used where and for what purpose? For purchasing the domain name "bitcointalk.org"? For purchasing "bitcoin.org" (as the forum was under bitcoin.org/smf at first, and then under forum.bitcoin.org)? For the dedicated server used to host this place? The Satoshi's email from Anonymous Speech was used to buy bitcoin.org, and it's pretty unknown beyond that. A better question is: why do you want to know such a thing? |
|
|
|
The best way is by connecting to your own node, no doubt. The second best, is by using Tails. It comes with Electrum pre-installed and does not allow you to sync without going through the Tor network. However, note that by doing that, all of your addresses can be linked from the Electrum server that you use to request information. You must not connect to a third party server when using electrum, and you must not use a full node wallet for better privacy, you can use your Electrum wallet and connect to your own Electrum server, without exposing your ip addresses and BTC addresses to any third party server.
The only way to not expose IP and Bitcoin addresses to a third party is by running a full node, so I presume you've mistyped. |
|
|
|
Thinner looks better. Um.. What has happened to the 4th guy?  |
|
|
|
Here are some reasons from the top of my head: - "If it works, don't touch it"-- motto for technicians. I've myself applied it. I think I was running a 23.0 for a long time, until 26.0 was released. If it does your job, why risk breaking anything?
- People want to run older versions until they feel newer are tested and reviewed enough.
- People are bored to update.
- An older version of Bitcoin Core might contain features that were removed in newer, and a part of other software and processes might depend on them.
|
|
|
|
|
Show Posts
