Ok, so imagine this scenario:

I run a business, I need a supplier. You guys, NeuroFish and JetCash, are both suppliers in contention for the role.

Obviously there are alot of factors that will lead me to choose who I will work with, but one of them is definitely how much information about our relationship will end up being sold to my competitors by Google or Amazon.


TBH, I treat even just regular people like this. Are you so lazy with computers that you're practically just one of Google's brain cells? I don't talk to people like that much.

this is somewhat a case of jumping out of the fire and into the frying pan


Mint (and also Ubuntu) have been openly shipping spyware software in their Firefox package for years now. Guess who the beneficiary is? Amazon.

(don't forget that Amazon is more of a web server company than anything else now, so if one assumes shopping habits at webstores that aren't Amazon is what they're analysing, think again)

Edit: So really, Mint/Ubuntu is jumping out of one fire and into another


Best bet if you're starting with Linux is (IMO) Debian, or Devuan. Mint/Ubuntu are just versions of Debian anyway (so most web advice for Ubuntu/Mint also works the same on Debian).


And if Mint will sacrifice your privacy openly, what kind of standards do it's developers have at all?

that's unreasonable

From segwit activation (September '17 IIRC) to Jan 2018 was just a few months. Segwit couldn't possibly be used to react to big hike ups in tx backlogs straight after it activated, that wasn't quite enough time for the whole of Bitcoin to move to segwit addresses, and then start spending from them . Good thing too, blocks stayed effectively capped at ~ 1.1MB until Jan '18, compromise: achieved

seems you forgot the reasoning why BIP100 got rejected too, but whatever



so....

• mempool full: because segwit
• mempool empty: because segwit

uh, ok

This stinks of an attempt to re-define what "decentralised" or "cryptocurrrency" actually means, there is no chance that the IMF would let this guy speak on their platform if he in any way represented a threat to the IMF's position as a monetary authority.

Let's not forget that Allaire and his company quit Bitcoin in 2015 when their attempts to assert influence over Bitcoin development failed. Let's not forget that the only reason Allaire and Circle failed was because people running Bitcoin Core refused to switch to the (long since dead) Bitcoin XT software.

e.g. the entirety of the year 2018,  during which mempools were half empty?



which problem?

blocks are too big? or blocks are too small? By choosing to use P2PKH addresses, blocks stay smaller. If you use segwit addresses, blocks can be made bigger.

Compromise: achieved

So something a little strange may be happening.

If I do:


then I get


whereas if walletcreatefundedpsbt chooses the inputs like this:


it returns a base64 string, and the outputs that supposedly cannot be signed from the previous command are chosen as inputs.


but then using utxoupdatepsbt on that string doesn't create any outputs, and both ScriptSig and ScriptPubkey in the metadata section are blank, although txids from the wallet are present. I am confused.


Edit: I was wrong, vout is 1 not 0. *sigh*

Sorry to anyone trying to follow along, this is really just one big case of me being too impatient mixed with not knowing what I'm doing

shit, it does.



Maybe an example at the bottom of the help text would help, but that's no excuse for me not reading the help properly

I've never seen this way of handling command parameters before, in bitcoin or elsewhere! But maybe this is something typical in RPC interfaces?



So at the moment I'm only familiarising myself with the commands for PSBTs. I'm doing this particular example very simply, so I'm letting bitcoin-cli create a standard redeem script, and I'm using P2PKH addresses for both inputs & outputs as further means of keeping things as simple as possible (I'll do all this with segwit transactions once I have the redeemScript I want to use working with P2PKH).

On the machine I'm using:

The outputs with the txids and amounts I'm providing as inputs to the PSBT are returned by listunspent. They've got >6 confirmations, and they were not mined, but they were sent from mined outputs on another machine on my regtest-net.

then


So there surely must be something going badly wrong with my setup... I find it hard to believe you guys don't have a test for such simple circumstances.

maybe I should specify exactly what I want to do


Either:

A. Receiver creates a .psbt file, with no inputs specified, but 1 or more outputs that pay to a custom ScriptPubKey (details of doing that are ot for this thread). Payer takes the .psbt, adds their input, signs it, broadcast

or if that's not possible...

B. Receiver creates the ScriptPubKey they wish to be paid to, Payer takes that and creates the .psbt themself, using that/those outputs, adds their own inputs, signs, broadcasts


Which (if either) of these is possible?

How could I have figured that out without asking? The available docs/help don't make any mention of that

And perhaps I'm getting the conceptual details wrong again, but that doesn't change the result of decodepsbt, I get an array of inputs but no outputs.
(yes, the wallet for the inputs is loaded in the machine I'm using)



Using the same inputs as I used for createpsbt, I'm getting:


(again, the wallet containing the inputs is loaded on the machine I'm using)

so I'm trying various things








...and all are rejected. I have inputs (which I apparently cannot choose?), but no outputs

doh, just figured it out

walletprocesspsbt is what's needed to specify inputs

still don't understand the purpose of the transaction: array, will these turn into the outputs after I figure out the magic words to do that? (I am attempting now to find the answer myself...)

indeed



didn't take you long to abandon "the free and uncontrolled market", lol


Segwit's working as the compromise it's supposed to be. Only 2% of addresses are even using segwit addresses, because many people just aren't aware, and also since the industry as a whole has only really now begun to support it (probably a good idea, taking risks with new tech in the real world could be an expensive mistake).

So until more users and businesses switch, 1.2MB average blocks is as big as they'll get. If you want bigger blocks and cheaper fees, the incentive is there, use it. Or don't. It's a f(r)ee market

It's not at all clear how this should be done


According to bitcoin-cli help createpsbt:


When using the form from the help as above, the inputs array is never populated if checking it using decodepsbt

(slightly ot: why are inputs/outputs added to the transaction: array at all? What's the difference between inputs/outputs in transaction: and those in inputs: and outputs?)


utxoupdatepsbt the resulting base64 string doesn't make any changes to the PSBT


Either there is some syntactic structure missing from the help message, or there is some other 'addinput/output' a RPC call that isn't obvious to me

well, this is only the millionth time this "news" has been broadcast


@Vladdirescu87

yet again, please stop posting this moronic "news items"

Setting up own node is best. You can go various lazy routes, but they either put someone else in charge of your money or your privacy (so exactly the same as regular on-chain Bitcoin)



Wrong.

Transactions on the Bitcoin network are either slow _or_ expensive, not both.

You can choose:

• cheap and slow
• fast and expensive

There is no "slow and expensive" option

There's nothing you can do to control that. You can use information about a node's uptime and how old it's present channels are to help you make good decisions. The incentives are to keep channels open as long as possible, but there have been bugs in the node software that can cause channels to be auto-closed when it was in fact unnecessary. Understanding the various lightning software, and keeping up to date on those details is important at this stage in LN node software development.



Right, bearing in mind the caveats above

no it's not, that's the least likely option

I recommend the opposite:


Red Hat (who make Fedora and Centos) are abusing their position in the Linux world. They're recreating important parts of Linux (init, desktop, device interface etc) in a way that forces you to use all their stuff.

The sensible way is to make components that are small, and compatible with alternatives. Red Hat are doing the opposite, making huge system components that force everyone else to become compatible with them (and lots of Linux software and distros are going along with this).

This approach makes it much harder to change bad software for good software, because the bad software is such a fundamental part of Linux underlying everything else


Don't use Red Hat's stuff, or anything else that uses Red Hat's stuff, there are better designed alternatives with smaller, better code (and hence fewer bugs) that don't lock you into their way of doing things.

hard forking bugs out of Bitcoin (not serious bugs though) do have some consensus, but it's unlikely to happen anytime for a while because of how unimportant they are. But that means there are hard forks that could get consensus.

they have to show up: in your channel, and also for the other person in your channel (there must be 2). So at least 1 person extra knows you have money, because they relayed it to you. That person has no idea where the money came from though.