So the rationale for introducing transaction weight is to put a separate price on signature operations, to reflect the resources sigops use when running a fully validating node (i.e. a price component for block space and a price component for sigops when determining tx fee).

Should this be reflected in the weight value assigned to transactions using schnorr sigs in the future?



Using schnorr sigs already reduces the proportion of a tx comprising the signature:

• BIP-schnorr defines a standardised 64kB size, smaller than the typical ECDSA sig size (71-72kB)
• Schnorr permits signature aggregation, that treats the sum of >1 signature as a single valid signature for more than 1 transaction tx input
• Taproot will allow conditional branches in more spending scripts to be collapsed into a Merkle root hash for all branches, so only the condition that is met is ever recorded on the blockchain

All the above reduce the space that signatures use on chain, and sig-agg can reduce the number of sigops used drastically for transactions with multiple inputs.

But batch verification works across an entire block of transactions, which would improve verification performance ~2x according to BIP-schnorr. That would make far more difference to validation performance than any of the points above, as it functions whether using sig-agg/taproot or not (and the 64kB size reduces space on chain, not sigops).


My question is: to incentivise the gains for the network, should schnorr sigs be assigned a lower weight than ECDSA sigs? It seems to make sense, given how much validation performance can be realised.

libminisketch was published last week: https://github.com/sipa/minisketch/blob/master/README.md

This is a software library that can be used to allow set differences to be encoded and relayed using less data than before. Bitcoin currently relays blocks using a different technique known as "compact blocks" (BIP152), but Minisketch should improve on the performance of compact blocks by several factors (also, compact blocks fail if the amount of transcations a node needs to reconstruct a given block is lower than a certain threshold).

This type of technique has been suggested as a scaling technique in the past, but the suggested method (IBLT, inverted bloom lookup tables) has probabilistic decoding performance, and hence has an associated failure rate. Minisketch always decodes successfully.

Not only could Minisketch reduce the amount of data needed to relay blocks between nodes, but could also be used to reduce the amount of data needed to relay transactions. Current relay can use 200-300 MB bandwidth per day, using Minisketch as part of the tx relay method will reduce this considerably (alot of redundant inventory request/reply messages are sent with the present relaying logic, i.e. nodes use significant bandwidth simply asking each other "which transactions have you got")


It's obviously early in the Minisketch story, but this is a p2p layer change that doesn't require a soft fork to implement. Along with other potential improvements to help the Bitcoin network's resource load (Schnorr, taproot, MAST, rolling UTXO set), we could be using a significantly leaner network this time next year.

So, issues

Here's what I'm trying:

Code:

$ bitcoin-cli createrawtransaction "$(cat ./tx.json)"
error: Error parsing JSON:'''[{"txid":"notarealtxid78ahfjb73qhb54jhb6fe7f7efkjbekshc9jh38394394hddskdskflnotarealtxid","vout":0}]''' '[{"1NotARealBitcoinAddress":0.01}]'

It should work, but doesn't (sendrawtransaction does work this way, eg. bitcoin-cli sendrawtransaction $(cat hextxsavedtoafile)


However, it works if I supply the json directly to the command:

Code:

$ bitcoin-cli createrawtransaction '''[{"txid":"notarealtxid78ahfjb73qhbjhbfefefkjbekshc9jh38394394hddskdskflnotarealtxid","vout":0}]''' '[{"1NotARealBitcoinAddress":0.01}]'

That's the same json that gets rejected when trying to use "$(cat file)" to supply the json data


Is this a bug in bitcoin-cli, or am I being naive about what the cat command is actually sending to the createrawtransaction command? Seems strange that sendrawtransaction can work this way, but createrawtransaction will not.

[Socialists are in full on brain washing mode:]

Liberalism (the John Lock/Adam Smith type) is being undermined by Orwellian bullshit, and powerful people in the conservative and socialist contingents are leading the charge

Socialists are in full on brain washing mode:

"So hey, d'you believe we should cooperate in a team to make society greater than the sum of it's parts? Congrats, you're a liberal, just like us!!!"

What they really mean: let's use group pressure to be really intolerant of anything we wouldn't choose for ourselves, and try to force everyone to choose what we think will work, and call it liberalism.


Conservatives are in full on brain washing mode:

"So hey, d'you believe individuals should make their own choices, and that the good deserve good things and the bad deserve bad things? Congrats, you're a (classical) liberal, just like us!!!"

What they really mean: let's keep powerful liars in the same place they are now (because being the best liar means you deserve good things), use power to stop competition because "responsible freedom", then call it liberalism


Whatever happened to the actual idea of liberalism? Powerful people do not like it, hence why they try so hard to distort what it is.

[Show me the money - Bitcoin and other cryptocurrencies are nigh on useless. For blockchains, the jury is still out]

Show me the money - Bitcoin and other cryptocurrencies are nigh on useless. For blockchains, the jury is still out

An old saying holds that markets are ruled by either greed or fear. Greed once governed cryptocurrencies. The price of Bitcoin, the best-known, rose from about $900 in December 2016 to $19,000 a year later.
Recently, fear has been in charge. Bitcoin’s price has fallen back to around $7,000; the prices of other cryptocurrencies, which followed it on the way up, have collapsed, too. No one knows where prices will go from here. Calling the bottom in a speculative mania is as foolish as calling the top. It is particularly hard with cryptocurrencies because, as our Technology Quarterly this week points out, there is no sensible way to reach any particular valuation. It was not supposed to be this way. Bitcoin, the first and still the most popular cryptocurrency, began life as a techno-anarchist project to create an online version of cash, a way for people to transact without the possibility of interference from malicious governments or banks. A decade on, it is barely used for its intended purpose. Users must wrestle with complicated software and give up all the consumer protections they are used to. Few vendors accept it. Security is poor. Other cryptocurrencies are used even less. With few uses to anchor their value, and little in the way of regulation, cryptocurrencies have instead become a focus for speculation. Some people have made fortunes as cryptocurrency prices have zoomed and dived; many early punters have cashed out. Others have lost money. It seems unlikely that this
latest boom-bust cycle will be the last. Economists define a currency as something that can be at once a medium of exchange, a store of value and a unit of account. Lack of adoption and loads of volatility mean that cryptocurrencies satisfy none of those criteria. That does not mean they are going to go away (though scrutiny from regulators concerned about the fraud and sharp practice that is rife in the industry may dampen excitement in future). But as things stand there is little reason to think that cryptocurrencies will remain more than an overcomplicated, untrustworthy casino. Can blockchains the underlying technology that powers
cryptocurrencies do better? These are best thought of as an idiosyncratic form of database, in which records are copied among all the system’s users rather than maintained by a central authority, and where entries cannot be altered once written. Proponents believe these features can help solve all sorts of problems, from streamlining bank payments and guaranteeing the provenance of medicines to securing property rights
and providing unforgeable identity documents for refugees.

Nothing to lose but your blockchains
Those are big claims. Many are made by cryptocurrency speculators, who hope that stoking excitement around blockchains will boost the value of their related cryptocurrency holdings. Yet firms that deploy blockchains often end up throwing out many of the features that make them distinctive. And shuttling data continuously between users makes them slower than conventional databases. As these limitations become more widely known, the hype is starting to cool. A few organisations, such as SWIFT, a bank payment network, and Stripe, an online-payments firm, have abandoned blockchain projects, concluding that the costs outweigh the benefits. Most other projects are still experimental, though that does not stop wild claims. Sierra Leone, for instance, was widely reported to have conducted a “blockchain-powered” election earlier this year. It had not. Just because blockchains have been overhyped does not mean they are useless. Their ability to bind their users into an agreed way of working may prove helpful in arenas where there is no central authority, such as international trade. But they are no panacea against the usual dangers of large technology projects: cost, complexity and overcooked expectations. Cryptocurrencies have fallen far short of their ambitious goals. Blockchain advocates have yet to prove that the underlying technology can live up to the grand claims made for it.




Bitcoin: Riding the Rollercoaster - The best-known cryptocurrency has been a failure as a means of payment, but thrilling for speculators

The price chart at CoinDesk, a cryptocurrency news site, begins on July 18th 2010, when a bitcoin could be had for $0.09. By November 2013 it had reached $1,124. In the summer of 2017 it started to take off, reaching over $19,000 in December. By end-March 2018 it was back down below $7,000 and in late August it was hovering between $6,400 and $6,500 (see chart, next page). That has made a few people very rich (just 100 accounts own 19% of all existing bitcoin), encouraged others to play for quickgains and left some nursing substantial losses. Bitcoin was never meant to be an object of speculation. When the pseudonymous Satoshi Nakamoto published a short paper outlining his plan for bitcoin a decade ago, it was as a political project. Bitcoin’s roots lie in the “cypherpunk” movement, a philosophy that combines an anarchic dislike of governments and large companies with the techno-Utopian belief that computers and cryptography can liberate and protect people. Much of the early development of the internet was informed by similar ideas. Bitcoin was intended as a computerised version of cash or gold, a “censorship-resistant” alternative to online payment systems run by companies such as Visa and PayPal. If trust in a central authority could be replaced with trust in computer code and mathematics, users could cut out the middleman and deal directly with each other, rugged individualist to rugged individualist. Electronic cash is not a new idea. In a paper published in 1982 David Chaum, a computer scientist, had suggested using cryptography to create electronic cash, and the cypherpunks had been kicking such ideas around since the late 1990s. What made Mr Nakamoto’s invention stand out was that he had found a solution to one of the biggest problems with computerised money how to keep users from spending the same digital coin repeatedly without relying on a trusted authority to check every transaction. With a physical currency, this problem mostly takes care of itself. Once a coin or note has been handed over, its original owner can no longer spend it. But digital currencies are just wisps of information on a computer, and computers are designed to move and copy information easily. Mr Nakamoto solved the problem by handing the job of policing the system to its users. Bitcoin is designed to generate a permanent, constantly growing list of every transaction ever performed with the currency the “blockchain”. Since all users have a copy of the system’s records, they would spot attempts to spend the same bitcoin twice. A centralised institution like a bank can simply update its internal records every time its customers perform a transaction. Since bitcoin is decentralised, though, all transactions must be broadcast to everyone on the network so that they can update their local copies of the blockchain. When two parties want to make a transaction, they alert everyone else of their intention. Those proposed transactions are bundled into blocks by a subset of users called “miners”, whose job is to maintain the records and ensure their integrity. Every block is connected to its predecessor by a chain of cryptographic links, which makes it next to impossible to alter records once finalised. In order to prevent malicious miners from subverting that process, bitcoin requires something called “proof of work”, in which
miners demonstrate their commitment by competing to crack mathematical problems that are hard to solve but whose solutions are easy to check. Only the winner of each competition is allowed to add a block to the chain. The network aims for an average block-generation rate of one every ten minutes. If blocks come in faster than this, mining is made harder to slow things down. All that computation takes a lot of electricity, and hence money, so each new block earns its miner a reward, starting off at 50 bitcoin in 2009 and programmed to halve every four years. It is currently 12.5 bitcoin, or around $80,000. These block rewards are the only source of new bitcoin in the system. Mr Nakamoto argued that central banks cannot be trusted not to debase their currencies by printing money, so he set a hard limit of 21m for the number of bitcoin that could ever be mined. All this may sound complicated, but the system generally works. Bitcoin can be used to make payments between any two users of the software, and though the experience is not exactly like using cash, it is a reasonable electronic analogue. Even so, bitcoin has failed to become an established currency, let alone as its more ideological supporters had hoped to flourish as an alternative to the traditional financial system.
One reason is that it is still not user-friendly. All participants have to download specialist software, and getting traditional money into and out of bitcoin’s ecosystem is fiddly. Moreover, although the lack of a central authority makes the system resilient to attempts at coercion, it also means that if something goes wrong, there is no one who can fix it. The original idea was that bitcoin users would “be their own banks”, responsible for the security oftheir own funds, says David Gerard, a cryptocurrency-watcher and systems administrator. But that is harder than it sounds. If you lose access to your stash of bitcoinsay, by mislaying a USB stick or accidentally overwriting a hard drive it can be impossible to recover. Many users therefore store their bitcoin on exchanges (companies that let users trade ordinary currency for the cryptographic sort). But many exchanges are amateurish operations and have an unenviable record of being hacked. And when bitcoins are stolen, there is no insurance scheme to make the owners whole. Nor are there any other protections of the sort that modern consumers take for granted. Mr Nakamoto’s original paper proudly points out that with bitcoin, chargebacks (used when a credit-card holder disputes a transaction) are impossible. There are structural problems, too. The size of an individual block of transactions is fixed, and the network enforces an average block-generation rate of one every ten minutes. In practice, that limits bitcoin’s throughput to around seven transactions per second. (Visa’s payment network can manage tens of thousands.) So when demand for bitcoin transactions is high, the system clogs up. Users have to accept that their transactions may be delayed or not go through at all, or offer miners extra fees as an incentive to prioritise their payments. Mr Nakamoto had hoped that bitcoin’s transaction fees would settle at fractions of a cent, but at the height of the boom in late 2017 they briefly reached $55. They have since come down to about $0.65.

Faster, faster
Bitcoin’s developers have tried various tweaks and workarounds to ease the jam. A scheme called SegWit, first introduced in August 2017, has provided a little extra wiggle room. A more ambitious proposal, called the Lightning Network, hopes to take the bulk of transactions off the ponderous blockchain system and getting users to trade directly with each other, but after a couple of years in development it remains plagued by reliability problems. One recent evaluation by Diar, the cryptocurrency-research firm, found that Lightning transactions became increasingly less likely to be completed successfully as they got bigger. Volatility, insecurity and occasional congestion make for a poor currency, so bitcoin has done best on the economic fringes. One use is for buying drugs and other dodgy items from online black markets, where buyers and sellers are prepared to put up with the downsides because they want to cover their tracks. It can help citizens of countries with currency controls get around them, says Alistair Milne, a financial economist at the University of Loughborough. And some cyber-criminals have turned to it for ransom demands. Legitimate businesses, with a few exceptions, have proved more cautious. A report from JPMorgan published in 2017 found that, of the top 500 online retailers, only three accepted bitcoin, down from five the year before. Among those that have stopped supporting it are Expedia, a travel agency, and Valve, which runs Steam, an online video-games shop (which cited “high fees and volatility” as the reasons). Chainalysis, a research firm based in New York that tracks data from 17 different bitcoin merchant payment processors, found that monthly transactions peaked in September 2017 at $411m, and had declined to $60m by May this year.

The South Sea bubble redux
The volatility that makes bitcoin unattractive as a currency also makes it an exciting target for speculation. “If we’re being honest,” says Tim Swanson, the founder of Post Oak Labs, a firm that provides technology advice, “the majority of people are buying [cryptocurrencies] because they hope the price will go up, rather than for any great philosophical reason.” Condemnation from prominent figures has only added to the
currency’s allure. Warren Buffett, a wealthy American investor, has called bitcoin “rat poison”. Jamie Dimon, the boss of JPMorgan (the sort of financial institution that bitcoin fans dislike) has described it as “a fraud”. A research note from Goldman Sachs, a bank, published in July, describes cryptocurrencies as “a mania” and concludes that they “garner far more attention than is warranted”. Still, back in May the same bank announced its intention to open a cryptocurrency trading desk, citing demand from its customers. Autonomous Next, a financial-research firm, reckons that 175 cryptocurrency funds were set up in 2017, up from just 20 the year before. Would-be punters will need a strong stomach. Bitcoin is thinly traded and barely regulated, and rumours of large-scale price manipulation have been supported by unusual trading patterns on
exchanges. A paper published by two researchers at the University of Texas at Austin asks whether Tether, another cryptocurrency, is being used to prop up the price of bitcoin. Governments are beginning to take notice. In May South Korean regulators raided Upbit, that country’s largest cryptocurrency exchange. In the same month America’s justice department began a criminal investigation into manipulation of bitcoin’s price. Official scrutiny, and the recent drop in prices, have spooked many investors. Goldman Sachs argues that bitcoin remains overvalued. But for every bear there is a bull. Tim Draper, a venture capitalist who made his fortune backing technology companies, has forecast that by 2022 a bitcoin will be worth $250,000.

[-listenonion=0]

Trying to get incoming connections over tor, and it's a mixed success.

I have a static hs for the node (and so I have -listenonion=0), and I got just 1 incoming connection that actually used the NETWORK service (also BLOOM and WITNESS, all other nodes were crawling nodes without any services). That was a stable long lasting connection, so maybe it's working...

But there are alot of debug messages like

Code:

Socks5() connect to <ip:port> failed: connection refused

...so it seems that there could be something in the config that's preventing the majority of peers connecting to the node.

Also, trying to use bind=<proxy IP> gives this fatal startup error:

Code:

Unable to bind to <proxy IP>:18333 on this computer (bind returned error Cannot assign requested address (99))

What is error 99?

Or, should I simply be expecting low numbers of incoming connections over tor?

[python-trezor]

so I found this info about using bech32 addresses with python-trezor: https://github.com/trezor/python-trezor/blob/master/docs/EXAMPLES.rst#bitcoin-examples

Get first receiving address of first account for Bitcoin (Bech32 native SegWit P2WPKH):

trezorctl get_address --coin Bitcoin --script-type segwit --address "m/49'/0'/0'/0/0"

Get first receiving address of first account for Bitcoin (SegWit-in-P2SH):

trezorctl get_address --coin Bitcoin --script-type p2shsegwit --address "m/49'/0'/0'/0/0"

But in the tx signing section following, there's no mention of bech32. Anyone have any experience or knowledge of whether a Trezor will sign transactions spending outputs from bc1/bech32 addresses?

This might be somewhat unpopular, but is popularity the goal? A good resource should be the goal IMO, I exclusively read this forum for about 1 year before I felt knowledgeable enough to post at all.


Getting the signal:noise ratio up can probably only be achieved using real resources. I'd be very happy if a BTC cost was introduced for posting:

• Nuke the old rank status for all members, re-adjust according to merit only
• Charge BTC for every post, low rank = highest fee
• Set the charges incredibly low to begin with, slowly increase to tweak the quality level

Lightning payments would be necessary, of course. Maybe I'm taking too hard a line, but if I have to pay even 500 satoshis per post, that would be a small price to pay to improve quality again.

Look at the inverse situation: 1000's of accounts are posting meaningless, obvious, copy-pasta or troll content, only in order to get paid per post by sig campaigns or trolls-in-chief.

Price discovery can solve this problem, it's a geniune "tragedy of the commons" issue after all.

Looks like some more of the Bitcoin hashrate is signalling BIP141 (aka the original Segwit 4MB soft fork).


Could it be that all the uncertainty created by the chain-fork threat of BIPs 148, 149, Barrycoin and BitmainCoin are making the miners nervous, and they are now in search of stability and certainty? I would understand if that were the case.

I'm ever so slightly amused by the new "affiliation medallions" (which is the name I just made up for them). Accordingly, goatpig and Ente are "Dogecoin followers", TraderTimm is an unlikely "ETC proponent", droark still supports NXT, and most amusing of all IMO, I'm "Ripple chief scientist" 

But where's the "Armory Army" medallion?

["You know how you can tell it's a compromise? Because all parties are equally unhappy!!!!" - Larry David in the "Car Pool Lane" episode of Curb Your Enthusiasm]

"You know how you can tell it's a compromise? Because all parties are equally unhappy!!!!" - Larry David in the "Car Pool Lane" episode of Curb Your Enthusiasm


Larry David is famously pessimistic, but this particular truism applies very aptly to the Segwit proposal, and I will explain why.


4MB is too big. Very quickly after it activates, the transaction spammers could take advantage of the extra space, and stuff all 4MB with spam.




Here's how -

Single sig:
A typical transaction is around 250 Bytes in size, comprising 1 input and 2 outputs (1 output goes to the receiving party, the other goes back to the sender as their change). Only one person controls the spending keys for the input address, so only one signature is required.

Multi sig:
Multi sig transactions are different. They can have a wide range of sizes, while still comprising only 1 input and 2 outputs. The number people needed to sign the transaction increases the size of the transaction, like this:

• 500 Bytes for addresses controlled by 2 parties
• 750 Bytes for adressess controlled by 3 parties
• 1,000 Bytes for addresses controlled by 4 parties
• 1,250 Bytes for addresses controlled by 5 parties
• 1,500 Bytes for addresses controlled by 6 parties

etc.....





Visually:

Single Sig

<  250 bytes   >

|    -    | ||    -    ||
tx data    sig 1



2 party Multi-sig

<        500 bytes       >

|    -    | ||    -    ||    -    ||
tx data    sig 1    sig 2



3 party Multi-sig


<             750 bytes             >

|    -    | ||    -    ||    -    ||    -    ||
tx data   sig 1    sig 2   sig 3



4 party Multi-sig


<                 1000 bytes                  >

|    -    | ||    -    ||    -    ||    -    ||    -    ||
tx data   sig 1    sig 2   sig 3    sig 4








So, now that we can see clearly how increasing the number of people need to sign the transaction increases the size of the transaction, here's how it can be used to spam the 4MB size



1 Regular full 1MB block (i.e. HOW IT WORKS NOW)

|||      1 MB limit       |||

 <          1 MB          >

 |      -      | ||      -      ||
   tx data         sigs




1 Segwit block filled with 100% single sig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <          1 MB          >

 |               -              | ||              -              ||
            tx data                         sigs



1 Segwit block filled with 100% 2 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <                        2 MB                         >

 |               -              | ||                            -                             ||
            tx data                                       sigs



1 Segwit block filled with 100% 3 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <          1 MB          > <                                     3 MB                                       >

 |               -              | ||                                         -                                          ||
            tx data                                                    sigs



1 Segwit block filled with 100% 4 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <       0.8 MB       > <                                       3.2 MB                                     >

 |             -             | ||                                           -                                           ||
           tx data                                                    sigs



1 Segwit block filled with 100% 5 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <    0.667 MB   > <                                       3.333 MB                                     >

 |           -           | ||                                             -                                             ||
        tx data                                                     sigs



1 Segwit block filled with 100% 6 party Multisig transactions


|||                                                 4 MB limit                                                    |||

 <   0.571 MB  > <                                        3.428 MB                                      >

 |          -          | ||                                              -                                              ||
       tx data                                                     sigs






So, we can see from this exactly how Segwit's new structure and new blocksize limit can be abused by the spammers: simply create the same mega-flood volumes of transactions as now, using the maximum Multi-sig signing parties they can (the protocol defines 15 multi-sig signing parties as the maximum)


That could potentially produce a maximum of 0.25 MB block of transaction data and 3.75 MB witness block of signature data, cutting tx/s rate to 0.75/s. Not good.





What I hope this demonstrates is that Segwit indeed is not perfect, it's a compromise.

THESE ARE ONLY SCENARIOS. In reality, real users of the Bitcoin network will outcompete the spam using higher fees.


And so, what does increasing the blocksize really achieve? The spam potential scales up at the same ratio the transaction rate does. We'd have more space for transactions, sure, but the TX FEES WILL BE ESSENTIALLY THE SAME. And the blockchain will grow x4 as fast as it does now.





So, I'm not saying Segwit's a bad idea. IT'S A COMPROMISE, WITH DRAWBACKS, AND IMPROVEMENTS. The sooner people genuinely understand the trade-offs, and why small-block people such as myself prefer to keep an absolute 1MB limit, and use 2nd layer networks like Lightning, Sprite etc to achieve TRUE TX SCALING, the better.

[Stage 1]

I'm going to attempt to modify the 0.14.x clients, try to popularise the modified client so as to put this nonsense to an end.

I'm done talking with these cowards



Stage 1: BU is pushed to the edges of the network

Add a condition to net_processing::ProcessMessage that detects BU client strings and set the maximum banscore, invoking net::SetBan()


As more nodes run the SegWILL client, BU nodes become pushed to the edge of the network topology, isolating them from the vast majority of nodes (the obvious counter measure is to use regular Core clients as proxies for BU nodes to stay connected to the rest of the Bitcoin nodes, so this simply places the BU nodes around the edge, to make Stage 2 as effective as possible)





...when the effect of this is seen to be sufficient (judged manually by the proportion of nodes running SegWILL), we go to....
Stage 2: BU blocks are no longer relayed

Add a condition to validation::CheckBlock() that detects BU blocks, and rejects them.


BU miners either switch to a Satoshi-consensus client, or go down with the sinking ship




...when the effect of this is seen to be sufficient (judged manually by the proportion of BU blocks entering the chain being sufficiently low), we go to....
Stage 3: Non-BIP9 signalled blocks are no longer relayed

Add a condition to validation::CheckBlock() that detects blocks that lack BIP9 signalling, and rejects them.


If the miners aren't getting the message by this point, this will help them out further; start doing as the network wills, or prepare to enter the paperweight business






IF we can build high levels of support for this plan, and once it is sufficiently refined, I believe we can draw a line under this whole soap opera. We can demonstrate that the people who are actually supporting and or using Bitcoin are ultimately the arbiters of what gets accepted and what gets rejected vis a vis the Bitcoin protocol.



My Personal Message settings are set not to e-mail me any PM's, if that concerns you should you wish to PM me about this. A moderator can hopefully confirm this.



Please comment, on-topic

Core returns a segfault error to the command line every startup. Blocks from previous catchup are not retained, but the number of missing blocks is not the same in between startups.

Provoked by unclean shutdown of Core, I closed it during the Rescanning... tx scan stage.

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type

The linked section in BIP143 sounds alot like any attempt to spend an Armory wallet output (held by uncompressed public keys) to a P2WPKH or P2WSH address will not be relayed by default policy. Does this mean that we may have to rely on miners who use non-standard relay policy to spend directly to P2WPKH or P2WSH addresses? There's also a suggestion that trying this carries a danger that could render the outputs unspendable when the native Segwit addresses are activated.

(I realise the new wallet format could be used as an intermediate step. Sounds expensive to me though....)

They're beginning to out themselves:

• Roger Ver on Jeff Berwick's Anarchast
• Ian Freeman on Free Talk Live (regular occurence)
• Reason.com's Andrea Castillo claims XT represents the libertarian viewpoint
• Jim Harper of Cato.org explains why XT is not an existential threat to Bitcoin

Can these people really claim to want money that's "independent from government influence", as Jeff Berwick puts it, when the change to Bitcoin is being promoted by investment from (or association with former stellar employees) of Goldman Sachs/Wal-Mart/Accel/Santander/PayPal etc?

Can they really claim to be credible libertarians, seeking to promote a suppressed idea, when they themselves only promote one side of the debate?

It's not too late to save face and actually give a platform to these "smart guys" whose opposing opinion they claim to have respect for.

For the whole time the Bitcoin network has existed, Google has never once endorsed, denigrated or even alluded to Bitcoin. Not even once.

For instance, I've increasingly been seeing .99 cent Youtube videos creep into low volume channels for several months now. And because it doesn't seem quite plausible that Google can really afford all the bandwidth they serve up on Youtube, you can see how more pay-per-view content would help them out. It's a perfect use case for bitcoin, and a move like that could send the perception of Bitcoin up in the public's estimations (and possibly alos the exchange rate, too).

Are there any other blatant opportunities to commericalise bitcoin that Google has passed up on since the network started in 2009?

It seems to me like the issues in this debate are heavily conflated. What is everyone actually arguing about? What do you really want, a brand name product, more storage space on the ledger, or higher transaction rates? If you have to choose only one, which?

I know it's not finished yet, but I figured someone from ATI may know this: how essential is the OS to the process? I'm getting contradictory indications from reading up that it either doesn't matter/base Debian distro will do, or that everyone must use the same build of OS (Ubuntu 14.04?) to satisfy what Gitian needs to work?

Okay, so I think I have all the dependencies listed from the Armory website, but I still have an inexplicable build problem. sudo make exits with no apparent errors, it just writes a line about leaving the cppForSwig directory, then kaput.

One thing I'm spotting is that the DESTDIR variable in the base level Makefile declares an empty line as it's value, is that what it's choking on? Or is there supposed to be something else happening to build before the make command is run (something that passes the value to the top-level Makefile)?


Here's a sample of the output, from the last "leaving directory" line up until the last line before it quits to the command line:

Code:

make[2]: Leaving directory `/home/user/BitcoinArmory-0.91.2-rc1/cppForSwig/leveldb'
mv leveldb/libleveldb.a .
g++ -O2 -pipe -fPIC  -Icryptopp -Ileveldb/include -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS  -c -o sighandler.o sighandler.cpp
swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i 
Language subdirectory: python
Search paths:
   ./
   ./swig_lib/python/
   /usr/share/swig/2.0.11/python/
   ./swig_lib/
   /usr/share/swig/2.0.11/
Preprocessing...
Starting language-specific parse...
EncryptionUtils.h:178: Warning 362: operator= ignored
Processing types...
EncryptionUtils.h:133: Warning 402: Base class 'BinaryData' is incomplete.
BtcUtils.h:83: Warning 402: Only forward declaration 'BinaryData' was found.
C++ analysis...
Generating wrappers...
BlockObj.h:604: Warning 472: Overloaded method TxIOPair::TxIOPair(TxRef,uint32_t,TxRef,uint32_t) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockObj.h:648: Warning 472: Overloaded method TxIOPair::setTxIn(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockObj.h:650: Warning 472: Overloaded method TxIOPair::setTxOut(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:317: Warning 472: Overloaded method StoredHeader::setHeightAndDup(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:583: Warning 472: Overloaded method StoredScriptHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:647: Warning 472: Overloaded method StoredSubHistory::markTxOutUnspent(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
StoredBlockObj.h:709: Warning 472: Overloaded method StoredTxHints::setPreferredTx(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:197: Warning 472: Overloaded method AddressBookEntry::AddressBookEntry(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:262: Warning 472: Overloaded method ScrAddrObj::ScrAddrObj(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:301: Warning 509: Overloaded method ScrAddrObj::addTxIO(TxIOPair &) effectively ignored,
BlockUtils.h:300: Warning 509: as it is shadowed by ScrAddrObj::addTxIO(TxIOPair *).
BlockUtils.h:300: Warning 509: Overloaded method ScrAddrObj::addTxIO(TxIOPair *,bool) effectively ignored,
BlockUtils.h:301: Warning 509: as it is shadowed by ScrAddrObj::addTxIO(TxIOPair &,bool).
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:352: Warning 472: Overloaded method BtcWallet::addScrAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:698: Warning 509: Overloaded method BlockDataManager_LevelDB::SetDatabaseModes(int,int) effectively ignored,
BlockUtils.h:695: Warning 509: as it is shadowed by BlockDataManager_LevelDB::SetDatabaseModes(ARMORY_DB_TYPE,DB_PRUNE_TYPE).
g++ -I/usr/include/python2.7 -I/usr/include/python2.7 -O2 -pipe -fPIC  -Icryptopp -Ileveldb/include -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -c CppBlockUtils_wrap.cxx
g++ -shared -fPIC -lpthread -Lleveldb  -O2 -pipe -fPIC UniversalTimer.o BinaryData.o leveldb_wrapper.o StoredBlockObj.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a libleveldb.a sighandler.o  CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
pyrcc4 -o ../qrc_img_resources.py ../imgList.xml
make[1]: Leaving directory `/home/user/BitcoinArmory-0.91.2-rc1/cppForSwig'

I'm figuring that the protocol cannot distinguish whether the signatures from multiple outputs in a transaction are from a single private key or multiple private keys. If so, why not make that feature available? I'll slope away quietly if it's already possible, but I'm fairly sure it can't be done now.