however well intended, the same company that sponsors Bitcoin developers also mining BTC is a conflict of interest. It's a good thing they're not the only organisation sponsoring developers, but I still would prefer that this had not happened.

the BetterHash pool is a good counter balance however. Anything that helps decentralize the mining market adds to Bitcoin's strength, even if Betterhash is a modest move in that direction. This should push other pools into adopting Betterhash also.

With any luck, Blockstream will be totally incompetent or too naive to enter the mining business, and rolling out Betterhash will be all that remains of this story in the long term

correct, except making the lightning/bitcoin daemon more favorable is not what you want to keep the raspi stable

try giving bitcoind (and your lightning daemon) a positive nice number, e.g.


this tells the linux kernel to de-prioritize CPU cycles that would otherwise be scheduled for a given process. All userland processes have an implicit nice value of zero, which means there's a FIFO style dynamic in the way they are served by the CPU. The range of valid nice values is from 19 (maximally nice) to -20 (not at all nice). htop tells you what nice value is assigned, possibly top will too

this should help to smooth out resource usage on a raspi


another angle is to boot directly from an SSD (and put your swapfile on the SSD also). This might only work on rasPi 3's, cannot remember specifically. The /boot partition can stay on your microSD, as it's not performance contingent, and likely read-only too. You just need to tell the config files in /boot to start the init process from /dev/sda (or whatever device your SSD system disk is)

it's conceptually similar, so you can see how someone could make such a mistake (or deliberately state the falsehood as fact in order to bash Lightning)


the similarities end in the redemption; if you redeem an IOU, the issuer might just refuse (or make an excuse). But the issuer of funds in a Lighting channel is the Bitcoin blockchain, and so when you "redeem", it accepts no matter what.

i.e. payment channels have the advantages of an IOU without the drawbacks

neutrino's probably improved since you last used it, but I don't have any experience of that. The bitcoin network will have alot more neutrino nodes in either the October release or the April release of the core node software, but until then you'll be relying on the small number of btcd nodes that support it

yes it's called "trolling", it happens on the internet

nested segwit inputs are a little bigger than old style inputs, but bech32 (i.e. native segwit) inputs are a little smaller

if you're sufficiently adept, your BTC is safer than your bank account money


I hate having to repeat myself on the same page of the thread, but that's why Bitcoin will always be in demand: because your BTC will always be safe. You can't say that about anything else to the same degree, which is why it's the ultimate safe haven, as long as that inviolable ownership characteristic remains stable.


All the below assets are subject to the "......aaaaaaaaaaand it's gone" problem

• bank accounts
• pension funds
• stocks
• bonds
• property
• commodity based (gold + others)

if someone with sufficient political power wants to take any of the above from you, they can (it's happened before). That's why Bitcoin is valuable and in demand, it cannot be confiscated (from people who are capable of protecting it)

the proposals (BIP118 is just one such proposal) for no-input opcodes don't malleate the transaction hash, that's not possible anymore.

They do alter (or malleate if you prefer) which input is used after the transaction has been written (but obviously not once it's confirmed)

This makes payment channel protocols much better. Using them for on-chain transactions has no benefit, and comes with the risk you mention; if you reuse an address, and you sent a no-input transaction from that address once before, someone could replay the old transaction to spend the newer input, as the old transaction didn't specify a particular input (hence "no-input"). But no wallet developer is going to give you the option to use no-input onchain, that'd be dumb

still, the devs have been talking about exactly how to design the no-input feature for maybe 1 year now. they're being very careful, because it's definitely possible for the user to shoot themselves in the foot if they get too inquisitive and start trying to use no-input in transactions without understanding how it could backfire on them. It's not possible to do anything like that in Bitcoin transactions now, all the footguns were taken out of the scripting language years ago

this is the latest forum troll you're shouting at

don't feed the trolls, it does not work

redundant disk solves that, a seed cannot. For a phone, just keep literal pocket change amounts on a phone. How often does an entire phone fail anyhow?



nope, I'm not saying either of those things, and that's not how I use Lightning at all. Money comes in, money goes out; there's not much need to go back on-chain, you just need to put some thought into how you manage it.

no, the wallets used to manage Lightning channels do have a seed in every implementation


there's no seed for the channel addresses, but that's not relevant, as the funds will always end up back in the addresses of the underlying bitcoin wallet should a channel be closed.


think of it like this; Lightning channels are like a checking account, for regular comings and goings of cash. saying the channels don't have seeds is like complaining your debit card didn't come with a bank vault and an armed guard

organized crime is always, always at some level sanctioned and overseen by their native spy agency.

which makes your following comment.....



.....naive.

Although law enforcement and financial regulators are not all part of organized crime, important members of in those organizations are, and help gangs and banks to legitimize profit from crimes.

Do you read newspapers? They're constantly full of stories about exactly that, and there's almost certainly plenty more that is never detected and thus never reported on.


So, appeals to "clean up" bitcoin are a bit of a joke, when you realize that the foxes are guarding the hen coop anyway. if bitcoin somehow eliminated (detectable) "bad" activity, corruption would enusre it continues in the banking system regardless

Bitcoin's crossed the 'safe haven' rubicon already, chaps


it's simple

if you buy anything, any other asset:

• there's a risk you will not be permitted to own it at some point
• there's a risk that it goes to zero (the market price, or the value of your investment once you are relieved of it's possession)

if you buy Bitcoin:

• it cannot be re-appropriated from you
• consequently it is always in demand
• things that are always in demand always have a price

the only real sticking point is that not everyone has quite grokked the situation for what it is, despite Munchkin and Obomb-er referring to Bitcoin as a "swiss bank account". There's no helping some people

it is already

• there is a world
• that world is a globe
• Bitcoin is a currency
• Bitcoin is used throughout aforementioned globe

ergo, Bitcoin is a global currency


furthermore, Bitcoin is a reserve currency. people hold it long term, in reserve. central banks and government treasuries do not hold Bitcoin reserves. but why would we care about that

everything you needed to understand the two segwit types is on page 1 of this thread. we're only on page 3 right now.

you're overcomplicating it still. massively.

just use the nested segwit addresses. the ones starting with a 3

it's easy. you can't go wrong that way

and so it was that the thread did end

correct the word in bold please

and try not to use your phone to access the forum, it will make these autocorrect mistakes and confuse people reading the thread



you're overcomplicating it


just use nested Segwit until you've figured it out, it's the simplest way of reducing any potential mistakes

yes

(but Bitstamp can't send to those, as you know)



if they're calling it "Segwit", and choosing that gives your Ledger an address starting with a 3, then it's nested segwit. Maximum compatibility, hence why Bitstamp can send to that type