Bitcoin Forum
April 25, 2024, 05:07:27 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] $SPRTS - Download New Sprouts Wallet Release 2.2.2 - Join us on Cryptopia on: February 13, 2018, 06:43:27 PM
Sprts can be staked on https://btcpop.co
We also provide a blockexplorer: https://sprts.btcpop.co ( Not always stable, we're still working on the setup for blockexplorers ).
Some Staking stats from Btcpop: https://sites.google.com/view/btcpopstaking ( not live ).
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: 【PRX】PRINTERIUM ★ 3D PRINTERS ★ POW/POS ★ WEB WALLET ★ ANDROID WALLET ★ YOBIT【★】 on: February 08, 2018, 02:29:48 AM
We've listed PRX on BTCPOP.
We do pooled staking and all staking rewards are shared to all coin holders based on their holdings.
Our node is 24/7 online so if you want to keep this coin alive you could deposit some coins to btcpop and get staking going.

I'll also setup a blockexplorer soon for this coin.
3  Alternate cryptocurrencies / Altcoin Discussion / Re: Staking pools on: February 05, 2018, 02:39:02 AM
On Btcpop.co we've a lot PoS coins and do pooled staking.
Fee is 2% so lower than Stake United and a lot more coins listed for Staking.
Pooled staking is higher reward because compound effect with more frequent payouts.
4  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]Spectrecoin[XSPEC] TOR+OBFS4, Ring Sig, Stealth! on: February 03, 2018, 12:38:03 AM
We've listed XSPEC on BTCPOP and I bought some my self to get the pooled staking a bit quicker started.
On BTCPOP you get staking rewards for all PoS coins you hold in your account and for coins in sell orders.
We've a lot PoS coins already on BTCPOP and keep adding more.
Soon we'll also offer shared Masternodes and a lot of Masternode coins.
5  Bitcoin / Armory / Re: 0.96.4 RC1 on: December 08, 2017, 03:08:14 AM
I'm trying to spend some mixed inputs but armory wont let me.

Code:
Traceback (most recent call last):
  File "/usr/local/lib/armory/ui/TxFrames.py", line 927, in createTxAndBroadcast
    self.createUnsignedTxCallback(ustx)
  File "/usr/local/lib/armory/qtdialogs.py", line 4607, in createUnsignedTxAndDisplay
    dlg = DlgOfflineTxCreated(self.frame.wlt, ustx, self.parent, self.main)
  File "/usr/local/lib/armory/qtdialogs.py", line 4651, in __init__
    reviewOfflineTxFrame.setUSTX(ustx)
  File "/usr/local/lib/armory/ui/TxFrames.py", line 1686, in setUSTX
    self.txtUSTX.setText(ustx.serializeAscii())
  File "/usr/local/lib/armory/armoryengine/AsciiSerialize.py", line 67, in serializeAscii
    return makeAsciiBlock(self.serialize(), headStr)
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2510, in serialize
    bp.put(VAR_STR, ustxi.serialize())
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 1698, in serialize
    bp.put(VAR_STR,      self.p2shMap[BASE_SCRIPT])
KeyError: 'base_script'

Is this with the latest state of testing?

Quote
Selecting only 1 type of inputs works.
Isn't it possible to mix segwit with non segwit inputs?

It should work.

Compiled few days back when i had the other issues.
Now i sent already with coin control and that worked so guess compiling latest makes no sense for now as I wont be able to test the same again.
6  Bitcoin / Armory / Re: 0.96.4 RC1 on: December 08, 2017, 02:00:47 AM
I'm trying to spend some mixed inputs but armory wont let me.

Code:
Traceback (most recent call last):
  File "/usr/local/lib/armory/ui/TxFrames.py", line 927, in createTxAndBroadcast
    self.createUnsignedTxCallback(ustx)
  File "/usr/local/lib/armory/qtdialogs.py", line 4607, in createUnsignedTxAndDisplay
    dlg = DlgOfflineTxCreated(self.frame.wlt, ustx, self.parent, self.main)
  File "/usr/local/lib/armory/qtdialogs.py", line 4651, in __init__
    reviewOfflineTxFrame.setUSTX(ustx)
  File "/usr/local/lib/armory/ui/TxFrames.py", line 1686, in setUSTX
    self.txtUSTX.setText(ustx.serializeAscii())
  File "/usr/local/lib/armory/armoryengine/AsciiSerialize.py", line 67, in serializeAscii
    return makeAsciiBlock(self.serialize(), headStr)
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2510, in serialize
    bp.put(VAR_STR, ustxi.serialize())
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 1698, in serialize
    bp.put(VAR_STR,      self.p2shMap[BASE_SCRIPT])
KeyError: 'base_script'

Selecting only 1 type of inputs works.
Isn't it possible to mix segwit with non segwit inputs?
7  Bitcoin / Development & Technical Discussion / Re: Bitcoin to Bitcoin Cash How Can I get it back? Wrong Transaction on: December 06, 2017, 08:45:35 PM
A lot altcoins use the same version bit and Poloniex has a big warning when displaying the deposit address.
Still poloniex should be able to recover them but probably it will cost them some work and time, they would need to export the key of your deposit address and import it in the correct wallet, then send you the coins on the correct chain.
8  Bitcoin / Development & Technical Discussion / Re: Why do people hate segwit so much? on: December 06, 2017, 01:20:40 PM
Core doesn't support segwit in full yet.
Core has merged bech32 addresses so with current version it should work to send to and receive from bech32 addresses.
I assume that everyone can receive from bech32 but older wallets can't send to them as they are invalid for them.

I like on chain optimizing so Bech32 isn't bad but who knows about Bech32? Maybe 0.1% of the Bitcoin users? Probably less.

And as said earlier, services often use bitcoind for their transactions and as long core doesn't support it in full they can't support it without a lot of development.
And even if services switch to Segwit then still not every transactions is segwit.
Coins already on services aren't in segwit addresses and moving them first to segwit to do segwit transactions increases the cost for services.
Adoption would start with offering deposit addresses for segwit and then some transactions will be segwit and some not till all coins are naturally turned over.
On the first step users could save a bit in fees on deposits but not on withdrawals on most services.
Hardfork with flextrans + bigger blocks would have solve all current problems and still would allow sidechain development.
This one was the worst solution with segwit, Till the time Segwit adoption comes closer to 100% the blocks will be full already also with Segwit transactions...
9  Bitcoin / Development & Technical Discussion / Re: Why do people hate segwit so much? on: December 06, 2017, 11:05:41 AM
I openly support on chain scaling, that was never a secret. 
I run for a while 100+ BU nodes just to show that the amount of nodes doesn't matter after a argument with someone who said that majority support core because it has more nodes.

The most lead devs of core wasn't around in 2011 at all.
Gmaxwell has "proven" how bitcoin can't work before even.
Luke-JR says that bitcoin should stay for nerds and shouldn't become a big thing.
Luke-JR also says that governments got their authority from god.

Could you try to stay at the facts?
We supported BIP91 like 100% of all miners at that time.
At the moment of writing that Blog post ( What wasn't written by me as you could see ) Segwit2x had 90%+ Miner support.
Why should we support something with 10% or less support what would've probably die if Segwit2x had stay at 90%+?

Segwit2x didn't happen now I support Bitcoin Cash personal more and will offer also features on btcpop for Bitcoin Cash.

How much money did you lost so far because not scaling?
Guess you don't run a business?
With the fork mess there was far less action on many sites as users kept of course their coins to get fork coins.
Transactions fees are one of or highest expenses since months.
Some Transactions could cost already $1000+ ( Lot inputs ), and thats what you get as business, lot small inputs what need to be forwarded to fewer outputs.

I'm in Bitcoin since 2011, I promoted Bitcoin, build business around it and I'm risking a lot of MY money.
And I see how expenses grows for us and income decreases the same time as users are not willing to pay high fees for deposits and withdrawals and p2p loans includes lot deposits and withdrawals.
Investors deposit small amounts or bigger amounts and invest in loans, the borrowers withdrawal the coins and deposit them back to repay what causes also lot smaller withdrawals again.

But as said in my previous post... Most are still just ignoring the reality and then blame those who aren't and who switch more to other solutions.
Not being able to find the reason they switch to other solutions.
10  Bitcoin / Development & Technical Discussion / Re: Why do people hate segwit so much? on: December 06, 2017, 10:41:41 AM
Basically it requires work to implement which is not as profitable as floating a shitcoin on your exchange and getting profits off that.
Some companies like blockonomics have already announced segwit support

We have about 120 coins on our exchange, our main business is p2p loans and we let users decide what coins they use or not, also my personal preferences doesn't matter much at all ( Would not support segwit personal ).

Offering all features for other coins doesn't mean we stop offering them for Bitcoin, users will just have more choices.
Lets call it market.

And why do you tell me that whatever company announced support?
We supported it as one of the first but can't fully support it as our transactions are done with bitcoind and the change goes straight to non segwit addresses.
If the change address type was a config option we would've full support as the first company few hours after activation of segwit.
We was also the first site who had Bitcoin Cash deposits and Withdrawals enabled and the second who had Bitcoin Gold enabled ( Initial sync on that coin was very slow probably intention so the devs had some advantages over others ).

What I was just initial saying here is that if core had full support in bitcoind then the adoption would already be bigger but users blame only companies here for not supporting it.

And saying that they need time is a lame excuse, for merging Bech32 support what isn't supported by most wallets there was enough time.
And Bech32 causes a lot more confusion in the short. ( I'm neutral on Bech32 personal ).

Go back in history how Segwit was called ready all the time and only the "evil" miners blocked it.
In fact nothing was ready and then the excuse comes that they can't develop when they don't know if it will ever be activated.
Thats another lame excuse as they clearly said its ready.
All the features could've been coded in already and a little check if segwit is active on the network would've been enough.
Segwit supporters also said more than once that Segwit will solve the scaling issues instant, after it was activated they switched to "give it some time".
It really doesn't matter if someone like segwit or not, after it was activated most would just use it to avoid high fees if it was possible at least.


Quote
I disagree with you, SegWit fixes transaction malleability and allows use of payment channels for example.
Mallaeability is not a big issue and there was better prospals to fix them on all transactions not only on segwit ( Flextrans as example ).
But those would need a HF.
I don't like the payment channels either as it causes or could cause a lot new problems and doesn't fix on chain problems at all.

In the end it doesn't matter at all, not scaling on chain caused the forks and will cause a lot more forks and those causes lot more work and problems.
On chain scaling wouldn't be a problem a HF would've been easier to deal with than all the mess now and all the things Segwit does would've been possible without if a HF was done.
Now Bitcoin will be forced to HF also in the future as it can't compete with the Bitcoin Cash DAA in the long, the first time bigger effect you'll see in a few hours for the next diff epoch.
Blocks will probably be slower for longer time and the backlog of tranactions bigger for longer time and fees higher for longer time and it could happen that the problems only increases with each cycle.
1. Cycle faster blocks as now but still mempool not a single time empty during this epoch.
2. Cycle slower blocks with even higher backlog in the mempool and higher fees for longer time.

It could happen that the cycle with faster blocks becomes even shorter and the cycles with slower blocks longer.
Must not happen and the price difference + backlog with high fees will cause also hashpower switching but in the long it will happen.

Some users fears huge blocks but ignore the fact that scaling on chain doesn't mean there can't be devloped sidechain solutions as well and if those are better they will lead to smaller blocks on chain no matter what the max blocksize is.

Bigger blocks now isn't a problem at all and we don't know if the current sidechain solutions are the best or if there will be better solutions in the future, its trying to solve non existing problems and thinking we're smarter now than people in the future.

Reality is just proving that there was so much going wrong and still going wrong but most are still ignoring reality.

The 2 ( biggest ) mistakes Satoshi Nakamoto made:
1. No dynamic blocksize based on demand like the daa ( Max blocksize = average Blocksize over last N blocks + xx% with a limited max increasing and decreasing to avoid manipulation).
2. Making Gavin Andersen lead dev without asking him.

Without those 2 mistakes we won't debating a scaling issue at all and still smart and good devs would develop more solutions what gives value to the network.


11  Bitcoin / Development & Technical Discussion / Re: Why do people hate segwit so much? on: December 06, 2017, 08:04:02 AM
Thats ofc nonsense, banning the Segwit2x nodes was pointless, if the for had happened the 1x nodes wouldn't have follow those anyway as the bigger blocks would've been rejected.
And the segwit stuff could've been done long before already on testnet and been coded in to be active when segwit activated.
It was also core who said segwit is ready since years and most of the community is ready for segwit and that segwit would solve scaling issues instant.
It was also BIP91 what was accepted by 100% what activated segwit and what included also 2MB Blocks later, without BIP91 their wouldn't be segwit at all.
UASF would have failed, without UASF there wouldn't be Bitcoin Cash and also no Bitcoin Gold,diamond,and 1000 other forks what will follow.
If core had follow the HK agreement there wouldn't be any of those forks either and Segwit had been active since much longer time.

I didn't wait for segwit i never liked the segwit idea but ofc when it was activated I would support it to offer users lower fees but that doesn't work because it isn't ready in fact.
And now the same people blame businesses for not adopting it.
It was also claimed as easier to do than a HF but in fact it isn't, updating the node software would've been easier than changing a lot of transactional code.
Bech32 was merged in pretty quick without need but a option to set the change address not, that option is missing since p2sh addresses and not just since segwit.
Bech32 is nothing important at all and its not even compatible with old nodes and also confusing for users.
If users request a withdrawal on sites to Bech32 addresses they would fail if the service didn't update.
12  Bitcoin / Development & Technical Discussion / Re: Why do people hate segwit so much? on: December 06, 2017, 02:15:42 AM
We had Segwit deposit addresses, Segwit hot wallet refill and segwit cold wallets on the day of activation on btcpop.co
Just to realize that the change goes straight to a p2pkh address when processing withdrawals.
Its easy to blame services but maybe blame Core for still not having a fully supporting wallet?
Most services use the json rpc of bitcoind, to support segwit now we would need to move to raw transactions and change all transactional code.
Where is the point in making so much propaganda for segwit and that most are ready for it but then not even supporting it in the core wallet?
Its now nearly 4 months since activation of segwit.

For sure i'm not going to invest money to create own work arounds or own patches to core code.
We're investing to offer all features in other currencies soon so users can use the features with low fees.
Even the segwit fees are now in avg higher than the non segwit before activation.
There is really no point to invest much time and money to support something what doesn't solve anything at all.
13  Bitcoin / Armory / Re: Little guide to Build Armory from Source on clean system on: November 26, 2017, 08:43:13 PM
libqt4-dev required as well

Code:
sudo apt-get install libqt4-dev

With the steps I build many times ( Except the typos ).
14  Bitcoin / Armory / Re: 0.96.4 RC1 on: November 24, 2017, 05:28:50 PM
I've setup on a clean new machine and now it works.
The signer still need to be fixed on my side as the signed TX is not recognized but i'm able to just broadcast the raw tx.

Do you have an error log for that last part?

Guess this one:
Code:
(WARNING) Transaction.py:1263 - Unexpected nested type for TxIn 16
(ERROR) Transaction.py:1289 - Insert list has index too big
(ERROR) Transaction.py:1289 - Insert list has index too big

But could be just because the signer is on an older version and the online node is on the current testing.
15  Bitcoin / Armory / Re: Is there a good "recipie" for spending from a P2SH-P2PK address in bitcoin-qt? on: November 24, 2017, 05:13:31 PM
And now another scamcoin comes... Bitcoin Diamond...

Easy solution for those who want to claim those scam coins:

Setup Online/Offline wallet with electrum, move your coins to a new electrum wallet before the fork block.
After the fork block move your coins back to armory.
Once the scamcoin releases a wallet you can import the empty btc privkeys into it and dump the scamcoin.

Or just move them to a tmp armory wallet into a p2pkh address and export the base58 key after you moved the BTC back to your normal wallet after the fork block.

I guess there will be several 100 or 1000 forks in the future, no way to support them all in armory without getting a dedicated dev team just dealing with forks/airdrops/splits.
16  Bitcoin / Armory / Re: 0.96.4 RC1 on: November 24, 2017, 04:58:35 PM
I've setup on a clean new machine and now it works.
The signer still need to be fixed on my side as the signed TX is not recognized but i'm able to just broadcast the raw tx.
17  Bitcoin / Armory / Re: Is there a good "recipie" for spending from a P2SH-P2PK address in bitcoin-qt? on: November 23, 2017, 12:04:43 PM
It is but I've had other stuff thrown on my lap these past couple days which need my immediate attention. So, no guarantees.

I also have some BTG in my wallet, but I can fully understand if goatpig does not want to touch that "project" with a ten foot pole.

Bitcoin Gold is heavily premined, and would have been ignored if they had not generated interest by airdropping the coin to all BTC holders.  They have a history of linking to key-stealing wallets from their web page, wallets that steal both the BTG and the BTC when an unsuspecting user tries to split the coins (both a "web wallet" which asked you to type in the seed, and then promptly took all funds; and 'Electron Gold' which is a fork of Electrum claiming to be from the same developer as Electron Cash, but said developer is very busy warning against it on Reddit, and has posted documentation claiming that it transmits the private keys).

It stinks of scam.  I guess the only reason the price is still high is that the developers try to pump it - which of course is an argument for dumping as much BTG as possible :-)



Dumped already everything i had in p2pkh addresses, I give nothing about the coins in p2sh type addresses, if there will be ever a signer then ok, i would dump them as well, if not then also ok for me.
Probably more value in not wasting much time on this BS and working on other things.
18  Bitcoin / Armory / Re: 0.96.4 RC1 on: November 23, 2017, 12:25:10 AM
Put the call in a try block and print the error message. Something like this:

Code:
         try:
            cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
         except DbErrorMsg as e:
            print e.what()
            raise e

Btw this traceback is for code from master (0.96.3). Have you reproduced the same issue with the testing branch?

I'll build the testing tomorrow again. ( ATM its rebuilding the DB again ).
19  Bitcoin / Armory / Re: 0.96.4 RC1 on: November 22, 2017, 09:49:23 PM
It's suggesting your DB is corrupt.

Rebuild more than once in the last days...
20  Bitcoin / Armory / Re: 0.96.4 RC1 on: November 22, 2017, 02:16:57 PM
The logs with the error backtraces should be there regardless of what version you are running now though. That's what I'm asking for.


Code:
2017-11-22 15:15:39 (INFO) -- TxFrames.py:727 - Change address behavior: NewAddr
2017-11-22 15:15:39 (ERROR) -- Traceback (most recent call last):
  File "/usr/local/lib/armory/ui/TxFrames.py", line 848, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/usr/local/lib/armory/ui/TxFrames.py", line 802, in validateInputsGetUSTX
    lockTime=TheBDM.getTopBlockHeight())
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2287, in createFromTxOutSelection
    return self.createFromPyTx(thePyTx, pubKeyMap, txMap, p2shMap)
  File "/usr/local/lib/armory/armoryengine/Transaction.py", line 2196, in createFromPyTx
    cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
  File "/usr/local/lib/armory/CppBlockUtils.py", line 2758, in getTxByHash
    return _CppBlockUtils.BlockDataViewer_getTxByHash(self, txHash)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7fc0d9941a80> >

Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!