Ive got this error:
"Error": "Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here."
tithes were not accepted but my balance was deducted.
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 219. (Read 243437 times)
February 15, 2019, 08:41:50 AM
February 15, 2019, 08:34:27 AM
right now i had one successfull tithe and several rejected
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
capulo I have the same problem, all my tithes rejected and balance is deducted by whole coin amount.
Edit: restart helped to return coins
February 15, 2019, 08:31:16 AM
right now i had one successfull tithe and several rejected
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
Yes your input amount is affected
Try restart wallet First
February 15, 2019, 08:21:01 AM
right now i had one successfull tithe and several rejected
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
but... i see that my balance goes down with every rejected - with amount of whole pile, not only tithe
is this how it should work? and how long i need to wait until coins came back? (rejected tx)
February 15, 2019, 07:56:37 AM
1.1.8.8 - Leisure Upgrade
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
How can I install the last mandatory update in Linux?
Code:
Reading state information... Done
biblepayd is already the newest version (1.1.8.5b-xenial1).
0 upgraded, 0 newly installed, 0 to remove and 170 not upgraded.
PPA repositories have been updated few hours ago. Could you try again now?
February 15, 2019, 03:44:42 AM
Hello,
Can you please explain bankroll for the non technical user.
I have old coins in my wallet, why i need bankroll, why it is not done automatically ?
How can I explain this to my granny who want to use BBP? she doesn't knows anything about computers, she just want to buy some BBP and leave the wallet open few times a day and receive some rewards for POG.
Can you please explain bankroll for the non technical user.
I have old coins in my wallet, why i need bankroll, why it is not done automatically ?
How can I explain this to my granny who want to use BBP? she doesn't knows anything about computers, she just want to buy some BBP and leave the wallet open few times a day and receive some rewards for POG.
February 15, 2019, 03:29:26 AM
1.1.8.8 - Leisure Upgrade
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
How can I install the last mandatory update in Linux?
Code:
Reading state information... Done
biblepayd is already the newest version (1.1.8.5b-xenial1).
0 upgraded, 0 newly installed, 0 to remove and 170 not upgraded.
February 14, 2019, 05:43:08 PM
1.1.8.8 - Leisure Upgrade
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
- Prevent 'exec bankroll' from spending bankroll denominations
- Prevent PODCUpdate from spending POG bankroll denominations
February 14, 2019, 05:41:47 PM
And also just to clarify, the PODC update code might have been accidentally picking some of the bankroll outputs; so let's see if this problem is resolved in the next version.
I can say for sure the next version will not spend bankroll transaction outputs for 'exec bankroll' or podcupdates (as I did some testing last night with the new version).
I can say for sure the next version will not spend bankroll transaction outputs for 'exec bankroll' or podcupdates (as I did some testing last night with the new version).
I believe PrivateSend also makes .001 denomination and I remember podcupdate and PrivateSend could not be used in the same wallet. If you mixed coins, your podcupdate could combined all those mixed denominations together. I suppose if your fix works as intended, the side benefit is that PrivateSend is also excluded from podcupdate?
We would have to specifically test that PS issue and probably do another patch for that case.
February 14, 2019, 03:59:55 PM
No, what was happening, was that I had bankrolled a whole bunch of coins but left just enough for PODC. However, PODC kept saying insufficient balance. I looked at the Coin Input and saw that my bankrolled coins were nicely separated from the amount I wanted to save for PODC, so I couldn't figure out what was wrong. I ended up selecting all the coins in my NON-Tithe addresses and sending them to a single address, then I noticed that shortly after, a single automatic PODC update would go out. But after that, it would stop completely. Each day, I would have to manually consolidate all my NON-TITHE addresses into one wallet for PODC to update. Eventually, I thought there might be a problem with the bankrolled coins, so I selected those as well and consolidated everything into one single wallet address. PODC automatic updates now work fine, however, now it always takes the whole balance regardless of what I specify in UTXOOverride. POG no longer works because my entire coin age is always reset.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
Sounds like the issue I posted here:
https://github.com/biblepay/biblepay/issues/70
I suggest you separate PoG from PoDC.
The issue will resolve itself over time. There's a vote to potentially remove PoDC from BiblePay. If the proposal passes, there's no point in using dev hours to make PoDC and PoG interoperate in the same wallet.
Anyway, if you want to split PoDC and PoG, you can send PoDC stake a second wallet. This worked for me in Windows 10:
https://discontinuo.us/biblepay-unofficial-wiki/how-to-run-multiple-biblepay-wallets
If anything is unclear, feel free to edit the wiki. Anyone can edit it anonymous and even upload images.
And also just to clarify, the PODC update code might have been accidentally picking some of the bankroll outputs; so let's see if this problem is resolved in the next version.
I can say for sure the next version will not spend bankroll transaction outputs for 'exec bankroll' or podcupdates (as I did some testing last night with the new version).
February 14, 2019, 03:07:45 PM
No, what was happening, was that I had bankrolled a whole bunch of coins but left just enough for PODC. However, PODC kept saying insufficient balance. I looked at the Coin Input and saw that my bankrolled coins were nicely separated from the amount I wanted to save for PODC, so I couldn't figure out what was wrong. I ended up selecting all the coins in my NON-Tithe addresses and sending them to a single address, then I noticed that shortly after, a single automatic PODC update would go out. But after that, it would stop completely. Each day, I would have to manually consolidate all my NON-TITHE addresses into one wallet for PODC to update. Eventually, I thought there might be a problem with the bankrolled coins, so I selected those as well and consolidated everything into one single wallet address. PODC automatic updates now work fine, however, now it always takes the whole balance regardless of what I specify in UTXOOverride. POG no longer works because my entire coin age is always reset.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
I managed to get it working by setting utxooverride a bit above needed and sending that amount to new address. Now it sends this amount and uses fees from some dust I have left too.
February 14, 2019, 02:56:39 PM
No, what was happening, was that I had bankrolled a whole bunch of coins but left just enough for PODC. However, PODC kept saying insufficient balance. I looked at the Coin Input and saw that my bankrolled coins were nicely separated from the amount I wanted to save for PODC, so I couldn't figure out what was wrong. I ended up selecting all the coins in my NON-Tithe addresses and sending them to a single address, then I noticed that shortly after, a single automatic PODC update would go out. But after that, it would stop completely. Each day, I would have to manually consolidate all my NON-TITHE addresses into one wallet for PODC to update. Eventually, I thought there might be a problem with the bankrolled coins, so I selected those as well and consolidated everything into one single wallet address. PODC automatic updates now work fine, however, now it always takes the whole balance regardless of what I specify in UTXOOverride. POG no longer works because my entire coin age is always reset.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
Perhaps why my PODC updates were failing is because somehow my wallet was not reading the utxooverride value correctly in some cases and was trying to send out a larger amount than what I had specified.
I just tried bankrolling a bunch of coins again and will see in a little while if I continue to have problems.
February 14, 2019, 02:45:05 PM
Been having trouble with the utxooverride command now in 1.1.8.7. Always seems to spend my full wallet balance despite what I put in. Any one else have this problem?
Is it spending your bankroll denoms? Fix is compiling right now... February 14, 2019, 02:44:33 PM
This is where we have to agree to disagree:
* The 40 block lookback is necessary, just as a 28 is in DGW, its an IT thing, and I weighed the efficiency vs the volatility; Youll see in prod in a couple days that vol is low with it. This decision is a good one
* There is no flaw in POG - there was only a configuration issue (all the params were wrong in the first release). This is an incorrect assessment.
* On dev time: Already wearing at least 3 hats; I don't feel this assessment deserves a proper reply - because your not fairly taking into consideration what Ive done for this coin.
* Longer lookback is not a necessary change nor an enhancement
* POG is ELI5 once the user manual for 5 year olds is created. I can say this because I know that the first gas lawnmower had more exposed controls than the 2000 version. Thats where we are. Im telling everyone that POG is going to be simpler than POW mining. Its POW with one gas pedal.
So lets be man enough to agree to disagree on these points.
For clarity, I agree a look back is necessary. Just that 40 is too small and should be increased to 205 or 410.
On your Dev time, I know you spend a ton of time on the coin. I am merely saying, how you choose to spend your dev time is picking a winner in this. I'm not asking you to spend MORE time coding, merely that the reason your time is so limited for coding right now is you're spending it to improve PoG.
And let's be clear, my opinion is a longer look back is necessary, and your opinion is it is not. We are both stating opinions. As you are the Dev and I'm merely a long time user, your opinion has a lot of weight.
But I will say, PoG as it stands now, without further enhancements, refinements or configurations...whatever you wish to call them, will not be as readily accessible to the general public as it is now. But you are in essence, saying it's ready to go. So I get back to why not vote to eliminate PoDC sooner rather than later if that is the path you're set on BBP going on? Let's make PoG the law of the land, end the debate and let the chips fall where they may.
- On the dev time, my recommendation for you is to do everything within your power to first provide 3-4 new active devs for biblepay, either by lobbying, recruiting or directly paying for them. Then you and I can sit back and prioritize their time. Til then you should be looking to me as the founder, not as the one who has to be stuck doing all the work for the coin, thats not how this works, the idea is to get the coin jumpstarted then the founders help run it.
- Thanks but I still think POG is perfectly fine. We're not perfectly fine right now as a community, because we need 900 new users first, I think thats where we lack.
February 14, 2019, 02:42:24 PM
Been having trouble with the utxooverride command now in 1.1.8.7. Always seems to spend my full wallet balance despite what I put in. Any one else have this problem?
February 14, 2019, 01:49:09 PM
Kudos for paying for the new user reward.
My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners. Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.
I do have concerns that you aren't willing to spend time on PoDC upfront if it's going to be retired, when that is exactly what you're doing now with PoG. By your labor, you are pushing a winner. It's your right to do so, but to use the lack of revisions to PoDC while PoG is being tweaked and refined is not a good argument against PoDC. I think you have the best intentions and your skills can get around many issues. But PoG is not ELI5 simple to understand even if it is trivial to set up.
A longer look back would mitigate one of the bigger issues with PoG. I beseech you to rethink your position there.
My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners. Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.
I do have concerns that you aren't willing to spend time on PoDC upfront if it's going to be retired, when that is exactly what you're doing now with PoG. By your labor, you are pushing a winner. It's your right to do so, but to use the lack of revisions to PoDC while PoG is being tweaked and refined is not a good argument against PoDC. I think you have the best intentions and your skills can get around many issues. But PoG is not ELI5 simple to understand even if it is trivial to set up.
A longer look back would mitigate one of the bigger issues with PoG. I beseech you to rethink your position there.
This is where we have to agree to disagree:
* The 40 block lookback is necessary, just as a 28 is in DGW, its an IT thing, and I weighed the efficiency vs the volatility; Youll see in prod in a couple days that vol is low with it. This decision is a good one
* There is no flaw in POG - there was only a configuration issue (all the params were wrong in the first release). This is an incorrect assessment.
* On dev time: Already wearing at least 3 hats; I don't feel this assessment deserves a proper reply - because your not fairly taking into consideration what Ive done for this coin.
* Longer lookback is not a necessary change nor an enhancement
* POG is ELI5 once the user manual for 5 year olds is created. I can say this because I know that the first gas lawnmower had more exposed controls than the 2000 version. Thats where we are. Im telling everyone that POG is going to be simpler than POW mining. Its POW with one gas pedal.
So lets be man enough to agree to disagree on these points.
One can see volatility here https://viisastentori.fi/bbp_test/checkpool.php .
I don't see correlation to 40 blocks and even more it looks like it might settle in time.
February 14, 2019, 01:48:07 PM
My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners. Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.
The mechanic of tithe=1 being every 4 hours only, could be tweaked so after 4 hours of unsuccessful tithing, client will try every 5 minutes thereafter until a successful tithe. The impact could be many users could all try to tithe at the same time, but something like this could prevent any missed windows.
I reserve judgment until we see how PoG behaves after block 102k. The dynamics are hard for me to comprehend and would like to see it in action with real users tithing.
February 14, 2019, 01:13:01 PM
Kudos for paying for the new user reward.
My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners. Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.
I do have concerns that you aren't willing to spend time on PoDC upfront if it's going to be retired, when that is exactly what you're doing now with PoG. By your labor, you are pushing a winner. It's your right to do so, but to use the lack of revisions to PoDC while PoG is being tweaked and refined is not a good argument against PoDC. I think you have the best intentions and your skills can get around many issues. But PoG is not ELI5 simple to understand even if it is trivial to set up.
A longer look back would mitigate one of the bigger issues with PoG. I beseech you to rethink your position there.
My chief concern about the 40 block look back is wild inconsistency that isn't as visible to PoBH miners as it would be in the face of PoG miners. Additionally since the rewards are not block to block, having a shorter look back for PoBH makes sense, but with the daily reward system of PoG a longer look back is a necessity to make it fair and it's payouts more consistent.
I do have concerns that you aren't willing to spend time on PoDC upfront if it's going to be retired, when that is exactly what you're doing now with PoG. By your labor, you are pushing a winner. It's your right to do so, but to use the lack of revisions to PoDC while PoG is being tweaked and refined is not a good argument against PoDC. I think you have the best intentions and your skills can get around many issues. But PoG is not ELI5 simple to understand even if it is trivial to set up.
A longer look back would mitigate one of the bigger issues with PoG. I beseech you to rethink your position there.
This is where we have to agree to disagree:
* The 40 block lookback is necessary, just as a 28 is in DGW, its an IT thing, and I weighed the efficiency vs the volatility; Youll see in prod in a couple days that vol is low with it. This decision is a good one
* There is no flaw in POG - there was only a configuration issue (all the params were wrong in the first release). This is an incorrect assessment.
* On dev time: Already wearing at least 3 hats; I don't feel this assessment deserves a proper reply - because your not fairly taking into consideration what Ive done for this coin.
* Longer lookback is not a necessary change nor an enhancement
* POG is ELI5 once the user manual for 5 year olds is created. I can say this because I know that the first gas lawnmower had more exposed controls than the 2000 version. Thats where we are. Im telling everyone that POG is going to be simpler than POW mining. Its POW with one gas pedal.
So lets be man enough to agree to disagree on these points.
February 14, 2019, 12:35:17 PM
Where is the funding for this coming from?
Right now Im paying out of my pocket for the BBP reward and the SMS service and the Google Adwords campaign.
I might ask some back later but at this point I dont care.
February 14, 2019, 12:34:33 PM
So on "I'm basically asking how can we gain more users in a system that if it were working at median difficulty would normally need more supply than exists":
We're not expecting to hit median difficulty when we are hoping to gain users; we are expecting to hit very low difficulty at first. I think we will hit difficulty around 1000 in Environment B - simply because of all the tithing capacity available. I wouldn't expect us to come anywhere close to hitting the sum of (single tithes per user) being > total money supply (until we do gain more POG users). I expect a user to tithe 20 times per day in Environment B, using all their bank notes up, with minimum coin age being almost .25 and minimum coin amount being almost 1, and re-using the same banknotes 2* per day. I could see us collecting half of the foundation tithes per day in a low difficulty environment like this, that is until new users join.
The new users are not joining because we didn't tithe our entire money supply, they are joining because POG difficulty is too low and POG profitability is too high. We would shoot from 50 POG users to 500. Why you would disagree with that is beyond me, but thats what would happen if we are paying 1 mil in rewards and only have 50 miners on POG.
On these medium diff figures, the other thing about POG that is different than the math done here above is we have 5 sets of 40 blocks per day with difficulty based on the last 40 blocks, and that will sweep in a lot of tithers who missed the boat up to 5 times per day (IE diff will be a little more volatile) giving them opportunities. What Im implying is if diff is high in the morning in environment B, we will still see it drop once those 40 blocks pass, allowing a lot of low diff users potentially in the pool (unless things are constant through the transition period).
So in summary, I expect difficulty to be as low as 1000 and everyone to tithe 24 times per day. Each time they re-use a coin, it has a minimum coin age requirement of .25 - so theoretically they could re-use the stacks of coins up to 4 times per day.
With 500 users otoh, I would expect difficulty to rise to 20,000 and then the users tithe frequency will drop to what we see now (4* per day, etc) because more coin age will be required per user to maintain the status quo. This is the kind of environment Im hoping to hit, and more than that, 20,000+ users. This algo is tuned for mass adoption.
The entire only looking back 40 blocks thing is going to introduce mass confusion for new users. If user A and B both are new users and have the default set to tithe once per day, and User A's system tries on block 40 of the string...can't because the diff has spiked to 25,000 and he's got no coin stacks older than 23 days and literally ten minutes later, his friend, User B, is able to max tithe 10 BBP from his 1 day old block of coins because he's on block 1 of a new cycle...people will believe they have done something wrong or it's just not working. Then 18 hours later, when User B gets this giant stack of rewards (probably on a 25:1 or better return) User A is really going to be mad. The next day when it happens again, User A will likely just give up and when User B finally gets to the wrong part of the 40 block cycle and suddenly cannot tithe, he'll get confused. He'll stay a few days longer than A because he thinks this coin is supposed to have these crazy rewards but for some reason he's not getting them either. He'll call User A and say "I guess you were right, this coin doesn't work right". They'll both tell non-User C, "avoid BBP, it doesn't work".
The 40 block look back is a big problem in a system that strives to be fair. A look back should be 205 blocks but a look back of 410 blocks would smooth out most the bumps and give a lot more stability to the expectations of users and be much harder to game for unwarranted gains.
While a crazy large ROI will draw in some users initially, at best it's only a temporary influx and quite frankly with the price where it is at and trending towards I cannot see a good retention rate. How we shoot our user base ten fold as you seem to think is feasible, is not so simple. There are MN coins out there with crazy ROI, but they're still low end coins with low user bases. We have one of the cheaper MN costs right now for established coins, but we're not seeing the volume on the markets that would imply we're getting new users from it.
Getting to your point that the algo is tuned to mass use...20,000 users should be nearly impossible with the current parameters. The system (if fully implemented) at median difficulty (which I think we both agree is unlikely in the near term and I'll say is unlikely even in the long term) can only support 10,000 tithes a day. Since most power users will be tithing multiple times each day (even you expect everyone to tithe 24 times a day) this math doesn't add up.
I think you misunderstand my dislike of PoG. It's not that it is inherently a bad system. And it's not that I'm a PoDC-or-die sort of user. It's merely right now we have a system (PoDC) that works for the advanced users and could be simplified for the intermediate users (in fact, it's what was democratically voted to be done a few months ago instead of PoG). I freely admit a new user will be able to put tithe=1 in their config file but that doesn't show an understanding of Pog any more than them putting gen=1 genproclimit=1 minersleep=750 in their config file means they understand PoBH.
Thank you for your reply and despite my disdain for PoG, I do thank you and MiP for your hard work on the coin and the PoG system. At the end of it all, I just think we'll have to agree to disagree.
Well I think you all realize by now I answer in a non biased fashion even at my own expense.
This argument about the 40 block lookback creating confusion is something that is being blown way way way out of proportion. The 40 block lookback is internal and not intended to be communicated to miners - its not something that affects the everyday use in a way that should be in a training guide. Its really the same system that we have with DGW anyway. The lookback period is used by algorithms to get a barometer or a feel going as to where the trend is. Its exactly the same as our 28 block lookback that is hardcoded in to DGW. (Its used so the wallet can be efficient and not slow down). Miners dont know about it - they dont know exactly how the POW difficulty changes - they just know that when its high, its very hard to mine the current set of blocks. This is exactly the same with POG. They dont need to know how exactly the clocks internal mechanism works, but they know how to mine it because they have a steering wheel and a gas pedal. This is an unfair argument, its very clear that POG is easy to use and exposes a simple difficulty that reacts properly to the current pools tithe level. We will be able to get the exact feel for it after block 102025 and before Environment B, because the capacity will be here in just a couple more days (IE the pool capacity and behavior will be in prod at that point) so we will know very clearly how it will behave in Environment B within 7 days after that (short of the hopeful influx of users that would fill up the pool later).
I know the web vote shows strong support for POG and 3 votes more for Improving PODC, however we also didnt get this far by misleading the users or not being democratic. Togo raised the potential issue that the web votes could be being swayed by illegal votes. We spoke about the untrustworthiness of the attackers that swear, that dont really care about the orphans or Jesus, that are here just because they are greedy, and I even watched, yes I WATCHED the 10 new users per minute come in when I ran the forum.biblepay site before Snat got it, and even had to shut off new user registrations to keep the polls from being corrupted. At that point I went ahead and added the official poll as a sanc poll to get support to finish writing and then to deploy POG to prod for this phase. We even commented about the untrustworthiness about web polls. As I said when the poll was on, Im not anti-PODC itself, I just have reservations about its ability to bring mass adoption. I feel the Holy Spirit wants POG over PODC because of that reason; we are supposed to be spreading the gospel otherwise God may not bless this platform. That means my job is to come up with a killer feature that exposes miners and users to the Gospel in new ways (ways that arent here yet) - for example an event list in the wallet, a spiritiual warfare campaign with compensation, we need to inundate users with gospel reminders somehow, but who are we inundating if they are all PODC miners (IE 300, with 10 computers each), why not try to inundate those horizontally, IE 3000 users where we might save one per week (IE let them reach Jesus)? Thats the kind of system God would bless. But Ill clarify, Ill get back on the PODC wagon if its voted for and Ill construct the vote in a way that makes it clear that POG would stay in environment A, and PODC would stay. However I will add a couple catches, that we enhance PODC to address the oracle concern (IE I will virtualize it) and address the concentration in another way (IE I will concentrate PODC in a way that any miner can mine it) but Im not going slate this 300 hours of work for PODC if its voted to be retired. So at this point realize I agree wholehartedly the only secure voting system that exists is our sanc voting system and the next poll should be a Sanc poll for this (around block 106000 or so).
Thank you for bearing with me.
Jump to: