LOL not that what I meant. I will basically try to get to know with those command line things how they work etc etc. It's more like exploring the entire system and getting to know the features.
You're unlikely to break the blocks db just learning the basic commands, but there are blocks commands cli that could potentially mess it up ( invalidateblock for instance) My drive is 2T so space is not an issue.
Put any backup on a different disk, then both disks would need to stop working at the same time to force you into total re-sync
|
|
|
RISC-V is the only open instruction set out there, or at least the only modern design (the older MIPS stuff was open sourced recently if I remember rightly)
The only way to get total control of an open ISA as an end-user is to validate the chip design all by yourself, then fabricate the chip yourself in your garden shed. Presumably that's what you intend to do?
|
|
|
There is such a function in SMF. I remember using a forum where this was possible. There is also another function that can be added and it would be curious, which shows which users are online reading the topic. Sounds interesting, hopefully it's implemented in Epochtalk too (or is easily done) Another useful feature would be to filter such a list by rank. Not much point in keeping track of newbies posting in dubious threads
|
|
|
It exists: the RISC-V ISA
The Bitcoin developers are ahead of the game somewhat, Bitcoin core 0.18.0 release will have RISC-V binaries
|
|
|
The Bitcoin network has been functional for 99.99999 % not 100%. There was a bug that was fix-it by satoshi. But most people consider this event as a downtime. block 74638 August 15thSome people consider the "Accidental Hardfork" downtime too. And compare that to typical internet banking uptime; 2 outages in 10 years, and now up for 5 years and counting is an unbeatable record someday we'll have p2p mesh networks and won't have to worry about the centralized internet infrastructure going down. but that's decades away....
Some people are already on a meshnet
|
|
|
Some threads are (to me) only started with the intent to troll, and I don't read or post in them if I suspect that
The author is displayed on the board's page, but I'm also interested in a list of those who reply. Those who reply are either too dumb to realise the thread is trolling, or they can tell too but they're happy to perpetuate the thread for whatever reason.
A function to get a list of people who posted in a given thread would be useful, trawling the thread for usernames manually would be time consuming (and only gives it more views)
|
|
|
OP's thesis describe sybil attack, so IMO it's worth to mention those BIP which have few/some correlation.
You're right, I don't know how I skipped over that I've seen some sources (including it's paper and Core's developer commentary) mention MuSig improve privacy since outsider can verify signature validity without see used public key. Do i interpret it wrong or they're talking privacy on different aspect? I see your point: multi-sig using Musig looks like a 1 input transaction when spending from a Musig address, regardless of how many signers are needed to pass the threshold. But the way I understand it, it's Schnorr's additive keys property that confers that quality, and not Musig per se. Certainly, Musig is designed at least in part to prevent the attack I described in my previous post, an attack which is a consequence of using additive public keys to generate the public key for a multisig address. So it seems logical that it's Schnorr that's improving multisig privacy, and Musig that mitigates the risks of using Schnorr signing for a multisig address.
|
|
|
Finally i have free time to read your thesis. My comment, thoughts & question : 1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction. Remember that these are confined to the network layer of Bitcoin: 1. With BIP156, your IP address will no longer be tied to your personal transactions from the perspective of connected Bitcoin nodes. 2. With BIP151, all relayed transaction data will be encrypted from the perspective of someone analysing internet traffic (but connected Bitcoin nodes will still see the transactions unencrypted). Neither of those BIPs will change the ability to analyse transactions on the blockchain 2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.
No, Musig Schnorr makes using multiple inputs less expensive. This only incentivises coinjoins, it does not make them any more private. edit: Musig is for threshold based multisig that is safe to use with signature aggregation (without Musig, the last person adding their sig to an n of n aggregated public key could cheat by throwing out all the previous keys and replacing them with 1 key that belongs to them, and pretend that all the previous people's keys are aggregated together into it, so they can steal everyone's money). And so Musig doesn't have anything to do with privacy or anonymity on the blockchain either
|
|
|
enthusiasts have continued to voice their opinions, including the ever-controversial Brock Pierce who recently espoused some interesting views.
Brock Pierce is only an enthusiast for living with convicted paedophiles and attending dubious parties where teenagers are invited to do drugs with adults from the US entertainment industry (Brock Pierce is a former child movie actor himself). That's more than controversial.
|
|
|
I doubt that's being updated any longer, it was superseded by "headers-first" downloading in version 0.10 (parallel downloading didn't work before headers-first. Bittorrent only downloads, it doesn't check the blocks, which is what really takes all the time). Version 0.10 was a very long time ago.
Additionally database format was changed since Core 0.15.0 which means you'll need to wait for database conversion to newer format and verify the blocks. I've no idea how long it'd take, but probably you will waste more time rather than download whole Blockchain using Bitcoin Core directly. I think only the chainstate database changed format, and I would assume the torrent file contained only the blocks. It makes no difference anyhow, the torrent is probably not being seeded anymore, and of course using Bitcoin to do the IDB is, as you say, quicker in any case
|
|
|
I doubt that's being updated any longer, it was superseded by "headers-first" downloading in version 0.10 (parallel downloading didn't work before headers-first. Bittorrent only downloads, it doesn't check the blocks, which is what really takes all the time). Version 0.10 was a very long time ago.
|
|
|
My question is if my amount left in multi-signature address of channel is 0 BTC, and i want to deposit more BTC for more transactions, will my existing channel will be closed? And should i need to reopen that channel? Or I can use my existing channel? And how many transactions will be recorded on blockchain?
A future feature called "Splicing" will enable this functionality. It's a fairly new idea though, it will take a while to get implemented in Lightning software. The idea is for both "Splice-In" (what you're asking for: adding on-chain funds to a pre-existing channel, without closing the channel), as well as "Splice-Out" (withdrawing funds from a channel using an on-chain tx, without closing the channel)
|
|
|
I'm pretty satisfied with eclair mobile, you just have to realise it's a mobile wallet intended to PAY for services, it's not intended to receive payments The Eclair developers will apparently release a new version later this year that lets you receive lightning payments
|
|
|
You guys are doing this on your own volition as there is no official organization for BTC?
There's a handful of people (3 or 4 I think) that have merging rights to add or remove from Bitcoin's code. Then there's dozens of contributors who offer changes. The 3-4 that push the merge button only do so when they get the agreement of at least another 3 or 4 code contributors who are regulars on the project. If it's something totally trivial, like changing documentation, the mergers might not bother wasting time getting agreement first, though. It's pretty informal overall (and typical for an open source project in that regard).
|
|
|
I want to believe as time goes by, this processes and steps to use the lighting network would be further simplified or seamless because if all these steps are not simplified as a result of further developments
You don't need to "want to believe", it's already much simpler if you stick with wallet default settings. The simplest, and default way to setup a Lightning wallet is like this: 1. Send some BTC to your wallet 2. Wait till the wallet finishes automatically opening some channels
|
|
|
It wouldn't make sense to let a customer that's new to the LN make a connection to a different node and then hope there'll be a route between the node they made a channel to and mine
That's true, it's 100% routable if it's a direct channel I don't even knew about the steps required if I hadn't read mocaccino's posts Those steps are only needed if you want more control. By default, lightning wallets will use an autopilot mode that handles the detailed setup
|
|
|
I'm running a LN for many months now, and i've accepted over 70 LN payments (not an impressive number, i know), but all of the payments came from customers that opened a direct channel between their client and my node...
Are you suggesting as such on your site (opening a channel to your node)? That's a pretty good way of making your node well connected and routing alot of payments This demonstrates the lightning model; any regular business can encourage their clientele to open channels direct to them, which makes financial sense for regular clients. You're basically your own mini-payments service, VISA can't compete with that.
|
|
|
Ok so it seems that I had a big misuderstanding of bi-directionnal channels, thank you all.
We've discovered an issue though: it's possible to confuse "dual-funding" and "bi-directional". Maybe there's a different phrase that could be used to make them both more distinct. Perhaps "dual-funded" channels could be referred to as "balanced" channels, and "single funded" channels as "unbalanced" also, people might get the idea that channels only flow one-way (as you did). Perhaps that can be made clearer somehow too.
|
|
|
I'm interested to see your comment about my being racist, and this seems to be the cry of people who are losing arguments.
You made a mistake using racism as an argument. It's guaranteed to end in an unproductive, confrontational thread. And of course, you're now being labelled racist. These sorts of arguments are very predictable like that, you have yourself to blame in not doing so
|
|
|
Basically, you have to incentivise your clients to: - 1) Install a decent desktop wallet on their pc
- 2) fund their desktop wallet with a couple hundred bucks worth of BTC
- 3) install a LN client on their mobile phone, create a new address, fund the address with "spending money"
- 4) open a channel between the client and the store's node, fund it
After these 4 steps, a store can generate a lightning invoice (QR) and let the customer scan and pay straight away... Works flawlessly, but still, i don't see my mother performing these steps... Also, the fact that you'd have to close the current channel if you wish to open a new one (when you have insufficient funds in your current channel for planned expenses) is a drawback. You can actually skip step 1, and switch step 2 and 3 (create a LN wallet right away, create a deposit addy and fund it straight from the exchange), but i would discourage anybody to keep a lot of funds on a mobile wallet. The biggest "drawbacks" would probably be to get somebody to visit an exchange or some other seller to exchange FIAT to BTC... There's no need to open a channel with the store. As a user, the minimum setup is 1 channel, to any well connected node. The software and the network takes care of the rest. That doesn't mean you can't do all the configuration yourself, as you describe. But the idea is to simplify the process, what you've written is the most complicated way, and in the case of the channel with the store, unnecessary.
|
|
|
|