Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 192. (Read 685214 times)
March 19, 2014, 11:23:43 PM
diff down to 1504
March 19, 2014, 11:10:04 PM
Did you know you can trade RIC/BTC at agx.io and earn entries into our AMD Radeon R9 280x giveaway through Sunday 03/23 11:59p UTC? Did you also know that BTC deposits at agx.io >.02 BTC through Sunday 03/23 11:59p UTC will earn you deposit bonuses up to 50k NOBL? Check out our infographic for more information.
- The Austin Global Team
Find us at:
agx.io
bitcointalk.org/index.php?topic=507474
bitcointalk handles: "agx.io," "AustinGlobal"
twitter.com/AustinGlobalX
austinglobal.tumblr.com
- The Austin Global Team
Find us at:
agx.io
bitcointalk.org/index.php?topic=507474
bitcointalk handles: "agx.io," "AustinGlobal"
twitter.com/AustinGlobalX
austinglobal.tumblr.com
March 19, 2014, 10:51:13 PM
Check out this message which explains it nicely too: https://bitcointalksearch.org/topic/m.906833
So it looks like maybe the spend isn't there yet?
I think it is, this explains how to spend: https://gist.github.com/gavinandresen/3966071Quote
You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).
That will create a multi signature transaction.
If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.
That will create a multi signature transaction.
If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.
So it looks like maybe the spend isn't there yet?
That was written much later than the post you linked.
March 19, 2014, 10:28:10 PM
I wonder if there is a way for the multi sig to be configured to accept a majority of the sig and not everyone's (forgive me if there is. Never used a multi-sig address). I think that would be better in case one person holding a key has a family emergency, vanished, died, etc. Then, the foundation wouldn't be able to access the funds.
AFAIK this is possible: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_listSay we use 5 people.
use
Code:
riecoind addmultisigaddress 3 '["publicKey1","publicKey2","publicKey3","publicKey4","publickey5"]'
Can someone knowledgeable on this subject confirm?
btw, about 10 blocks left until diff adjustment.
Quote
Never used a multi-sig address
Me neither. It just popped out of the back of my head, and then I researched it.
Excellent! Looks like we have a winner. But all foundation members should agree (or majority) in case someone thinks of a better idea. I will be PMing those on the list on Monday. Looks like we are ahead of schedule. Thanks surfer for your contributions!
March 19, 2014, 10:15:46 PM
Check out this message which explains it nicely too: https://bitcointalksearch.org/topic/m.906833
So it looks like maybe the spend isn't there yet?
Quote
You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).
That will create a multi signature transaction.
If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.
That will create a multi signature transaction.
If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.
So it looks like maybe the spend isn't there yet?
March 19, 2014, 10:00:39 PM
I wonder if there is a way for the multi sig to be configured to accept a majority of the sig and not everyone's (forgive me if there is. Never used a multi-sig address). I think that would be better in case one person holding a key has a family emergency, vanished, died, etc. Then, the foundation wouldn't be able to access the funds.
AFAIK this is possible: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_listSay we use 5 people.
use
Code:
riecoind addmultisigaddress 3 '["publicKey1","publicKey2","publicKey3","publicKey4","publickey5"]'
Can someone knowledgeable on this subject confirm?
btw, about 10 blocks left until diff adjustment.
Quote
Never used a multi-sig address
Me neither. It just popped out of the back of my head, and then I researched it.
March 19, 2014, 09:52:41 PM
I wonder if there is a way for the multi sig to be configured to accept a majority of the sig and not everyone's (forgive me if there is. Never used a multi-sig address). I think that would be better in case one person holding a key has a family emergency, vanished, died, etc. Then, the foundation wouldn't be able to access the funds.
March 19, 2014, 09:45:49 PM
I think it's hard for people not to pump and dump in general. They invest energy + resources and expect a return so the moment they can they dump. The people involved in developing a thriving community continue to hold (myself included). Looking forward to your PM (I have a diff u/n on rietalk)
March 19, 2014, 09:28:46 PM
Can't we use a multi-signature address rather than an exchange? Although complicated, it seems like it would be much simpler than the exchange. Also, people would be able to verify the funds are at that address.
I didn't think of that! Great idea! I am assuming Riecoin client has that option correct?
. To learn how to use multi-signature addresses, go hereAlso, difficulty is going to halve to about 1456 in 20 something blocks (if my math is correct, that is). Get ready to mine!
Well ok. Guess we have a nice way to do the donations. I will be PMing all those on the list and hopefully we can come to mutual agreement on this. And darn. Hopefully low difficulty doesn't make it easier for people to pump and dump.
March 19, 2014, 09:20:50 PM
How many confirmations does upCpu pool needs to send mined RIC?
March 19, 2014, 09:15:25 PM
Can't we use a multi-signature address rather than an exchange? Although complicated, it seems like it would be much simpler than the exchange. Also, people would be able to verify the funds are at that address.
I didn't think of that! Great idea! I am assuming Riecoin client has that option correct?
. To learn how to use multi-signature addresses, go hereAlso, difficulty is going to halve to about 1456 in 20 something blocks (if my math is correct, that is). Get ready to mine!
March 19, 2014, 09:01:44 PM
Can't we use a multi-signature address rather than an exchange? Although complicated, it seems like it would be much simpler than the exchange. Also, people would be able to verify the funds are at that address.
I didn't think of that! Great idea! I am assuming Riecoin client has that option correct?
March 19, 2014, 08:23:04 PM
Can't we use a multi-signature address rather than an exchange? Although complicated, it seems like it would be much simpler than the exchange. Also, people would be able to verify the funds are at that address.
March 19, 2014, 07:24:39 PM
Update: Since I've been getting more response than expected for Riecoin Foundation, sign up will close this Sunday and the Riecoin Foundation will begin creating the trustless system for donations. Any suggestions is welcome!
March 19, 2014, 07:23:37 PM
difficulty to drop in 10 hours (at current rate of 6 mins/block)
Thatll suck
March 19, 2014, 06:16:34 PM
March 19, 2014, 04:08:07 PM
difficulty to drop in 10 hours (at current rate of 6 mins/block)
March 19, 2014, 03:26:17 PM
For the RIC geeks: I'm starting to put together a simple example of RIC mining in Python.
https://github.com/dave-andersen/fastrie/tree/master/explain/examples
Contributions and suggestions welcomed. Right now it's just four very basic programs:
- sieve of e
- fermat test (too lazy to implement r/m)
- a RIC PoW finder that just uses the sieve to find valid PoWs counting from 1;
- a RIC PoW finder that fermats every odd number to find valid PoWs counting from 1;
Coming up will be a version that doesn't have to start at 1, and then faster versions that use inverse-mod-n and a large primorial. Hopefully, we can keep these all readable. My target for this is the average Redditor or Hacker News reader who can read Python and might find this all interesting / educational.
https://github.com/dave-andersen/fastrie/tree/master/explain/examples
Contributions and suggestions welcomed. Right now it's just four very basic programs:
- sieve of e
- fermat test (too lazy to implement r/m)
- a RIC PoW finder that just uses the sieve to find valid PoWs counting from 1;
- a RIC PoW finder that fermats every odd number to find valid PoWs counting from 1;
Coming up will be a version that doesn't have to start at 1, and then faster versions that use inverse-mod-n and a large primorial. Hopefully, we can keep these all readable. My target for this is the average Redditor or Hacker News reader who can read Python and might find this all interesting / educational.
Good initiative! Thanks a lot!
March 19, 2014, 02:22:31 PM
What is the port for ric.upcpu.com?
March 19, 2014, 01:28:06 PM
For the RIC geeks: I'm starting to put together a simple example of RIC mining in Python.
https://github.com/dave-andersen/fastrie/tree/master/explain/examples
Contributions and suggestions welcomed. Right now it's just four very basic programs:
- sieve of e
- fermat test (too lazy to implement r/m)
- a RIC PoW finder that just uses the sieve to find valid PoWs counting from 1;
- a RIC PoW finder that fermats every odd number to find valid PoWs counting from 1;
- One based upon the iterative polynomial sieving I mentioned earlier, combined with fermat tests (but no real sieving).
Coming up will be a version that doesn't have to start at 1, and then faster versions that use inverse-mod-n and a large primorial. Hopefully, we can keep these all readable. My target for this is the average Redditor or Hacker News reader who can read Python and might find this all interesting / educational.
What's nice is that it already shows the punchline of why jh's was faster. If you examine the runtimes for outputting all valid RIC PoWs for the numbers up to 10,000,000 -- not that RIC ever started that easy:
brute_force_ric: 7.4s <-- fermat test every odd number
basic_ric: 3.2s <-- basic sieve of e, use to test for primes
ric_gen: 0.039s <-- iteratively generate candidate locations using an increasing-sized primorial
https://github.com/dave-andersen/fastrie/tree/master/explain/examples
Contributions and suggestions welcomed. Right now it's just four very basic programs:
- sieve of e
- fermat test (too lazy to implement r/m)
- a RIC PoW finder that just uses the sieve to find valid PoWs counting from 1;
- a RIC PoW finder that fermats every odd number to find valid PoWs counting from 1;
- One based upon the iterative polynomial sieving I mentioned earlier, combined with fermat tests (but no real sieving).
Coming up will be a version that doesn't have to start at 1, and then faster versions that use inverse-mod-n and a large primorial. Hopefully, we can keep these all readable. My target for this is the average Redditor or Hacker News reader who can read Python and might find this all interesting / educational.
What's nice is that it already shows the punchline of why jh's was faster. If you examine the runtimes for outputting all valid RIC PoWs for the numbers up to 10,000,000 -- not that RIC ever started that easy:
brute_force_ric: 7.4s <-- fermat test every odd number
basic_ric: 3.2s <-- basic sieve of e, use to test for primes
ric_gen: 0.039s <-- iteratively generate candidate locations using an increasing-sized primorial
Jump to: