Bitcoin Forum
June 16, 2024, 06:06:14 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Bitcoin / Armory / 0.96.5 - BLKDATA DB does not have the requested ZC tx on: May 16, 2023, 10:33:29 PM
I tried getting Armory 96.5 working on my Qubes 4.1 machine (4.0 is really not supported any more), and all was well until this last part

compiling was really the same as 94-96.x, using debian 10/buster toolchain, no issues

-INFO  - 18:09:08: (BlockUtils.cpp:915) blkfile dir: /home/user/.bitcoin/blocks
-INFO  - 18:09:08: (BlockUtils.cpp:916) lmdb dir: /home/user/.armory/databases
-INFO  - 18:09:08: (lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 18:09:08: (BDM_Server.h:263) Listening on port 63221
-INFO  - 18:09:08: (nodeRPC.cpp:57) RPC connection established
-INFO  - 18:09:08: (BlockDataManagerConfig.cpp:919) waiting on node sync: 99.9997%
-INFO  - 18:09:08: (nodeRPC.cpp:425) Node is ready
-INFO  - 18:09:08: (BlockUtils.cpp:1108) Executing: doInitialSyncOnLoad
-INFO  - 18:09:08: (BDM_Server.cpp:1121) registered bdv: 4a80c146a3552190f2b4
-INFO  - 18:09:08: (DatabaseBuilder.cpp:199) Reading headers from db
-INFO  - 18:09:25: (DatabaseBuilder.cpp:238) Found 723305 headers in db
-INFO  - 18:09:33: (DatabaseBuilder.cpp:64) Rewinding 100 blocks
-INFO  - 18:09:33: (DatabaseBuilder.cpp:71) updating HEADERS db
-INFO  - 18:09:33: (DatabaseBuilder.cpp:493) Found next block after skipping 1660080bytes
-INFO  - 18:09:35: (DatabaseBuilder.cpp:281) parsed block file #3599
-INFO  - 17:53:09: (DatabaseBuilder.cpp:281) parsed block file #3600                                                                                                                                                
-INFO  - 17:53:11: (Blockchain.cpp:248) Organizing chain                                                                                                                                                            
-INFO  - 17:53:18: (Blockchain.cpp:370) Organized chain in 6s                                                                                                                                                      
-INFO  - 17:53:24: (DatabaseBuilder.cpp:76) updated HEADERS db in 908s                                                                                                                                              
-INFO  - 17:53:25: (lmdb_wrapper.cpp:388) Opening databases...                                                                                                                                                      
-INFO  - 17:53:25: (DatabaseBuilder.cpp:1231) verifying txfilters integrity                                                                                                                                        
-INFO  - 17:54:06: (DatabaseBuilder.cpp:1314) done checking txfilters                                                                                                                                              
-INFO  - 17:54:07: (DatabaseBuilder.cpp:134) scanning new blocks from #723305 to #790065
-INFO  - 18:06:46: (BlockchainScanner.cpp:852) scanned from block #789756 to #790065
-INFO  - 18:06:46: (BlockchainScanner.cpp:214) scanned transaction history in 759s
-INFO  - 18:06:47: (BlockchainScanner.cpp:1789) resolving txhashes
-INFO  - 18:06:47: (BlockchainScanner.cpp:1848) 0 blocks hit by tx filters
-INFO  - 18:06:47: (BlockchainScanner.cpp:1937) found 0 missing hashes
-INFO  - 18:06:47: (BlockchainScanner.cpp:1982) Resolved missing hashes in 0s
-INFO  - 18:06:47: (lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 18:06:47: (DatabaseBuilder.cpp:186) scanned new blocks in 760s
-INFO  - 18:06:47: (DatabaseBuilder.cpp:190) init db in 1726s
-INFO  - 18:06:47: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
-INFO  - 18:06:53: (BlockchainScanner.cpp:857) scanned block #790066
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2086) BLKDATA DB does not have the requested ZC tx
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2087) (scrubbed_but_valid_hexdata)
-WARN  - 18:10:17: (LedgerEntry.cpp:334) failed to get tx for ledger parsing

subsequently, ArmoryDB only seems to perform "Wallet Properties" callbacks, most everything else produces errors in the qt log

the ERROR line from lmdb_wrapper.cpp repeats dozens of times. And the gui reports "node offline"
2  Bitcoin / Development & Technical Discussion / BIP119/OP_CTV: is this a unilateral fork, and does anyone care? on: April 21, 2022, 01:24:55 PM
according to, the answer to my question is no.

But if we look at:



then it is a little less clear.

Some reddit personalities (who are also devs in some cases) have expressed disquiet that the author of BIP119/CheckTemplateVerify is acting too unilaterally, and for sure, he is not following the process that previous soft-forks went through in order to gain acceptance.

So I guess my question is not technical: is this not inherently political, even if BIP119's author intends it to be, or even realizes it at all? Because the proposal seems ok, but it seems that acceptance of this way of working sets a precedent for someone else to propose similar such fork-activations, only to claim "this is how forks are done now", then we might have the Classic/Unlimited/BIP10x/hard fork nonsense repeated again.

usual thread rules; no trolling, no trolls

sorry if off-topic, feel free to move
3  Bitcoin / Armory / debian 11/bullseye deps on: November 13, 2021, 08:57:23 PM
seems like this will not work (easily)

so far:

  • no qt4
  • no psutil

I'm guessing any psutil functions were rolled into python3 "native" libraries, which doesn't help at all Undecided
I guess also there are probably more dependency problems, but no qt4 already seems too serious as things stand.

to what extent is dev branch at usable for everyday stuff? Or is this where we all realize that Armory is (for now) pinned to Debian 10 and version 0.96.5?

my recent experience with other packages that need a python2 interpreter suggest that other Linux distros don't make this any easier
4  Bitcoin / Bitcoin Technical Support / [22.0 rc + HWI] Bug: entering a 2nd URI fails on: August 28, 2021, 10:06:49 AM
steps to reproduce:

1. open Bitcoin Core Qt 22.0rc2
2. enter payment URI
3. send
4. send succeeds
5. enter a different URI
6. GUI does not register the uri details in the send "tab"

only restart seems to reset whatever it is needs state resetting

this is involving my testing of HWI with 22.0, FWIW. Latest HWI, Debian Buster as a Qubes VM

@achow101, I believe
5  Bitcoin / Development & Technical Discussion / [Taproot softfork] "Speedy trial" activation on: March 06, 2021, 12:19:09 PM
New proposal:

(based on this bitcoin ML post:


  • 3 months BIP 9 activation (no activation lock-in when it ends), starting April 14th 2021 (so soon), ending July 14th
  • 3 month delay till the actual soft-fork after activation (October 1st 2021 would be the date of the soft-fork, regardless of when it is activated)

So miners/pools get a chance to demonstrate their goodwill, but don't have to update their nodes in a big rush (potentially pushed on them by their rivals' signalling for the soft-fork)

In the meantime, the discussion about what to do if the opportunity is missed can continue, including anyone preparing unilateral activation movements fashioned on BIPs 148 and 91.

Sounds ok to me. FWIW, people in the #taproot-activation channel seemed to like it too.

Rules: No trolls, no trolling
6  Bitcoin / Development & Technical Discussion / [Taproot softfork] lukejr removing option to lock-in on timeout... :D on: March 01, 2021, 09:31:23 AM

background: link to Taproot Proposal thread

tl;dr, luke is writing code for activating soft forks in Bitcoin, and he thinks it was a mistake to make an option for the new soft fork code for Taproot to lock-in automatically (this happens if miners don't signal to activate before the fork's activation time limit is over.)

I agree. If there's a mix of nodes signalling to activate (LOT=true) and not signalling (LOT=false), a wide variety of problems can occur, especially if miners activate without paying attention to what other nodes are signalling. For that reason, miners might take the safe option of _not_ activating, assuming they don't want chaos. The other way to look at it is that some miners might like some temporary chaos, as it gives them or any friends of theirs with spare fiat to buy any market dip caused by said chaos.

The potential for chaos if people can choose which LOT they want is pretty high. It's both possible, and possible to exploit. So, I agree with luke. Stability, of every facet, should be the paramount concern.

The subtext to most arguments revolving around this issue is:

  • 1. let people decide for themselves
  • 2. we must be sure that they know and understand what they have chosen

Point 1 is easy. Point 2 is hard, and probably not realistic.

But I disagree with the idea that pushing out LOT=true with Bitcoin 0.21.1 is somehow forcing users into something they didn't want.

Everyone is responsible for understanding what's in the Bitcoin software they run (and for all software they run). Significant numbers of people don't pay any attention though, and that's unlikely to change much before or immediately after Bitcoin 0.21.1 is released (although I'd argue that the trend for being more conscious of "what's in my software" is increasing).

So the decision seems easy to me:

  • Release Bitcoin 0.21.1 with LOT=true, no option to configure it
  • Running 0.21.1 or not becomes the choice as to whether the soft fork activates

This way, all potential chain forking chaos is avoided, and most of the drama will be neutralized.

Don't like Taproot? Then don't run Bitcoin 0.21.1, and you can try to convince others to do the same. It's simple to understand, and if people don't understand it, then making the options more complicated is a perfect recipe for making the situation much, much worse.

Thread rules: No trolling, no trolls
7  Bitcoin / Press / [2021-01-22] OKCoin to integrate Lightning Network on: January 22, 2021, 10:40:01 PM

rollout in Q1 this year apparently

So now exchanges supporting LN are:
  • Some private US one of which I forgot the name
  • Bitfinex
  • FixedFloat (crypto only)
  • Kraken (soonTM)
  • OKCoin (sooner than Kraken)

I don't mean to gloat, but there appears to be an accelerating number of exchanges offering (or preparing) Lightning, as I predicted they would. Well, maybe I am gloating slightly Tongue Cool Grin
8  Bitcoin / Press / [2020-12-16] "Kraken to launch bitcoin lightning integration in 2021" on: December 16, 2020, 02:57:07 PM

Kraken is excited to announce new investments and forthcoming features designed to bring the benefits of Bitcoin’s Lightning Network to our global exchange.

Building on Bitcoin’s blockchain technology, the Lightning Network will help the world’s largest cryptocurrency scale to process millions of transactions per second, a leap forward enabling trades to be completed at a lower cost and with greater speed.

In 2021, we are committed to hiring a team to focus specifically on the Lightning Network, as part of our continuing effort to deliver the best possible experience for traders and investors.

We expect to allow clients to withdraw and deposit Bitcoin on Lightning in the first half of 2021, which will allow clients to move their Bitcoin instantly and with the lowest fees.

But easier deposits and withdrawals are just the beginning of the additional features we are aiming to provide. By joining Kraken’s Lightning Network team, you can shape the future of programmable payments with digital money.

If you have an eye for front-end or UX design or if you have experience with open-source Lightning protocol development, we are interested in your application.

Apply here
About the Lightning Network

An in-progress innovation, the Lightning Network will enable Bitcoin to be moved into new types of channels secured by the Bitcoin blockchain.

The Lightning Network is evolving quickly and there are numerous open-source and free wallet solutions that already support this new bitcoin payments platform. For merchants, BTCPay Server offers a Lightning Network integration, enabling e-commerce stores to receive fast and cheap Bitcoin payments.

Note: Lightning Network wallets are connected to the internet, and aren’t advised for long-term safe-keeping. Please carefully review your Lightning wallet’s documentation to ensure you are using it correctly.
9  Bitcoin / Development & Technical Discussion / [validation performance] ECDSA GLV endomorphism patent expires Sep 25th 2020 on: September 18, 2020, 04:12:04 PM


2:06 < sipa> hi!
12:06 < sipa> this is mostly a short announcement so it doesn't cause any surprise
12:07 < sipa> libsecp256k1 started out as an experiment to see how much secp256k1 EC operations could be made by using the GLV endomorphism optimization, which it was specifically designed to support, but not actually implemented anywhere
12:07 < luke-jr> vasild: that's kinda the point; it reduces to one config format
12:07 < fjahr> hi
12:07 < sipa> as it turned out that there is some risk it is encumbered by a patent, the GLV optimization was made optional, and defaults to off (and has been off in every bitcoin core release)
12:08 < sipa> it looks like that patent is expiring on september 25th, and blockstream had a patent attorney verify that (i'm happy to share their findings, if anyone cares)
12:08 < wumpus> yay!
12:08 < cfields> wooo!
12:08 < luke-jr> sipa: how sure can we be that it can't break consensus?
12:08 < sipa> so the plan is to switch it to default on after that date, or even rip out the non-GLV code
12:08 < sipa> luke-jr: good question
12:09 < luke-jr> is it provable? :x
12:09 < sipa> libsecp256k1' CI has always tested with both endomorphism enabled and disabled
12:09 < sipa> including our exhaustive tests, which are probably as close to a mathemetical proof we can get for real software - at least for some aspects
12:10 < sipa> fwiw, that's a test where the library is compiled with a slightly different curve equation that makes it trivially insecure, and only leaves 12 valid private/public keys
12:10 < sipa> and in that mode, we can test literally every combination of signature/pubkey/private key
12:11 < wumpus> nice
12:11 < sipa> so i think that given that, it shouldn't be any more invasive than regular code changes to libsecp256k1
12:11 < luke-jr> has it been proven on a mathematical level? (not saying it's a problem if not, just asking)
12:12 < sipa> luke-jr: for some parts of the code we have actual proofs (some hand-written, some automatic); though admittedly not the part touched by the endomorphism
12:12 < wumpus> I think he means in mathetmatical theory, not so much the specific code
12:12 < luke-jr> right
12:13 < sipa> wumpus: for the group arithmetic, there is a transliteration of the C code to python, which is then symbolically executed and can be automatically proven correct
12:13 -!- guest534543 [~mix@] has joined #bitcoin-core-dev
12:13 < provoostenator> Very cool, somewhat scary, but how much of a speedup is this?
12:13 < sipa> the conversion from C to Python (or its semantics) of course aren't, but the algorithms at a slightly higher level are proven
12:13 < wumpus> sipa: that's a very interesting approach
12:13 < sipa> provoostenator: 27% for ecdsa verification
12:13 < provoostenator> Ok, that's worth some code review time alright.
12:13 < wumpus> very hard to say no to that Smiley
12:14 < sipa> well
12:14 < sipa> arguably, libsecp256k1 originally _only_ had the GLV mode
12:14 -!- davec [] has quit [Ping timeout: 272 seconds]
12:14 < sipa> the mode where GLV was disabled (which is now default) was added later
12:14 < wumpus> yes it was added out of patent concerns
12:15 < sipa> yes
12:15 < sipa> but all changes since 2013 have always kept both GLV and non-GLV working, and tested
12:15 < meshcollider> Interesting, I didn't know that
12:15 < luke-jr> was the GLV mode ever released in Core?
12:15 < wumpus> no
12:15 < sipa> luke-jr: it's a compile time option, and it was never enabled in (default) builds of core
12:16 < sipa> you could always enable it yourself with --enable-endomorphism
12:16 -!- davec [] has joined #bitcoin-core-dev
12:16 < luke-jr> right, not sure how many people actually did that tho :p
12:16 < wumpus> some people did it for benchmarking at times
12:16 -!- Kiminuo [~mix@] has quit [Ping timeout: 260 seconds]
12:16 < wumpus> apart from that, dunno
12:16 < sipa> luke-jr: i assume nobody
12:16 < vasild> If there are concernts, what about doing all calculus in both and comparing they produce the same result?
12:17 < luke-jr> we do have a USE flag for it in Gentoo, but no metrics on usage

the above sounds rather promising: IBD (and validation in general) could see significant performance gains if this (already well tested for several years) feature is enabled in the distirbuted Bitcoin binaries/packages.

And interestingly, it appears we can compile all previous releases of Bitcoin using libsecp256k1 (back to 2013, I think) with this --enable-endomorphism option (possibly it needs enabling in the configure script for libsecp256k1 only, didn't check that yet). The Gentoo package for Bitcoin has (possibly always?) allowed it as an option, so maybe some people have been testing this without being aware they are breaking the patent restrictions.

my initial reaction was the same as someone later jokes in the chat:

1. cryptography patent
2. patent expires, and so people actually start using formerly patented code
3. (no) profit

10  Other / Off-topic / [2019-10-31] Why 'Shitcoin minimalists are like ______" according to Mr. Nobody on: October 31, 2019, 01:06:02 PM
Not sure what to make of this story. Has anyone heard of this person before? Seems a bit self-important for a person that's done pretty much nothing except sit around exhaling bad breath with some apparent words mixed in Cheesy


In exciting new news, new to Bitcoin, a brand-new complete nobody has newly announced that their new meaningless opinion is the same thing as what he said 2 seconds earlier.

Dubbed "Bitcoin's Invisible Man" (so-called because of their publicity-shy transparency), Mr. Nobody tweeted every minute of the day last week in the most objective way yet:

Quote from: Mr Nobody
I am not the most important person in Bitcoin, and I don't know anything about it. I haven't got anything important to say, and you should all join my Bitcoin website and club

Mr. Nobody went on to explain that God had recently told him the truth about everything, ever:

Quote from: Mr Nobody
Everybody likes me, and if you don't, it's just because you are a HATER. You are basically ADOLF BITLER!!!
And for the last time, I am NOT a loser Angry

In conversation with his imaginary friend Bitcoin Re-hash, Nobody went on to say:

Quote from: Mr Nobody
What was that Bitcoin Re-Hash? You're saying you're very healthy, and would like some not-spoofed transactions to eat for your breakfast? I can give you some hot air and an empty website full of people I paid to talk to you if you like? What's that, you want some real food? How about me and Craig Wright do some mud-wrestling for you? Or me and Christine Lagarde could kiss with tongues?"

I think we can all agree Bitcoin friends, this is groundbreaking stuff from Mr Something-or-other!  Be sure to subscribe to his feeds to find out the next important chapter in this story!!!

Wow! I literally cannot contain my excitement about this! Everyone should reply to tell us what they think about this crucial development in Bitcoin, we need to make sure it gets the attention it deserves!!
11  Bitcoin / Development & Technical Discussion / [meta] Rust in Bitcoin reference implementation on: October 13, 2019, 10:31:26 AM
Rust is a new-er programming language, and has a reasonably good reputation:

  • liked for being more difficult to make mistakes with than C/C++ (although not impossible, of course)
  • for being sufficiently powerful in expressiveness, yet relative simplicity compared to C/C++
  • disliked because compiling the actual Rust compiler was until recently not possible (we have gnu's guix system to thank for that)

So, there's been a Rust implementation of Bitcoin around for a while, and some good programmers actually preferred to spend their time re-implementing the existing Bitcoin client in Rust than to work on the reference C++ implementation. Which is a good plan in and of itself, as a proof of concept if nothing else.

There are now plans to implement Rust code into the main Bitcoin implementation:

speaking as a non-expert on either language, but as a Bitcoin user who does understand something about coding and computer science, I'm unenthusiastic about this.

I understand the rationale:

  • Rust code has lower review burden
  • The plan is to duplicate non-consensus C++ code, to add redundancy to network consistency/reliability
  • Rust is proven these days, compiler can be bootstrapped

that's all ok.

however, one plan is not to use a Rust compiler that is bootstrapped from a trustworthy source (Canonical's Rust compiler). Call me nuts if you so choose, but that seems like a very cavalier decision to make with software that should be putting security first. You can say "trusting Canonical is subjective", in which case, it should be ruled out altogether in such a critical piece of software as Bitcoin

my other concern would be the "thin end of the wedge" argument.

The rationale for putting the specific Rust code into the Bitcoin codebase is sound; if headers fetching code fails in some unknown circumstance, maybe only the C++ implementation of the headers fetching code will fail, and the Rust headers fetching will continue to function without incident. Hell of a supposition to make, but it's somewhat reasonable, as there is some acceptance that Rust can be written in such a way that certain types of bug are less likely (but not impossible)

But this would make it too easy to say "let's just re-write the main implementation in Rust, piece by piece! After all, failover Rust code is working great so far!"

In the end, such a radical change (I'm sure that statement will be a point of contention, but it's essentially self-proving by the virtue of the fact that this is a contorversial change of direction) was always bound to be divisive.

The developers who are keen to send Bitcoin in this direction should realise that there's no real practical difference between doing something divisive for good reasons, or doing something divisive to cause problems in the project.

usual thread rules, + 1 extra:

  • no trolling
  • no trolls
  • discussing personalities or intentions or politics of those debating is not allowed, and will be removed, e.g. "Bjarne Sostroup says x about Rust" is disallowed, everything must be provable in it's own right, here in the thread, written by you

the technical merits and the consequences to how the Bitcoin project is managed are the focus of this thread
12  Bitcoin / Development & Technical Discussion / [minisketch] Draft Erlay tx relay BIP published on: September 27, 2019, 01:11:34 PM

exciting, I didn't expect progress so quickly since the announcement of the Minisketch library this Spring.

This implementation does something really smart; @naumenkogs has opted to snip the txids to a fraction of their full length, then adds a salt to guard against hash collisions. This saves more bandwidth than set reconciliation alone. The total bandwidth savings are apparently ~40% over the flood based transaction relaying that Bitcoin uses now (and that's the figure for a "private" node with 8 outgoing connections, public nodes with hundreds of connections will save far more bandwidth).

I think daily tx relay on average uses something like 300MB? Not sure. If so, that would mean cutting that to 180MB Cool

If this is an easy BIP to review, it could make it into Bitcoin next year Smiley
13  Bitcoin / Press / [2019-09-24] BITCOIN NETWORK HASHRATE IN SPOOKY 40% FLASH CRASH !!!!1 on: September 24, 2019, 06:14:01 PM

Authored by Marie Huillet via,

Bitcoin’s network hash rate dipped a record 40% yesterday, Sept. 23, in a sudden shock for the network.

Data from - corroborated by other sources - indicates that the network’s hash rate plummeted yesterday from over 98,000,000 TH/S to 57,700,000 TH/s.
Mystery flash crash remains unexplained

The flash drop remains unexplained as of press time and is all the more striking given the Bitcoin network’s record-breaking string of new all-time high hash rates throughout summer.

Just five days ago, Cointelegraph had reported that Bitcoin’s hash rate had passed a record 102 quintillion hashes in a historic milestone.

As previously noted, the hash rate of a cryptocurrency  sometimes referred to as hashing or computing power  is a parameter that gives the measure of the number of calculations that a given network can perform each second.

A higher hash rate means greater competition among miners to validate new blocks; it also increases the number of resources needed for performing a 51% attack, making the network more secure.

By press time, Bitcoin’s hash rate has somewhat recovered back to almost 88,300,000 TH/s  yet remains well below its earlier records.

Throughout summer, cryptocurrency analysts had argued that the network’s record-breaking streak of all-time hash rate highs was a bullish indicator for the top coin’s price performance.

In a tweet posted this August, Bitcoin investor Max Keiser had claimed that:

Quote from: Max "Barry Silbert's Bitch" Keiser
   “Price follows hashrate and hashrate chart continues its 9 yr bull market.”

Back in November 2017, Bitcoin had seen a sudden hash rate downturn of almost 50%, accompanied by slowed transaction processing times, a price dip, and even miners’ short-lived switch over to the forked network, Bitcoin Cash (BCH).
14  Bitcoin / Development & Technical Discussion / [Lightning decentralisation] Routing around hubs on: August 30, 2019, 11:59:45 AM
  • could Lightning decentralisation be improved by giving node operators a "do not route thru X" config option?
  • could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?
  • how might this affect fees?
  • how might this affect liquidity?
  • how (if at all) might this inter-operate with delegated (i.e. "trampoline") routing?

trolls/trolling not tolerated

please post questions and/or answers

15  Other / Meta / [TROLL-UKKAKE] People who argue with trolls on technical matters are suspicious on: August 26, 2019, 03:15:35 PM

What is the difference between BCT users who argue with technical trolls


"astro-turfing" users who are actually working with the trolls to make it appear like there's still a legitimate argument taking place

Example: Segwit thread on Discussion sub


Not much
16  Bitcoin / Hardware wallets / [TREZOR One] Can the bootloader be upgraded? on: April 26, 2019, 03:29:57 PM
So I have a fairly old TREZOR One with bootloader 1.3. This is too old to upgrade to the newest (1.8+) Trezor One firmware, minimum bootloader is 1.5 for firmware 1.7+

New versions of the bootloader can be downloaded and built from, but it seems as though the only option is to destroy the outer shell of the Trezor, then flash the new bootloader manually. Then you have a naked Trezor with no outer shell!!!

Is that really the situation? Surely there's another way? :-/
17  Bitcoin / Bitcoin Technical Support / PSBT/BIP174: how to create inputs/outputs using bitcoin-cli on: April 12, 2019, 09:50:49 AM
It's not at all clear how this should be done

According to bitcoin-cli help createpsbt:

createpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...]

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
18  Bitcoin / Bitcoin Discussion / [Anti Bitcoin] Lightning Loop: closed source and anti-competitive on: March 21, 2019, 10:56:26 AM
Lighting Loop announced today:

So Lightning Labs are operating a new service that does everything their lightning client (called "lnd") should be doing, and they intend to begin to charge businesses a fee to do this!


"The service can be used in various situations:

  • Acquiring inbound channel liquidity from arbitrary nodes on the Lightning network
  • Depositing funds to a Bitcoin on-chain address without closing active channels
  • Paying to on-chain fallback addresses in the case of insufficient route liquidity"

I get why: businesses don't even need their own lightning node to do this.

But the Loop servers will be a central point of failure, so any kind of attack against those servers will undo any adoption Loop could stimulate, and harm Lightning's reputation in the process.

If Lightning Loop is such a good technology, and Lightning Labs are a competitive provider of services using that tech, then they can open source the server code so that others can set up Loop servers and compete openly. But they've chosen monopoly status as a provider of Loop, and all the negatives that brings with it.

Lightning Labs do not want an open competition, and any adoption of Loop will create a significant point of failure for the Lightning network. Lightning Labs are shooting themselves in the foot doing it this way.
19  Other / Meta / [Feature suggestion] A list of which users that posted in a certain thread on: March 14, 2019, 10:26:36 AM
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)
20  Other / Meta / Should PGP keys be made mandatory for high ranks? on: March 02, 2019, 01:26:26 PM
Maybe start out saying Legendaries must register PGP keys within a timeout that starts after their most recent login? Then move that requirement down the ranks slowly.

It seems like PGP usage is sort of encouraged, but then again there is also a field in Profile Settings for MSN and Skype handles Roll Eyes If PGP is needed to recover accounts, why not actually make it a part of the forum? Given that Bitcoin is really a part of a wider push towards personal cryptography as a whole, I'm slightly surprised we're still at the "post your public key in this thread" stage
Pages: [1] 2 3 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!