Bitcoin Forum
May 04, 2016, 01:56:30 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 242 »
401  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 06, 2014, 01:23:22 PM
The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol.
Uh, what "ease" of 51% attacks? Or high resource costs?
And only few use cases? O.o
Maybe I misunderstood, but I thought that this thing needed to have it's own hash-power in order to avoid attacks from the main blockchain. Therefore, unless the sidechain has enormous hashpower it would be trivial for a party to break away from the primary chain to do a 51% attack.
Merged mining solved this a long time ago.

I say it's few use cases because I'm not convinced that there are alot of uses that would be preferred to be in a sidechain, rather than a totally separate solution. Though I'm not financier or whatever, so I'm probably just ignorant of all the potential.
I can't think of any uses that would prefer a totally separate solution (other than scams).
402  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 05, 2014, 10:06:52 PM
The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol.
Uh, what "ease" of 51% attacks? Or high resource costs?
And only few use cases? O.o
403  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 05, 2014, 08:48:23 PM
If SIDECHAIN1 binds to some output on the Bitcoin chain, how can you guarantee that I can't run an otherwise duplicate SIDECHAIN2 that grants all bitcoins to myself and then I just turn around and take the coins on the output of Bitcoin?

"4.2 Fraudulent transfers" is apparently talking about this issue, but I still wonder what prevents a total reorganization from the genesis of the sidechain by whoever made it and having the flexibility of deciding to do this anytime in the the future?

It seems like no matter what you have to trust whoever created the side-chain for as long as the side-chain exists.
You have to trust the miners on the sidechain not to 51% attack it with a "SIDECHAIN2", yes. Just like Bitcoin*.

* Not exactly "just like" if you're using SPV proofs.
404  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 05, 2014, 07:24:26 PM
Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:
Quote
Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?
Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release.
The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way.

Thanks but my (very basic) question is about the fungibility of the sidecoins.
I rephrase the question.
Is the release of a locked bitcoin (or any fraction thereof)  tied to a specific sidechain transaction OR is there flexibility in the choice of the unspent outputs on the sidechain to release the locked bitcoin?

Pratical use case: suppose I have locked one bitcoin in tx A to release one sidecoin in tx A' on the sidechain.
Later, I lock another bitcoin in tx B to release another sidecoin in tx B'.
Can I redeem the second sidecoin to release the first bitcoin ?
If tx A and tx B are transferring from the same parent blockchain, they should be the same asset on the sidechain.
Obviously you can redeem any "sidecoin" of the same asset type using any of the locked coins, since as soon as you do a transaction on the sidechain the original transferred-in coin is consumed.
405  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 05, 2014, 05:47:58 PM
Boussac and I are trying to better figure out the details of the peg mechanism and their consequences at a higher level (economic).
Basically, the question is the one asked by Boussac:
Quote
Let's say I have locked one bitcoin to release one sidecoin. To release the locked bitcoin, does my sidechain-enabled wallet simply collect one sidecoin (plus tx fee) worth of sidechain unspent outputs or  are there other constraints on my sidechain transaction transferring the coin back to the bitcoin blockchain ?
Once a bitcoin is locked to a sidechain, it is entirely up to the sidechain rules what the terms are for the release.
The obvious case is 1:1 equivalence, but there's nothing saying a sidechain must do it that way.

On my side, I would add this question:
Quote
Am I right if I say that parent chains don't choose their sidechains but sidechains (devs, community) choose their parents ?
Yes, that's correct. The parent chain could try to prevent sidechains below it, but even then as long as there is multisig you can always do a federated peg sidechain.
406  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 05, 2014, 03:31:00 PM

Well, seems better to wait for answers from the experts.
Still waiting. The way this fungibility issue is ignored in this otherwise awesome white paper is puzzling with so many bright minds as co-signers.

I assume for simplicity a 1:1 peg between bitcoin and sidecoin.
Perfect fungibility would mean I can redeem any set of unspent outputs totalling one sidecoin on the sidechain to release any locked bitcoin on the blockchain.

To illustrate this notion, suppose there is perfect fungibility and the sidechain is used as a mixer for the blockchain.
I assume for simplicity a 1:1 peg between bitcoin and sidecoin.

"Dirty" BTCs are transferred to the sidechain and come back clean as sidecoins but with a 10% laundering fee: in the off-chain market  I can only get one sidecoin for 1.1 BTC because I would need 1.1 BTC to get a clean sidecoin in a sidechain transaction.
The point is  that, with fungibility, the spread between the pegged rate and the market rate can be significant.

I could have taken any example where the function of the sidechain requires fungibility and commands a transaction fee.
Transaction fees on a sidechain are not necessarily market driven because of market imperfections.
Therefore fungibility is an important design parameter for sidechains.
Can you come up with an example that is plausable? Having a hard time following enough to figure out what the actual question is...
407  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 04, 2014, 09:03:01 PM
SC1 decides to "cut the link" with this chain.
What? SC1 is a blockchain, not an entity.
408  Bitcoin / Pools / Re: [13000 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: November 04, 2014, 06:10:42 PM
There are a few issues with this system though, specifically as it comes to "stale" work.  If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale).  While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block.
No different than if they were solo mining and claimed the full 25 BTC...
As long as you don't credit stale shares (from the pool's perspective), nobody is hurt. Smiley
409  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 04, 2014, 01:28:56 PM
Is it possible to get this kind of architecture ?


Yes, but BTC-via-SC1 and BTC-via-SC2 would be different assets on SC3.
Although you can treat them identical if you want to (ie, if you trust SC1 and SC2 equally).
410  Bitcoin / Hardware / Re: Windows miners beware: FTDI driver update may brick hardware! on: November 04, 2014, 11:34:52 AM
Thanks, I'll lock this one.
411  Bitcoin / Hardware / Windows miners beware: FTDI driver update may brick hardware! on: November 04, 2014, 10:09:03 AM
Ars Technica has an article about Windows Update pulling in a driver update for the popular FTDI chipset bricking knock-off chips.
I don't know if any mining hardware is using these knock-off chips, but I would suggest being careful about connecting anything to a Windows system for now.
Note that if you have the WinUSB driver installed (BFx2 and cgminer users), you shouldn't be affected - but if it were me, I wouldn't risk it.

If you know devices affected, please post here to let others know.
412  Bitcoin / Pools / Re: [13000 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: November 04, 2014, 07:17:52 AM
Would this negate the shift scheme we currently use? I only ask since from time to time it takes less than a minute for the network to solve a block and in the past we/pool had luck getting some of those consecutive blocks, a momentary users restart could leave someone out in the cold after running 30+ days nonstop and Windoze wants an update/restart and the pool was unlucky the prior 8 consecutive hours.
I don't see why you would expect it to change the reward scheme at all.
413  Bitcoin / Pools / Re: [13000 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: November 04, 2014, 06:44:16 AM
I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

+1. I much prefer direct payouts, and it eliminates a lot of your risk.
Does this mean that instead of an hourly disbursement of funds to/for accounts meeting the user's settings minimum threshold from their accumulated balance, that we would have a payment after each/every matured block award which accepted shares were submitted for? Or somehow still utilize a shift scheme to determine contributions?
One nice thing about PPLNS (and why p2pool uses it) is that it's very easy to make the block reward mined distributed among all the miners it's supposed to pay.
So you wouldn't need to wait until the block matures to get a payout - you'd "just have" the payout in your wallet the moment the block was mined, and it would never touch BTCGuild's wallet at all.
Disclaimer: I don't know what (if anything) Eleuthria has planned for implementing this, this is just how I would do it, if it were me.
414  Bitcoin / Pools / Re: [10000Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB on: November 04, 2014, 06:08:05 AM
Most common reject cause is because it is already in the memory pool.  If Discus Fish picked it up then it likely was relayed pretty normally and we already had it when you pushed.
Well http://eligius.st/~wizkid057/newstats/pushtxn.php was the first place where I pushed it but still transaction was rejected and not relayed, why so?
CPFP is only implemented for the mining policy, not the mempool.
This means your parent transaction need to pass the mempool's checks on its own before it will be considered for CPFP prioritisation.
415  Bitcoin / Hardware / Re: [Guide] Dogie's Comprehensive Avalon Avalon2 Setup [HD] on: November 03, 2014, 04:00:43 PM
To "factory reset" a pi, usually you just take the SD card out and reprogram it...
416  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 02, 2014, 03:36:09 PM
How can I fix that? pool does not see any work of course.

Code:

 [2014-11-02 11:42:21] HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl

Try updating libcurl (if you're using Linux).  Definitely try:

sudo apt-get install build-essential autoconf automake libtool pkg-config libcurl4-gnutls-dev libjansson-dev uthash-dev libncursesw5-dev libudev-dev libusb-1.0-0-dev   libevent-dev libmicrohttpd-dev hidapi

sudo apt-get update
sudo apt-get upgrade

You may also have to rerun ./configure and make again...
His libcurl is fine. No version of libcurl supports stratum+tcp, so this is an ordinary message before it uses its own implementation.

Also, I don't see any actual problems in his log...
417  Alternate cryptocurrencies / Altcoin Discussion / Re: TeaCoin - BlockChain Problem?? Block Reward Reset on: November 02, 2014, 01:57:48 AM
https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki
418  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: October 31, 2014, 01:48:31 PM
Hah, people snooping around find things before I announce them Wink
Yes, that's the point of it. It isn't done yet, though!
Any suggestions for the TUI and RPC changes to go with it?
Kinda weird to see 2 Mh/s average for "4 Mh/s when it's doing SHA2 and 100 kh/s when it's doing scrypt" XD


Srry! Didn't mean to snoop around or cause you trouble! Just updated and found that magic word in my git console which made me curious. Quite rightly! Smiley

TUI is tough for multiple algos. Maybe stack them like that.

Code:

 bfgminer version 4.10.0 - Started: [2014-10-23 13:27:50] - [  8 days 00:49:38]
 [M]anage devices [P]ool management [S]ettings [D]isplay options                       [H]elp [Q]uit
----------------------------------------------------------------------------------------------------
 Pool 0: sha.pool.com       Diff:4  +Strtm  LU:[13:16:31]  User:sha_usr
 Block: ...3abed3e2 #327848  Diff:36G (257.6P)  Started: [12:55:51]
 ST:4  F:12  NB:1243  AS:0  BW:[ 54/ 43 B/s]  E:23.01  I: 2.75uBTC/hr  BS:362k
 2            |  4.90/ 4.95/ 4.72Gh/s | A:221409 R:1144+126(.56%) HW:33265/4.2%
----------------------------------------------------------------------------------------------------
 BPM 0:       |  2.49/ 2.49/ 2.37Gh/s | A:110784 R: 613+ 67(.60%) HW:16925/4.2%
 BPM 1:       |  2.47/ 2.46/ 2.35Gh/s | A:110626 R: 531+ 59(.52%) HW:16340/4.1%
----------------------------------------------------------------------------------------------------
 Pool 0: srcypt.pool.com     Diff:4  +Strtm  LU:[13:16:31]  User:scrypt_usr
 Block: ...3abed3e2 #327848  Diff:36G (257.6P)  Started: [12:55:51]
 ST:4  F:12  NB:1243  AS:0  BW:[ 54/ 43 B/s]  E:23.01  I: 2.75uBTC/hr  BS:362k
 2            |  950/ 932/ 940kh/s | A:221409 R:1144+126(.56%) HW:33265/4.2%
----------------------------------------------------------------------------------------------------
 GSD 0:       |  475/ 466/ 470kh/s | A:110784 R: 613+ 67(.60%) HW:16925/4.2%
 GSD 1:       |  475/ 466/ 470kh/s | A:110626 R: 531+ 59(.52%) HW:16340/4.1%
----------------------------------------------------------------------------------------------------
 [2014-10-31 13:13:29] Accepted 1376f0cf GSD 0  Diff 13/4
 [2014-10-31 13:13:34] Accepted 0966a537 BPM 1  Diff 27/4
 [2014-10-31 13:13:39] Accepted 09d103b4 BPM 0  Diff 26/4
 [2014-10-31 13:13:40] Accepted 130996e3 BPM 1  Diff 13/4
 [2014-10-31 13:13:43] Accepted 24b1ea24 GSD 1  Diff 6/4
 [2014-10-31 13:13:44] Accepted 14b90178 BPM 1  Diff 12/4


hhmmm... looks weird...  Grin
Heh, you're assuming devices that only do one or the other.
I've got CPU (and plan to have OpenCL) doing both at the same time Smiley
419  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: October 31, 2014, 11:36:57 AM
Hi there!

Just found that new "multialgo" branch on github, but couldn't find any docu on that.
Could you pls shed some light on what this is all about?

Would it be possible to mine multiple algos at the same time?
Like having bitcoin and scrypt hardware working simultaneously, each on its own algo/pool?

Thx!

BFG FTW!  Grin
Hah, people snooping around find things before I announce them Wink
Yes, that's the point of it. It isn't done yet, though!
Any suggestions for the TUI and RPC changes to go with it?
Kinda weird to see 2 Mh/s average for "4 Mh/s when it's doing SHA2 and 100 kh/s when it's doing scrypt" XD
420  Bitcoin / Development & Technical Discussion / Re: Signature Mining (to embed messages into the blockchain without using OP_RETURN) on: October 30, 2014, 12:09:36 PM
You might want to look at https://github.com/Blockstream/contracthashtool
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 242 »
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!