Bitcoin Forum
September 25, 2018, 10:31:27 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 »
1  Bitcoin / Press / [2018-09-01] The Economist: Show me the Money & Riding the Rollercoaster on: September 10, 2018, 02:54:57 PM
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.

2  Bitcoin / Bitcoin Technical Support / Incoming connections/Port forwarding: is bind=<IP> needed, and why? on: August 20, 2018, 12:45:05 PM
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?
3  Bitcoin / Alternative clients / Python-TREZOR: Do bech32/bc1 addresses work yet? on: June 09, 2018, 04:14:58 PM
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

Quote
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?
4  Other / Meta / @Admins: Merit not working as configured, trolls just don't care (no surprise) on: April 18, 2018, 03:13:03 PM
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.
5  Bitcoin / Bitcoin Discussion / Segwit BIP141 heading for 50% miner signalling on: June 25, 2017, 07:36:12 AM




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.
6  Bitcoin / Armory / Armory Army? on: April 01, 2017, 08:34:11 PM
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"  Cheesy

But where's the "Armory Army" medallion?
7  Bitcoin / Bitcoin Discussion / Segwit IS the compromise: everybody is equally unhappy with it, including me on: March 12, 2017, 01:53:50 PM
"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. Sad





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.


8  Bitcoin / Development & Technical Discussion / [RFC] Multi-stage client fork: SegWILL on: March 09, 2017, 10:32:13 PM
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
9  Bitcoin / Bitcoin Technical Support / Core 13.2: Segfault/Block retention on: February 14, 2017, 12:56:05 AM
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.
10  Bitcoin / Armory / BIP 143 and Armory wallet format on: October 18, 2016, 07:09:05 PM
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....)
11  Alternate cryptocurrencies / Altcoin Discussion / Celebrity "Libertarians" who advocate the Bitcoin XT putsch on: October 22, 2015, 01:07:49 PM
They're beginning to out themselves:



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.
12  Bitcoin / Bitcoin Discussion / Google have been conspicuously quiet about Bitcoin for 6 years. What gives? on: August 21, 2015, 12:26:42 PM
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?
13  Bitcoin / Bitcoin Discussion / Which innovation in Bitcoin do you REALLY want? on: August 17, 2015, 05:52:36 PM
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?
14  Bitcoin / Armory / Building Armory with Gitian on: April 15, 2015, 08:46:26 AM
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?
15  Bitcoin / Armory / Building Armory on Fedora 20 on: July 18, 2014, 07:11:16 PM
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'
16  Bitcoin / Armory / Is it possible to compose a single tx using outputs from multiple wallets? on: July 15, 2014, 09:31:14 PM
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.
17  Bitcoin / Bitcoin Technical Support / Issues with installing Bitcoin-Core on Fedora 20/Qubes 2 rc1 on: July 15, 2014, 02:50:55 PM
Hello all

Problems with getting bitcoin installed and working on Qubes 2 rc1 (which is essentially Fedora 20 using the Xen hypervisor by default)

So far:

  • Installed the www.ringingliberty.com repo in the fedora-20-x64 template successfully, as well as the bitcoin-qt and bitcoin-server packages (thanks to Alice Wonder for troubleshooting with that)
  • Launched Bitcoin-Qt in a VM that uses the fedora-20-x64 template. Error message states that /var/lib/bitcoin cannot be created as datadir
  • Launched Bitcoin-Qt in the same VM, but using the command line to prepend the command with "sudo". Blocks begin to download, but a search shows they are not saving to disk, and the client refuses to shutdown cleanly. etc/bitcoin is created, but var/lib/bitcoin is not
  • Created /var/lib/bitcoin as root before launching Bitcoin-Qt. Error generated is:

                    Runaway exception

                    Exception: N5boot12interprocess22interprocess_exceptionE
                    No such file or directory
  • Tried just picking the standard location for the datadir (~/.bitcoin), and the blocks are downloading and being saved (and so permissions are playing some role in this issue). But it seems less than ideal, I fear this will only cause more problems down the line

So, does anyone have any insight to this? Being able to set this up would be pretty useful as a way of making bitcoin use more secure (the idea is to segregate all usage related to using and maintaining bitcoin to this VM).
18  Bitcoin / Armory / Consistent output precedence for tx's from a single address? on: June 14, 2014, 09:54:03 PM
I think everyone mining is probably familiar with this: do multiple outputs get chosen in a predictable order when spent from a single address? If yes, what's the order? Reverse date order? (i.e. highest priority first)
19  Bitcoin / Press / [2014-4-9] Coindesk - MultiBit User’s Loss Highlights Need for New Wallets on: April 09, 2014, 10:15:26 PM
http://www.coindesk.com/multibit-user-loss-high-need-bitcoin-wallets/

Multibit has somewhat of a reputation for buggy behaviour that causes less catastrophic problems. Most interesting is this pair of quotes:

“Until now wallets have all been written by volunteers who put huge time and effort in for free. This is one reason bitcoin has low transaction costs, but it isn’t sustainable.”
“One of the most critical transitions the community will have to make this year is to a world where most of us are paying for our wallets in some way.”

Is this a call for protocol enforced fees to fund development? Seems like a strange way of making the case for that.
20  Bitcoin / Armory / Monetize Armory development with dedicated hardware on: April 08, 2014, 05:30:27 PM
I'm thinking about this while contemplating my call a month or two ago for people to consider the most secure operating system/hardware setup for using Armory.

All the various innovations to increase the feature set revolve around security (offline signing, M of N backups, M of N addresses etc). These two strands could usefully be brought together: for instance, an Armory LiveOS CD would be a useful security appliance. And further to that, Armory terminals (maybe stratified into home, commercial or corporate editions) that do nothing but Armory with security being the end goal. Dedicated Armory signing devices, and/or fully fledged hardware wallets, would also be useful (even if such devices are so simple that it's largely a question of inking a deal to rebrand and resell an existing product, manufacturers of POS terminals and hardware wallets already exist).

Yes, I'm aware that dedicated hardware incurs even more development costs. But it's likely the best way to maintain funding for a free and open software distribution, which is always going to be a real challenge.
Pages: [1] 2 3 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!