Will support p2pool do?
Yes, actually p2pool is supported.
Topic: [ANN] ** NEW SITE bitgem.pw ** BTG BitGem 0.4.9.ALPHA1 | COLORED COINS | FAUCET - page 35. (Read 147857 times)
July 02, 2013, 04:00:53 AM
Yes, actually p2pool is supported.
July 02, 2013, 02:10:02 AM
Will support p2pool do?
July 01, 2013, 10:02:32 PM
hry mineral any word on the gem wallet for linux yet ?
There is a link with a build of qt GemWallet for linux 64 bits at first post.
You don't have to recompile. It's already a compiled file. Just extract it from the .zip, make it executable and run it.
I'm using 32 bit linux so no go for me, but it should work on 64 bit.
July 01, 2013, 09:58:12 PM
BITGEM VIRTUAL GEMS ASPECT ENCODING (draft proposal 2013-June, Yukon Coinelius)
(Following specification and notes are copyright 2013, [email protected] and supplied for free use only in open-source freely-distributable BitGem wallets and software. Any other use requires separate licensing arrangement.)
Good initiative on the GemWallet idea, mineral. It's very nice to see your continuing development, which I think many BitGem fans have been anticipating, along with future pretty GUIs, etc.
I'd like to open the design up to further discussion, and supply some proposals here that you and the BitGem community can think about and adopt. Your current approach of apportioning the wallet balance across the 4 gems and 4C specs is a good start, but mainly serves the user's personal “hoarding”.
I propose a further UseCase is to focus on the Transactions, to enable users to *send, receive, and trade specific virtual gems*, which represent exact encoded amounts. So for example, users can send “10C Flawless Round Diamond”, or “1C Perfect Heart-Shaped Ruby” -- and those always correspond to exact encoded amounts.
Then:
* each of those gems can have unique pretty pictures in the gui.
* users can scroll through their transaction history to see pictures/names of all the gems they have received in their wallet (even after they spent them).
* users can create and send gems by selecting aspects from pulldown menus, and see the pictures of gems with different properties.
* exchanges could even support trading in such “gems” directly with words or pictures, instead of numeric amounts.
With this approach, the wallet balance itself does not have to be separately maintained in terms of gems (which is complicated - how to make change, handle fees, etc), but conceptually becomes more like a pool of “raw gem material” that you can use to fashion any kind of gem you want (or can afford). (In future, we could also have a way for the wallet balance to be expressed in terms of a user's favorite gems they have received.)
An advantage of this system is that it does not require changes in the underlying bitcoin protocol. It's not a full blown “colored coin” approach, but simply an encoding of transaction values to be reflected in the UI.
QUICK SUMMARY
The basic idea is that a certain amount will exactly represent a specific combination of gem aspects.
For example, 1 Carat of
Flawless Round Diamond = 0.573 btg (just for example, not the real value)
Perfect Round Diamond = 0.473 btg
Perfect Square Diamond = 0.463 btg
Perfect Square Emerald = 0.461 btg
thus, 10 Carat Flawless Round Diamond = 5.73 btg
To send/trade a specific gem, you select the aspects in the GUI and it will compute the amount, or you type an amount and it will tell what gem that is. When you send the transaction amount, it gets delivered exactly to your recipient via the normal bitgem/bitcoin protocol (no changes needed), and thus shows exactly that gem received in their wallet transaction list. So continuing the example, if you send 0.573 btg, the receiver's wallet will show they got a “1 Carat Flawless Round Diamond” (with picture!)
DESIGN ISSUES
To create this capability, we need:
1) to define an *exact unique encoding of Gem Aspects to amounts*, and
2) it must have a defined “total ordering” on the aspects such that higher values specify “better” gems.
Below I supply a working draft of a Gem Aspect Encoding, but before we get to that, the community should think about some general principles and what we want, because it affects how the encoding works. Some top-level design questions and issues:
* Should we support only the 4 gem kinds - diamond, ruby, sapphire, emerald - or allow for expansion to include a few more? I think more would be good if we can accommodate it. Like a total of 8, 16... or even a 100+ (for example, there are about 150 gem kinds listed here: http://www.gemselect.com/other-info/gemstone-list.php) We have to balance the fun and interest of having lots of different gems, versus the development work, complexity, and usability, but I think around 100+ is manageable if there is user interest.
* Simplicity and ease-of-use: The full “4C” system has a nice “theoretical rigor”, but I tend to think users may get overwhelmed with so many technical details in real-world use. Plus it will make the descriptions long and unwieldy. I propose a simplified code with fewer aspects, just (Carat, Quality, Shape, Kind).
* Should all the gem kinds be about the same value, or should diamonds be worth *much* more than rubies, rubies way more than emeralds, etc. I tend to think all the gem kinds should be about the same value, so everyone can afford to trade in the kinds of gems they like best. There will have to be some order, but we can make it so the other aspects count more. So everyone can trade diamonds or emeralds or HeartShaped Rubies, just maybe not 10 Carat Flawless ones.
* Rank of gem aspects
The draft proposal is: Carat - Quality - Shape - Kind, in that order.
So Carat is the most important part of the value - all 10C gems are worth more than all 9C gems. Carat can be as large as you want, so the system scales up to any amount.
Next is Quality, so for equal carat, all Flawless gems worth more than all Fine ones.
Next Shape - (All Round worth more than all Square. This is somewhat arbitrary, so we probably should have only a few shapes, like 4 or 8 so users can remember the order)
And finally, Kind.
I put Kind last so it affects the value least, so everyone can afford to send/trade their favorite gems. Also we might support even 100+ kinds, and it would be too hard to remember the value ordering, so it's better if it counts only a little to the value.
* Scope and Implementation
To collect/manage/display pictures for all the gem combinations, we have to keep the scope at a manageable level.
At 100+ gem kinds * 8 shapes * 4 quality levels, is 3200 combinations, which I think is just about still manageable. I'm hopeful at least the quality could just be an algorithmic change to the picture, like dimming or speckling it. Also, pictures of all shapes across all gems might not be available - maybe there's an algorithm for that too.
Of course, if we just start with 4 kinds (diamond, ruby, sapphire, emerald) it's much easier. Or maybe we don't need Quality, or Shape...?
BITGEM VIRTUAL GEMS ASPECT ENCODING - DETAIL, with Total Ordering (draft proposal 2013-June, [email protected])
Following is the detailed draft proposal.
I dropped many of the technical grades from 4C, and designed for usability and fun (no “poor” grade, nobody wants a poor gem).
Also dropped Color, because it's really just a hue, and adds complexity with little benefit (probably nobody wants a purple emerald).
The numbers of levels in each aspect should be a power of 2, like 4, 8, etc, for efficient bit-encoding.
Gem Aspects, from high to low:
CARAT - (all remaining high bits of the value). So we can define any amount.
QUALITY
order: (Flawless > Perfect > Excellent > Fine) or (Flawless > Excellent > Fine > Good)
Combines cut and clarity from the 4C system, and drops the technical terms like “vs2”, and grades like “poor” (nobody wants a poor gem).
4 levels, encodes in 2 bits.
EXPANSION
We should probably allocate a few bits at this level for future expansion, special “one of a kind” gems, etc. For now these bits would be all 0.
probably 4 bits is enough. However, to scale the basic gem values into a good range, we might like an additional 7 spare bits here, for a total of 11. (see summary example below).
SHAPE
order: Round > Oval > Pear > Heart-shaped > Marquise > Trillion > Square > Baguette
This ordering is a progression from Round to Rectangular (Baguette), where each shape has some similarity to the ones around it.
Basically the rounder and the fewer corner points, the better. (That does not necessarily correspond to real world valuation, it's just for easy mnemonic.)
Limit to 8 shapes, encodes in 3 bits. (maybe use only 4 shapes??)
For reference: Pear is like a teardrop, Marquise is like oval pointed on both ends, Trillion is rounded triangle, Baguette is narrow rectangle.
It might be hard to find pictures of each gemstone in all these shapes. Some algorithmic transform on a base picture would be helpful.
References:
http://www.gemstone.org/index.php?option=com_content&view=article&id=145&Itemid=45
http://www.africagems.com/trillion-gemstones.html
KIND
4 kinds encodes in 2 bits. Consider extension to 128 kinds in 7 bits.
order: (Diamond > Ruby > Sapphire > Emerald) (or alphabetical?)
Consider extending to many more gems including SemiPrecious, up to 8, 16, ... even 128+, like list at http://www.gemselect.com/other-info/gemstone-list.php
If we support many gemstones beyond the 4 precious gems, possibly the value order should be alphabetical. Mainly so people can tell on sight which are most valuable. So we would just have Amethyst > Garnet because A > G. (It's probably too hard to correspond with “real value” ordering, and users would have to keep looking it up anyway.)
Maybe should use alphabetical order even for: (Diamond > Emerald > Ruby > Sapphire).
Carat, quality, shape counts more than the kind in the overall value of the gem.
SUMMARY
This encoding system uses Quality + Expansion + Shape + Kind = 2 + 4 + 3 + 7 = 16 bits to encode the basic gem from 128 kinds. And the remaining high bits for the Carat.
These 16 bits can hold a value up to 64k, which means the base value for a 1 Carat gem ranges 0-64k. Given 1 “cent” is 10000 in the BitGem system, that means the basic 1C gem value can range from 0 to 6.4 cents (0.064 btg).
That value might be a little too small. To move the decimal over 2, we could add 7 more spare bits to the expansion, making 23 bits which gives a range of roughly 0 to 8 btg as the basic 1C gem values.So, with 23 bits and Quality as the highest aspect, we would have basic 1C values distributed approximately like this:
Flawless gems: 4 to 8 btg
Perfect: 2 to 4
Excellent: 1 to 2
Fine: 0 to 1
I hope this specification helps move us forward to being able to send, receive, and trade BitGem virtual gems as unique “real” objects.
All user feedback and comments welcome. Also, donations appreciated, BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
mineral, I have only limited time to assist with this effort, but will try to advise/support you and other developers to implement such features in the Bitgem software. I will follow any community feedback here, and we can also discuss more in PM.
(Following specification and notes are copyright 2013, [email protected] and supplied for free use only in open-source freely-distributable BitGem wallets and software. Any other use requires separate licensing arrangement.)
Good initiative on the GemWallet idea, mineral. It's very nice to see your continuing development, which I think many BitGem fans have been anticipating, along with future pretty GUIs, etc.
I'd like to open the design up to further discussion, and supply some proposals here that you and the BitGem community can think about and adopt. Your current approach of apportioning the wallet balance across the 4 gems and 4C specs is a good start, but mainly serves the user's personal “hoarding”.
I propose a further UseCase is to focus on the Transactions, to enable users to *send, receive, and trade specific virtual gems*, which represent exact encoded amounts. So for example, users can send “10C Flawless Round Diamond”, or “1C Perfect Heart-Shaped Ruby” -- and those always correspond to exact encoded amounts.
Then:
* each of those gems can have unique pretty pictures in the gui.
* users can scroll through their transaction history to see pictures/names of all the gems they have received in their wallet (even after they spent them).
* users can create and send gems by selecting aspects from pulldown menus, and see the pictures of gems with different properties.
* exchanges could even support trading in such “gems” directly with words or pictures, instead of numeric amounts.
With this approach, the wallet balance itself does not have to be separately maintained in terms of gems (which is complicated - how to make change, handle fees, etc), but conceptually becomes more like a pool of “raw gem material” that you can use to fashion any kind of gem you want (or can afford). (In future, we could also have a way for the wallet balance to be expressed in terms of a user's favorite gems they have received.)
An advantage of this system is that it does not require changes in the underlying bitcoin protocol. It's not a full blown “colored coin” approach, but simply an encoding of transaction values to be reflected in the UI.
QUICK SUMMARY
The basic idea is that a certain amount will exactly represent a specific combination of gem aspects.
For example, 1 Carat of
Flawless Round Diamond = 0.573 btg (just for example, not the real value)
Perfect Round Diamond = 0.473 btg
Perfect Square Diamond = 0.463 btg
Perfect Square Emerald = 0.461 btg
thus, 10 Carat Flawless Round Diamond = 5.73 btg
To send/trade a specific gem, you select the aspects in the GUI and it will compute the amount, or you type an amount and it will tell what gem that is. When you send the transaction amount, it gets delivered exactly to your recipient via the normal bitgem/bitcoin protocol (no changes needed), and thus shows exactly that gem received in their wallet transaction list. So continuing the example, if you send 0.573 btg, the receiver's wallet will show they got a “1 Carat Flawless Round Diamond” (with picture!)
DESIGN ISSUES
To create this capability, we need:
1) to define an *exact unique encoding of Gem Aspects to amounts*, and
2) it must have a defined “total ordering” on the aspects such that higher values specify “better” gems.
Below I supply a working draft of a Gem Aspect Encoding, but before we get to that, the community should think about some general principles and what we want, because it affects how the encoding works. Some top-level design questions and issues:
* Should we support only the 4 gem kinds - diamond, ruby, sapphire, emerald - or allow for expansion to include a few more? I think more would be good if we can accommodate it. Like a total of 8, 16... or even a 100+ (for example, there are about 150 gem kinds listed here: http://www.gemselect.com/other-info/gemstone-list.php) We have to balance the fun and interest of having lots of different gems, versus the development work, complexity, and usability, but I think around 100+ is manageable if there is user interest.
* Simplicity and ease-of-use: The full “4C” system has a nice “theoretical rigor”, but I tend to think users may get overwhelmed with so many technical details in real-world use. Plus it will make the descriptions long and unwieldy. I propose a simplified code with fewer aspects, just (Carat, Quality, Shape, Kind).
* Should all the gem kinds be about the same value, or should diamonds be worth *much* more than rubies, rubies way more than emeralds, etc. I tend to think all the gem kinds should be about the same value, so everyone can afford to trade in the kinds of gems they like best. There will have to be some order, but we can make it so the other aspects count more. So everyone can trade diamonds or emeralds or HeartShaped Rubies, just maybe not 10 Carat Flawless ones.
* Rank of gem aspects
The draft proposal is: Carat - Quality - Shape - Kind, in that order.
So Carat is the most important part of the value - all 10C gems are worth more than all 9C gems. Carat can be as large as you want, so the system scales up to any amount.
Next is Quality, so for equal carat, all Flawless gems worth more than all Fine ones.
Next Shape - (All Round worth more than all Square. This is somewhat arbitrary, so we probably should have only a few shapes, like 4 or 8 so users can remember the order)
And finally, Kind.
I put Kind last so it affects the value least, so everyone can afford to send/trade their favorite gems. Also we might support even 100+ kinds, and it would be too hard to remember the value ordering, so it's better if it counts only a little to the value.
* Scope and Implementation
To collect/manage/display pictures for all the gem combinations, we have to keep the scope at a manageable level.
At 100+ gem kinds * 8 shapes * 4 quality levels, is 3200 combinations, which I think is just about still manageable. I'm hopeful at least the quality could just be an algorithmic change to the picture, like dimming or speckling it. Also, pictures of all shapes across all gems might not be available - maybe there's an algorithm for that too.
Of course, if we just start with 4 kinds (diamond, ruby, sapphire, emerald) it's much easier. Or maybe we don't need Quality, or Shape...?
BITGEM VIRTUAL GEMS ASPECT ENCODING - DETAIL, with Total Ordering (draft proposal 2013-June, [email protected])
Following is the detailed draft proposal.
I dropped many of the technical grades from 4C, and designed for usability and fun (no “poor” grade, nobody wants a poor gem).
Also dropped Color, because it's really just a hue, and adds complexity with little benefit (probably nobody wants a purple emerald).
The numbers of levels in each aspect should be a power of 2, like 4, 8, etc, for efficient bit-encoding.
Gem Aspects, from high to low:
CARAT - (all remaining high bits of the value). So we can define any amount.
QUALITY
order: (Flawless > Perfect > Excellent > Fine) or (Flawless > Excellent > Fine > Good)
Combines cut and clarity from the 4C system, and drops the technical terms like “vs2”, and grades like “poor” (nobody wants a poor gem).
4 levels, encodes in 2 bits.
EXPANSION
We should probably allocate a few bits at this level for future expansion, special “one of a kind” gems, etc. For now these bits would be all 0.
probably 4 bits is enough. However, to scale the basic gem values into a good range, we might like an additional 7 spare bits here, for a total of 11. (see summary example below).
SHAPE
order: Round > Oval > Pear > Heart-shaped > Marquise > Trillion > Square > Baguette
This ordering is a progression from Round to Rectangular (Baguette), where each shape has some similarity to the ones around it.
Basically the rounder and the fewer corner points, the better. (That does not necessarily correspond to real world valuation, it's just for easy mnemonic.)
Limit to 8 shapes, encodes in 3 bits. (maybe use only 4 shapes??)
For reference: Pear is like a teardrop, Marquise is like oval pointed on both ends, Trillion is rounded triangle, Baguette is narrow rectangle.
It might be hard to find pictures of each gemstone in all these shapes. Some algorithmic transform on a base picture would be helpful.
References:
http://www.gemstone.org/index.php?option=com_content&view=article&id=145&Itemid=45
http://www.africagems.com/trillion-gemstones.html
KIND
4 kinds encodes in 2 bits. Consider extension to 128 kinds in 7 bits.
order: (Diamond > Ruby > Sapphire > Emerald) (or alphabetical?)
Consider extending to many more gems including SemiPrecious, up to 8, 16, ... even 128+, like list at http://www.gemselect.com/other-info/gemstone-list.php
If we support many gemstones beyond the 4 precious gems, possibly the value order should be alphabetical. Mainly so people can tell on sight which are most valuable. So we would just have Amethyst > Garnet because A > G. (It's probably too hard to correspond with “real value” ordering, and users would have to keep looking it up anyway.)
Maybe should use alphabetical order even for: (Diamond > Emerald > Ruby > Sapphire).
Carat, quality, shape counts more than the kind in the overall value of the gem.
SUMMARY
This encoding system uses Quality + Expansion + Shape + Kind = 2 + 4 + 3 + 7 = 16 bits to encode the basic gem from 128 kinds. And the remaining high bits for the Carat.
These 16 bits can hold a value up to 64k, which means the base value for a 1 Carat gem ranges 0-64k. Given 1 “cent” is 10000 in the BitGem system, that means the basic 1C gem value can range from 0 to 6.4 cents (0.064 btg).
That value might be a little too small. To move the decimal over 2, we could add 7 more spare bits to the expansion, making 23 bits which gives a range of roughly 0 to 8 btg as the basic 1C gem values.So, with 23 bits and Quality as the highest aspect, we would have basic 1C values distributed approximately like this:
Flawless gems: 4 to 8 btg
Perfect: 2 to 4
Excellent: 1 to 2
Fine: 0 to 1
I hope this specification helps move us forward to being able to send, receive, and trade BitGem virtual gems as unique “real” objects.
All user feedback and comments welcome. Also, donations appreciated, BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
mineral, I have only limited time to assist with this effort, but will try to advise/support you and other developers to implement such features in the Bitgem software. I will follow any community feedback here, and we can also discuss more in PM.
July 01, 2013, 09:23:28 PM
If I understand it correctly, the gems are just a way present the single underlying BTG value, right? BTG coins don't have attributes to truly distinguish them, right?
July 01, 2013, 06:06:37 PM
why do i got transaction creation failed message?
help please
i use lastest wallet
help please
i use lastest wallet
July 01, 2013, 07:32:43 AM
Linux x86_64 instructions:
-unzip:
- Linux x86_64 GemWallet: https://docs.google.com/file/d/0B9-QvC1XNosldDExaHR4R0NvY2M/edit?usp=sharing MD5SUM: 91a3694327c48e46f295ca3ccd8de156
-add +x perm
-install pending dependencies packages.
linux-x86_32, MacOS, etc will have to wait a little.
Could you explain what you mean by this please I unzip the file all I see is a qt nothing else so I replace the qt than recompile correct? -unzip:
- Linux x86_64 GemWallet: https://docs.google.com/file/d/0B9-QvC1XNosldDExaHR4R0NvY2M/edit?usp=sharing MD5SUM: 91a3694327c48e46f295ca3ccd8de156
-add +x perm
-install pending dependencies packages.
linux-x86_32, MacOS, etc will have to wait a little.
July 01, 2013, 06:09:49 AM
hry mineral any word on the gem wallet for linux yet ?
I built the linux version on 32 bit ubuntu and I don't have any sign of the special gem wallet.
July 01, 2013, 12:57:38 AM
Linux x86_64 instructions:
-unzip:
- Linux x86_64 GemWallet: https://docs.google.com/file/d/0B9-QvC1XNosldDExaHR4R0NvY2M/edit?usp=sharing MD5SUM: 91a3694327c48e46f295ca3ccd8de156
-add +x perm
-install pending dependencies packages.
linux-x86_32, MacOS, etc will have to wait a little.
-unzip:
- Linux x86_64 GemWallet: https://docs.google.com/file/d/0B9-QvC1XNosldDExaHR4R0NvY2M/edit?usp=sharing MD5SUM: 91a3694327c48e46f295ca3ccd8de156
-add +x perm
-install pending dependencies packages.
linux-x86_32, MacOS, etc will have to wait a little.
June 30, 2013, 11:05:29 PM
hry mineral any word on the gem wallet for linux yet ?
I built the linux version on 32 bit ubuntu and I don't have any sign of the special gem wallet.
June 30, 2013, 06:50:46 PM
hry mineral any word on the gem wallet for linux yet ?
There is a link with a build of qt GemWallet for linux 64 bits at first post.
June 30, 2013, 05:06:37 PM
i still dont understand the gemwallet arent these coins what do the gems do ?
June 30, 2013, 03:49:29 PM
hry mineral any word on the gem wallet for linux yet ?
There is a link with a build of qt GemWallet for linux 64 bits at first post.
June 30, 2013, 03:21:41 PM
I'm working on a BitGem pool.
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
Thanks, the1silverwolf, pool added to info.
How many confirmations are required for mined blocks before the immature transaction confirms ?
The other pool just came online and I notice he has his set at 520.
Is that correct ?
Assuming 520 is correct I have reset the pool to that number. If it's lower than that please let me know.
That seems really high.
yes, 520 confirmations need for matury a mined block.
It is the same than ppcoin, novacoin and bitbar. I suppose it prevents attacks and fosters stake.
June 30, 2013, 02:10:17 PM
I'm working on a BitGem pool.
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
Thanks, the1silverwolf, pool added to info.
How many confirmations are required for mined blocks before the immature transaction confirms ?
The other pool just came online and I notice he has his set at 520.
Is that correct ?
Assuming 520 is correct I have reset the pool to that number. If it's lower than that please let me know.
That seems really high.
June 30, 2013, 01:25:45 PM
hry mineral any word on the gem wallet for linux yet ?
June 30, 2013, 10:55:04 AM
I'm working on a BitGem pool.
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
If anyone is interested in helping me test it out before launch go check it out.
http://swmining.mine.nu/btg
Thanks, the1silverwolf, pool added to info.
June 29, 2013, 05:40:49 PM
lol and it just keeps going up.
It was a glitch. You can see my previous reply here : https://bitcointalksearch.org/topic/m.2613751
June 29, 2013, 05:02:21 PM
Anyone want to trade some for zenith?
June 29, 2013, 04:38:10 PM
lol and it just keeps going up.
Jump to: